Cross-VLAN sharing and auto-discovery of selective resources

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.

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.