Where VLAN isolation actually comes from

The setting that feels like a wall

Splitting a flat home network into a guest segment, an appliance segment and a trusted segment is one of the most satisfying changes you can make to a home server. Each network gets its own subnet, the router sits between them, and nothing crosses without a rule. That is real progress, and it is easy to over-read.

The over-reading starts with the word "isolated". A VLAN identifier is a label carried on a frame. Isolation is a property of the whole path that frame travels, and every device on the path has to agree about the label. Where the agreement stops, the isolation stops — quietly, and without an error message.

A VLAN is a label, not a wall

OPNsense's own guide describes a VLAN as a way to create separate layer-2 networks inside one physical switch, keeping different groups of devices isolated even though they share the same hardware. The mechanism is the tag. On a trunk link between devices that understand it, frames carry their VLAN tag so one cable can carry several networks at once. On an access port — the kind a computer, printer or access point plugs into — the switch adds a tag to frames arriving from the device and strips the tag from frames leaving toward it. The end device sees no tag at all; it simply believes it is on one ordinary network.

That is what makes the mental model precise. The tag is meaningful only between devices that understand tags.

Where the tag stops, the boundary stops

OPNsense's guide is blunt that unmanaged switches provide only basic functionality, while managed switches support VLANs. If an unmanaged switch, a simple repeater or an adapter that ignores tags sits between your router and a group of devices, those devices end up in one broadcast domain no matter what the plan says. The tags cannot be carried or cannot be interpreted, and frames that should have stayed apart are delivered to everyone attached to that device.

There is a second, sharper warning in the same guide: do not mix tagged and untagged VLANs on the trunk connecting the router and the switch. The documented side effects include leaking router advertisements, DHCP, CARP and other broadcasts between the tagged and untagged networks. A trunk left in a mixed mode out of habit can join the very networks you separated.

The practical habit is to trace one device to the router and label each link as tag-aware or not. Pay particular attention to the trunk feeding a Wi-Fi access point: most access points expect their management network untagged and additional SSIDs tagged, so that link is deliberately mixed — and it is where a mistake most often reconnects a guest network to everything else.

The router is a member of every zone

Because crossing a VLAN requires routing, the firewall has an interface in each one. That is what makes it the boundary you review, and also what makes it the single device where all the networks meet. An extra interface assigned to the wrong VLAN, a bridge between two ports, or a rule left broader than intended turns the router from a crossing point you chose into a crossing point you forgot.

The router is inside every zone at once, so it deserves the least privilege and the most careful review of anything on the network.

Discovery is the convenience you will be tempted to restore

Segmentation has a tax that arrives the next morning: the printer, the speaker and the television stop appearing. That is expected. Multicast DNS names ending in `.local.` are link-local by definition. RFC 6762 says such names are meaningful only on the link where they originate, that queries must be sent to the mDNS link-local multicast address, and that responders should ignore queries arriving from outside the local link. A router does not forward that traffic between subnets, so discovery fails politely rather than loudly.

The usual fix is deliberate. OPNsense documents an mDNS proxy plugin that connects multicast DNS across multiple networks; it is installed on purpose and needs at least two interfaces. Turning it on is not fixing a bug. It is choosing to re-bridge a narrow slice of the boundary so devices can find one another. That can be the right trade, and it deserves to be a written decision rather than a checkbox: which records need to cross, from which network to which, and whether a narrower proxy that repeats only the services you need can do the job instead of everything.

A repeater forwards discovery, not data — but discovery is what lets a client learn an address and then connect, so convenience and exposure travel together.

A segmentation test you can read

A segment is only as trustworthy as the test that proves it. Keep the test small enough to repeat.

• **Trace the path.** For one representative device, list every hop to the router — cable, switch, access point, adapter — and mark each as tag-aware or not.
• **Check the trunk.** Confirm the router-to-switch trunk carries no unintended untagged VLAN, and record the deliberate mixed trunk at the access point.
• **Test the crossing.** From one zone, reach a service in another on its expected port, then try an unplanned host or port and confirm it fails.
• **Test discovery.** Name which discovery protocols an application relies on, and whether a repeater carries them, between which networks, and why.
• **Capture, do not assume.** A short packet capture on each interface shows whether tagged frames actually arrive; a green rule counter only shows that something matched.
• **Keep a way back.** Before changing tags on a trunk, confirm console or local access that does not depend on the network you are editing.

What segmentation does not do

It does not patch a device, and it does not protect devices inside the same segment: traffic within a VLAN goes directly between them rather than through the router. It does not stop a person copying data from one network to another. And it does not replace identity or application-level authorization — a firewall sees the paths and protocols it can observe, not the meaning of every request.

These are limits, not objections. The value of segmentation is narrow and real: it removes accidental reachability and makes the intended paths explicit. A firewall rule is not a network boundary covers the rule-writing discipline; the point here is that the rules only matter if the path actually honours the separation.

What we would do next

Pick one boundary you rely on, trace its full path once, and write three lines: what is allowed to cross, why, and what evidence shows it does. Then find one re-bridge — a mixed trunk, a discovery proxy, an extra interface — that you cannot justify, and remove it. Isolation becomes believable when you can point at the path and not just at the setting.

Sources and limits

This article synthesises the sources below into a practical explanation. It is not a security standard, legal advice, or a guarantee that guidance current at review time still applies — check the review date above against your own situation.

1. VLAN and LAGG Setup — OPNsense. Explains that a VLAN creates separate layer-2 networks on the same switch, distinguishes tagged trunk ports from untagged access ports, states that an access port tags ingress frames and strips egress tags, notes that unmanaged switches do not support VLANs, warns against mixing tagged and untagged VLANs on a trunk because broadcasts can leak between them, and states that traffic crossing VLAN boundaries must be routed and controlled by firewall rules.
2. Multicast DNS Proxy — OPNsense. Documents the mdns-repeater plugin, which connects multicast DNS of multiple networks, is installed deliberately, and requires at least two interfaces to work.
3. RFC 6762: Multicast DNS — IETF. Defines names ending in .local. as link-local and meaningful only on the link where they originate, requires queries to be sent to the mDNS link-local multicast address, and advises responders to ignore queries that arrive from outside the local link.

More from Server Attic

• 2026-08-07

  A firewall rule is not a network boundary

  A practical OPNsense-inspired checklist for separating trust zones, writing understandable rules, testing the path and keeping a recovery route when a firewall change goes wrong.

• 2026-10-22

  A .env file is not secret management

  A .env file keeps a value beside the process. Secret management still has to answer where that value lives, who can read it, how it is replaced, and how the backup is protected.

• 2026-10-22

  A restart policy is not supervision

  A restart policy brings a container back after it exits. Supervision is the separate work of noticing the repeats, limiting them, and escalating while the process is still failing.