1

I am to deploy some managed switches for FTTB/FTTH and preparing configuration to introduce isolation between customers (by disabling L2 forwarding between client ports or using private VLANs). However this having it's benefits also introduces one major drawback - inability for clients from same ip subnet to communicate with each other.

Let's say two of them get assigned addresses 80.x.1.2/24 and 80.x.1.3/24. Since L2 forwarding between them is not possible they cannot communicate in traditional Ethernet manner. That is exactly what I want for security reasons: hiding broadcast arp traffic, preventing rogue DHCP servers, etc. Clients L2 boradcast domain is effectively limited only to see the required servers and their gateway.

I'm not sure if this isn't against very basics of networking itself, but is there any way to force their traffic to go through a router without manually creating routes in client hosts themselves? This would solve everything - traffic filtering, bandwidth management, monitoring, etc..

squirrely
  • 209
  • 3
  • 11
  • As I read this, I'm wondering if your goals are contradictory. You want client isolation, unless they want to communicate? – mfinni Jan 14 '14 at 13:45
  • Sure, I thought that it might sound that way. Then probably it's more a question of filtering. I'm aware of DHCP snooping and few other security features implemented in switches to be used in such situations, but how would you apply bandwidth limitations applicable for plans they buy? Or let's say they plug their Windows machines directly, without routers. Customers that don't know about each other end up being connected to the same switch, like LAN at home. – squirrely Jan 14 '14 at 13:56
  • The users will need a router to communicate with the outside world (default gateway), and that will provide all the connectivity you need. Basically set up policies, rules, whatever on the router to allow traffic between the nodes. – NickW Jan 14 '14 at 14:12
  • So you basically suggest to force clients to use our supplied routers with our predefined configuration? – squirrely Jan 14 '14 at 14:23
  • Why would you be allowing communication between them? You're giving them NAT-ed IP addresses, so nodes out on the public internet wouldn't be able to initiate communication with your customers. So, since that can't happen, why would you bother allowing customers to contact each other directly? You're selling a gelded internet connection, so just leave it at that. – mfinni Jan 14 '14 at 14:43
  • @squirrely, no, if they're going to be using your switch, you'll have to configure their PC/router/Ipad to connect to the internet, and when you configure them, you put in a "default gateway", the default gateway will route any traffic your clients send, if you administer it properly, you can allow intra-client communication through your router (if you decide to do so). – NickW Jan 14 '14 at 14:47
  • @mfinni: Actually I'm giving them public IP addresses and NAT'ing is optional for clients, if they deploy own router in their premises for that purpose. NickW: I give them IP addr's via DHCP, and the switch I talk about is FTTB switch for different customers in that building. Clients only get the lead of wire with a plug. – squirrely Jan 14 '14 at 15:26
  • You distribute IP addresses, do you pass a default gateway and subnet mask at the same time? – NickW Jan 14 '14 at 15:31
  • Maybe it's me but I don't understand your problem. You have hosts from multiple customers connected to the same switching infrastructure and you want to restrict communication in the switching infrastructure so that one customers hosts cannot communicate with another customers hosts but can communicate with each other? That is precisely what a VLAN is for. Create a VLAN for each customer. Add port members to each VLAN. Connect the hosts for each customer to the ports in their respective VLAN. – joeqwerty Jan 14 '14 at 16:39
  • @NickW: yes, I do. Also, I've been exploring the issue and found that ISP I currently explore hands out public IP address from /18 subnet. If I do a traceroute to neighboring IPs, they're reached through gateway in that same subnet. That's basically what I'd like to do, but I'm having difficulty understanding how that's possible.. – squirrely Jan 14 '14 at 16:54
  • If you look at the subnet mask on those IPs they hand out, I think you'll find them to be smaller than a /18, and the PC will send anything that it can't reach locally to the gateway (router) who having them connected to VLAN interfaces, will know how to route the traffic back and forth. – NickW Jan 14 '14 at 16:59
  • @joeqwerty: it seems that my original question is misleading and it might be wise to correct it, but I'm not yet sure how. Basically I don't feel confident leaving L2 forwarding active between customers due to security reasons, yet I do not like the fact that neighbors have no direct connectivity between them (let's say to exchange files via torrent, etc..). There wouldn't be any problems if all the clients got their public IPs from different subnets and they'd be able to communicate through a router, but there's no way I can do that. – squirrely Jan 14 '14 at 17:11
  • @NickW: Well the fact that DHCP given address is on another side of entire /18 subnet than default gateway, gives me a hint that the subnet is not divided after all.. Am I wrong? I'm aware that host tries to reach anything out of it's local subnet via default gw, but in my case hosts in question are in the same subnet, and the goal is to somehow force all the traffic between hosts through a router. – squirrely Jan 14 '14 at 17:21
  • 1
    I suppose the router could be doing proxy ARP, telling the hosts that any other IP is actually the router's MAC. – NickW Jan 14 '14 at 17:27
  • I've changed the original question to better explain the situation. – squirrely Jan 15 '14 at 08:46
  • 1
    Proxy ARP would be my choice of tech to do this, http://en.wikipedia.org/wiki/Proxy_ARP, the first paragraph on wikipedia explains most of why: "`Serving as an ARP Proxy for another host effectively directs LAN traffic to the Proxy.`" – NickW Jan 15 '14 at 09:22
  • 1
    I apologise, but I really don't get this question. What it **seems** to me to boil down to is "*I have machines whose addressing scheme connects them at layer 2, but I want to be able to filter as if they were connected only at layer 3 and separated by a traditional layer-3 firewall*". If that's the case, why not connect them via a switch fabric capable of firewalling? – MadHatter Jan 15 '14 at 09:25
  • Thanks NickW, your suggestion seems promising, I shall look at it. MadHatter, you're not getting the whole point. Filtering at switch itself provides solution only to one part of the problem I described. – squirrely Jan 15 '14 at 10:33
  • 1
    That is very possible, but you write "*There wouldn't be any problems if all the clients got their public IPs from different subnets and they'd be able to communicate through a router, but there's no way I can do that.*". What problems would be solved by them communicating through a router that are not solved by a switching fabric capable of firewalling as a router does? – MadHatter Jan 15 '14 at 10:47
  • I'm with MadHatter on this one. – mfinni Jan 15 '14 at 15:36
  • Bandwidth throttling, client local traffic accounting, limiting any network access in case of client suspension. I agree that some of the mentioned features can be implemented in the switch itself, but managing and configuration becomes very inconvenient. Having all the traffic flowing through a router makes all the management easier. By the way, I'm not trying to prove anything here. I'm open to suggestions to find best solution. Firewalling at switch itself was considered long time ago, but was ruled out for reasons mentioned earlier. – squirrely Jan 16 '14 at 07:41

0 Answers0