1

I have a network with several VLANs that each contain resources or clients with different access rights.

For simplicity, let's say I have 3 VLANs:

  1. ID 10: Contains privileged clients and private resources only accessibly to these privileged clients
  2. ID 20: Contains guest-clients that only have access to public resources
  3. ID 30: Contains public resources that are accessible by both privileged and guest-clients

On this setup, I would like to make auto-discovery and access right management work so that clients in VLAN 10 can discover and access resources in VLANs 10 and 30, and clients in VLAN 20 can discover and access resources in VLANs 20 and 30. The resources I need to auto-discover are of different type (windows network shares, printers, security cameras, apple devices, etc.) so there are several different mechanisms at work, most of which I don't have any knowledge over.

Is it possible to make such a setup work generically, so that devices on VLAN 10 see a single network that consists of both VLANs 10 and 30 and behaves just like as if everyone were plugged into the same switch and devices on VLAN 20 see a network that consists of all devices on VLANs 20 and 30?

Would I need to create a bridge between VLANs 10 and 30 and a second bridge between VLANs 20 and 30? Would this also implicitly bridge VLANs 10 and 20 (not acceptable)? If so, can I just disallow this implicit bridging with firewall rules (like drop all packets from VLAN 10 to VLAN 20 and vice versa)?

What would be the best way to subnet such a layout and how would I go about setting up DHCP to accomplish it? My current thoughts are something like the following:

  • 192.168.10.x for VLAN 10, 192.168.20.x for VLAN 20, and 192.168.30.x for VLAN 30
  • Subnet 255.255.0.0 for everyone (so that devices send broadcasts across VLANs)

Is it possible to get such a setup working on a Vyatta-Linux-based router, especially the DHCP part? It seems to determine which interfaces to listen on based on the subnet I provide. So, to have it listen on eth0.10 (VLAN 10), I would need to give it subnet 192.168.10.0/24, but I would like for the DHCP clients to be told that the subnet is 255.255.0.0, not 255.255.255.0.

What other services/forwarding would I need to set up (e.g. ARP proxying) to be reasonably sure that all common auto-discovery-mechanisms should work?

Any help would be much appreciated.

Markus A.
  • 419
  • 7
  • 18
  • 1. Broadcasts don't cross subnets, regardless of the subnet mask. 2. You'll need to route traffic across the VLAN's (inter-VLAN routing). 3. You'll need to set up a DHCP scope for each VLAN. 4. You'll need to configure a DHCP relay agent to get DHCP to work across the VLAN's. 5. What type of "auto-discovery of selective resources" are you referring to? Windows clients don't automatically discover resources, such as file shares and shared printers. – joeqwerty Jan 18 '14 at 02:41
  • @joeqwerty Let me address the points you made: 1. Yep. That's why I was thinking of giving the clients the 192.168.0.0/16 subnet mask so that all 3 VLANs are in the same subnet. 2. Is a simple bridge sufficient for this? 3. You mean by giving them independent subnets? 4. What would be the purpose of this agent? To resolve the names of resources on a different VLAN? 5. Can be anything. Can be the windows netbios functionality that allows it to populate the network neighborhood, Apple's bonjour, UPNP, but also a couple proprietary things like security camera software needing to find the cameras. – Markus A. Jan 18 '14 at 02:46
  • A: 1. VLAN's provide separation at layer two. It doesn't matter what layer three subnet each set of clients uses, broadcasts on one VLAN will never reach any other VLAN even if the clients are on the same layer three subnet. 2. Think of a VLAN as a separate routable network. In order to get traffic from one network to another and vice versa you'll need to route that traffic. Routing between VLAN's is called Inter-VLAN routing. 3. Yes. Each VLAN will be a different, independent subnet at layer three. You'll therefore need an appropriate DHCP scope for each subnet (VLAN). Continued... – joeqwerty Jan 18 '14 at 02:55
  • 4. A DHCP relay agent relays DHCP client traffic (DHCPDiscover packets) from one subnet to a DHCP server on another subnet. That's the way you get DHCP to work across subnets with a single DHCP server. 5. NetBIOS traffic doesn't cross subnet boundaries. You would need to configure the router to route NetBIOS traffic. – joeqwerty Jan 18 '14 at 02:58
  • @joeqwerty It sounds like you are suggesting I just need to keep my VLANs entirely separate, just like if they were physically different networks and then set up whatever routing (netbios, bonjour, upnp, ...) I need manually to individually make all the discovery and stuff work. I was trying to see if there is a different solution that basically "maps" VLAN 30 into VLAN 10 and VLAN 20. The physical analogy of this would be to give all devices on VLAN 30 two NICs and plug them into 2 switches. Then connect one of them to network 10 and the other to network 20. Can I do this virtually in VLANs? – Markus A. Jan 18 '14 at 03:17
  • @joeqwerty I'd rather not have to deal with setting up all the different types of routing I need to make all the auto-discovery work, if there is some (let's say) layer-2-way of simply bridging the VLANs in a clever way and using firewall packet-dropping to enforce access rules. Think of a physical switch with eth0, eth1, and eth2. Then bridge all 3 of them, but drop all traffic incoming on eth0 outgoing on eth1 and all traffic incoming on eth1 and outgoing on eth0. That should do the trick. Except, how do I set up DHCP for this? – Markus A. Jan 18 '14 at 03:20
  • I'm not actually suggesting anything. I only wanted to give you some insight into how VLAN's work. I would hold on and see what answers and additional insight you get from others to your question. – joeqwerty Jan 18 '14 at 03:25
  • @joeqwerty :) Makes sense... So far, I've just been viewing VLANs as a way-in-software to create a "parallel" network that runs on the same physical links across smart-switch, but behaves in every way just like as if it was a physically separate network, except you use eth0.10 and eth0.20 on your router for the interfaces to the two networks rather than eth0 and eth1. But maybe the analogy breaks down somewhere? Maybe I should have asked the question talking about physical networks instead rather than complicating things by introducing VLANs into it. Should be the same ideas, no? – Markus A. Jan 18 '14 at 03:31

1 Answers1

3

You and @joeqwerty had a spirited discussion in the comments for the question and I'm going to echo some of that.

Let's start from a simple basis: There are multiple standard and vast numbers of proprietary "auto-discovery" protocols-- that is, protocols by which client and server hosts or programs locate each other. To speak about "auto-discovery" as though it is a monolithic entity is skirting the entire issue. Keep that in mind throughout.

You've segmented your network into multiple virtual LANs. Broadcasts will not be communicated between these virtual LANs. Many (most?) auto-discovery protocols are broadcast-based, so they're going to fail to locate hosts in other VLANs.

Just bridging the networks together won't help you because, in effect, you'll just make all the networks into one big LAN again. All the other reasons you have for segmenting into multiple VLANs are out the window.

Selectively forwarding protocols between VLANs is where things will get interesting.

Standard IP-based auto-discovery protocols, like NetBIOS "browsing", mDNS (known as "ZeroConf" or "Bonjour", and others can be forwarded between IP subnets (which are typically mapped 1-to-1 to VLANs by logical sub-interfaces on routers) with proper application-layer gateway software. There are various products from multiple vendors that can do this (use your favorite search engine and look for "forward bonjour between subnets" and you'll find lots of stuff, for example.)

Proprietary auto-discovery protocols are going to be more problematic. You'll have to hope that software has been written by someone to forward them across VLANs or subnets. Protocols that work at layer 2 only are going to be even more problematic because in order to cope with the adjacency tables your switches maintain accounting for the VLAN a MAC address is associated with, any cross-VLAN gateway software will have to have some kind of proxy-MAC functionality.

What you're looking for isn't impossible, but it will have to be handled on an individual protocol basis. There is no "magic wand" solution that you can apply to achieve the result you're looking for.

Evan Anderson
  • 141,881
  • 20
  • 196
  • 331
  • Ouch... Having to deal with each service individually was exactly what I wanted to avoid... Yuck... I guess I'm not lucky today... Let me leave the accepted answer open for now, hoping for a miracle, but looking at the impressive detail in your other answers (and your reputation, of course), I don't have high hopes... If nothing comes up in a week, you get the v´. :) – Markus A. Jan 18 '14 at 05:39
  • What happens if I simply have all my VLANs be part of the same subnet and then set the ports of private resources to be "untagged members" of only VLAN 10 with PVID 10 (standard VLAN 10 access port), the ports of public resources are untagged members of VLANs 10, 20, and 30 with PVID 30, privileged clients are untagged members of VLANs 10 and 30 with PVID 10, and guests are untagged members of VLANs 20 and 30 with PVID 20. Shouldn't this do what I want? And even without the "router-on-a-stick" bottleneck? Or are there issues with this? – Markus A. Jan 18 '14 at 06:02
  • If your switch allows you to mark a port an untagged member of multiple VLANs you might be able to pull off something like you describe. No modern switch will permit you to mark a port as an untagged member of more than one VLAN, though. – Evan Anderson Jan 18 '14 at 06:05
  • The Cisco SG200-08 seems to be able to do it if I set the port to "General". I'll see if I can set something like this up over the weekend. Should be interesting to get the router to work in such a messy environment. Let's see how DHCP and other services behave if the router has multiple paths to the exact same NIC on different VLANs. E.g. if the router sends a packet to a guest-client via VLAN 30, that packet will arrive, but any corresponding replies will come back on VLAN 20... And the guest won't even know what happened... Hmmm... Any potential issues that you can see? – Markus A. Jan 18 '14 at 06:14
  • I give your odds at getting something you want at less than 1 in 100. – Evan Anderson Jan 18 '14 at 06:14
  • I'm surprised that what I'm trying to achieve seems to be so obscure. Sounds to me like a very standard problem. And so far, I haven't come across a good reason why **at least in theory** IEEE802.1Q and a Linux router or switch shouldn't be able to get this working... Strange... :) Would this be equally impossible with physically separate networks? Or could you simply use the filtered bridging there? – Markus A. Jan 18 '14 at 06:20