VLANs Explained With a Real Homelab Topology

Most homelab VLAN guides fail in the same place. They explain 802.1Q tagging accurately, show you how to configure a trunk port, and then stop — leaving you able to build VLANs and entirely unsure what to put in them. The tagging is the easy half. The design is the half that determines whether you have improved anything.

So this is both halves: how the tagging works, then a complete topology with the actual segmentation rationale and the firewall rules that give it teeth. I have rebuilt my network twice and this is the shape I would build a third time.

What a VLAN is, mechanically

A switch’s default behaviour is to flood a broadcast frame out of every port. Everything plugged into that switch is in one broadcast domain, and every device can address every other device directly. Your printer can reach your NAS. Your doorbell camera can reach your hypervisor’s management interface. There is no boundary anywhere, which means a compromise of the cheapest device on the network reaches the most valuable one with no obstacle.

A VLAN partitions that switch into several logical switches. Frames in VLAN 20 are flooded only to ports in VLAN 20. As far as a device on VLAN 20 can tell, VLAN 30 is on different hardware in a different building.

The mechanism is four bytes. When a frame needs to cross a link shared by multiple VLANs, the switch inserts an 802.1Q tag into the Ethernet header carrying a 12-bit VLAN ID — which is where the 1–4094 range comes from. Ports come in two flavours:

• Access port — belongs to exactly one VLAN. Frames arrive untagged, the switch adds the tag internally, and it strips it again on the way out. The device has no idea VLANs exist. Your laptop, your printer, your Zigbee coordinator all sit on access ports.
• Trunk port — carries several VLANs, tagged. Used switch-to-switch, switch-to-router, and switch-to-hypervisor. Both ends must agree on which IDs cross the link.

Every trunk also has a native VLAN: the one ID that traverses it untagged. It exists for backwards compatibility and it is a persistent source of confusion. Set it to an unused ID that carries nothing, on every trunk, and never think about it again.

And the fact that catches everyone: VLANs alone block nothing between subnets. They put devices in separate broadcast domains, and the moment your router has an interface in both, it will happily route between them, because routing is what routers do. VLAN 20 reaches VLAN 30 through the router at line rate unless a firewall rule says otherwise. The VLAN creates a checkpoint; the firewall rule is what makes the checkpoint refuse anyone. People build eight VLANs, change nothing on the firewall, and conclude that segmentation is overrated. They have built eight subnets and zero security.

The topology

Six networks. The IDs are arbitrary — mine are, yours should be — and all addresses here are illustrative:

The reasoning behind each split matters more than the numbers.

Management is separate because it is the keys to the kingdom. A switch web UI, an access point’s admin page and a hypervisor console are the three things that turn a foothold into ownership of everything. This VLAN has no wireless SSID and no DHCP; reaching it requires a specific port or the VPN.

Servers are separate from trusted clients because the trust runs one way. My laptop needs to reach the NAS. The NAS has no reason to initiate a connection to my laptop, ever. Separating them lets the firewall express that asymmetry, and if the NAS is compromised, it cannot pivot to the machine where my SSH keys live.

IoT is separate because those devices are indefensible. A smart plug runs a vendor firmware blob, last patched at the factory, with a hardcoded cloud endpoint and a support lifetime measured against the vendor’s funding round. Assume every one of them is hostile and design accordingly. This is the single highest-value VLAN in the list, and I have written more about the toaster problem specifically.

Cameras are separate from IoT because they are worse. Cheap NVR cameras are notorious for phoning home to unspecified hosts, and unlike a smart plug they carry a video feed of my hallway. This VLAN gets no internet access at all — the NVR pulls the streams locally and I reach the NVR from elsewhere.

Guest is separate for the obvious reason, and the guest network needs client isolation on the AP as well as VLAN separation, so visitors’ laptops cannot see each other either. The details of getting that genuinely right are their own rabbit hole.

The switch and trunk configuration

Physically: router trunk to the core switch, trunk from the core switch to the access point, trunk to the hypervisor, access ports for everything else. Here is the core switch in a generic Linux/bridge idiom, which is what a managed switch’s GUI is drawing for you:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# Trunk to the router: all VLANs tagged, native VLAN 1 carrying nothing
$ bridge vlan add dev swp1 vid 10,20,30,40,50,60 tagged
$ bridge vlan add dev swp1 vid 1 pvid untagged

# Trunk to the access point: only the VLANs with an SSID
$ bridge vlan add dev swp2 vid 20,40,60 tagged
$ bridge vlan add dev swp2 vid 1 pvid untagged

# Trunk to the hypervisor: server and management VLANs
$ bridge vlan add dev swp3 vid 10,30 tagged

# Access port: NAS, servers VLAN only, untagged
$ bridge vlan add dev swp8 vid 30 pvid untagged

# Access port: an IoT device that must never see anything else
$ bridge vlan add dev swp12 vid 40 pvid untagged

Note swp2. The access point trunk carries VLANs 20, 40 and 60 only, because those are the three with an SSID. Management and cameras have no wireless presence at all, so they never cross that link. Trunk the whole set to every device out of habit and you have handed a compromised access point a path to your hypervisor console.

On the router side, sub-interfaces on the trunk give each VLAN a gateway:

1
2
3

$ ip link add link eth1 name eth1.30 type vlan id 30
$ ip addr add 192.168.30.1/24 dev eth1.30
$ ip link set eth1.30 up

Repeat per VLAN. On an OPNsense box this is the Interfaces → VLANs page and then assigning each one, which is the same operation with fewer opportunities to typo a subnet mask.

The rules that make it mean something

This is the part the tagging guides skip. Default-deny between all VLANs, then punch specific holes. Expressed as nftables:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

table inet filter {
  chain forward {
    type filter hook forward priority 0; policy drop;

    # Established traffic returns. Without this nothing works and you
    # will spend an hour confused.
    ct state established,related accept

    # Trusted -> everywhere internal. My laptop is the admin station.
    iifname "eth1.20" oifname { "eth1.30", "eth1.40", "eth1.50" } accept

    # Servers -> internet only. No lateral movement into client space.
    iifname "eth1.30" oifname "eth0" accept

    # IoT -> internet only. Explicitly never to servers or trusted.
    iifname "eth1.40" oifname "eth0" accept

    # Cameras -> nothing. No internet, no internal. The NVR pulls from them.
    # (Rule intentionally absent: policy drop covers it.)

    # Guest -> internet only, and blocked from all RFC1918 space.
    iifname "eth1.60" ip daddr { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 } drop
    iifname "eth1.60" oifname "eth0" accept

    # Management: reachable from trusted only, on admin ports only.
    iifname "eth1.20" oifname "eth1.10" tcp dport { 22, 443 } accept

    # The specific holes. Home Assistant on the server VLAN must reach
    # the IoT devices it controls. This is a real requirement, so it is
    # a real, narrow rule rather than a blanket allow.
    iifname "eth1.30" ip saddr 192.168.30.15 oifname "eth1.40" accept

    # NVR pulls RTSP from the cameras. Nothing else touches that VLAN.
    iifname "eth1.30" ip saddr 192.168.30.20 oifname "eth1.50" tcp dport 554 accept
  }
}

Read that top to bottom and the network’s security policy is legible in twenty lines. That legibility is the actual deliverable. When something breaks in eight months you will read this file, and a file that describes intent survives contact with your future self far better than a GUI with forty rules in creation order.

The ct state established,related accept line deserves its own warning. Every single person building this forgets it once, discovers that outbound connections send packets and receive nothing, and loses an hour to increasingly wild theories.

What I would skip

Two things from the standard VLAN advice have earned no keep in my lab.

Dynamic VLAN assignment via 802.1X. RADIUS handing each device a VLAN based on its identity is the correct enterprise answer and it is beautiful in a diagram. In a house it means running a RADIUS server, enrolling every device, and discovering that half your IoT hardware has no supplicant at all and needs a MAC-authentication bypass — which is a static port assignment with extra steps and a service that can fail. Static assignment is boring, legible, and has no runtime dependency. Keep it.

A VLAN per service. Somewhere past six the trust boundaries stop describing anything real. A separate VLAN for the media server and the backup server means two subnets whose firewall policy is identical, so the boundary between them is decorative. The test I use: if I cannot state, in one sentence, what a VLAN defends against and what it would contain during a breach, it should be merged into its neighbour.

The threat this actually addresses

It is worth being precise about what segmentation defends against, because the benefit is frequently described in terms that do not survive scrutiny.

VLANs do nothing about the initial compromise. A camera with a vulnerable firmware image gets compromised on VLAN 50 exactly as easily as it would on a flat network. Segmentation has no opinion about that event and cannot prevent it.

What segmentation attacks is lateral movement, and lateral movement is the step that turns an incident into a catastrophe. The realistic bad day in a home network runs like this: something cheap and unpatchable gets owned, either through an exposed service or a compromised vendor cloud. On a flat network, that device now sits on the same broadcast domain as everything you own. It can scan the whole subnet, find your NAS advertising SMB, find your hypervisor’s management page, find the router’s admin interface, and try default credentials against all three. The compromise of a £12 plug becomes the compromise of your photo archive, and the path between those two facts is about four minutes long.

With a camera VLAN that is denied all egress, the same compromised device can reach the NVR on port 554 and nothing else in the universe. It cannot scan, it cannot find, it cannot phone home for instructions. The incident stays exactly the size it started at.

That is the entire value proposition, and it is worth stating in those terms because it sets the right expectation. Segmentation makes a successful attack smaller. Given that the attack surface in a modern house consists largely of hardware from vendors who stopped caring in 2019, containing the blast radius is the only lever you actually control.

The corollary matters too: a VLAN whose firewall rules allow it to reach everything has zero value. The rules are the product. The tags are just plumbing.

Troubleshooting

“The device gets no IP.” In order: is the port’s PVID the VLAN you think it is; does the router have a sub-interface on that VLAN; is DHCP listening on that sub-interface; and does the trunk between switch and router carry that tag? A device on an access port with the wrong PVID sits in silence, because the DHCP request is flooded into a VLAN with no server in it.

“It works on the switch and dies at the router.” Almost always a trunk that carries the VLAN in one direction only, or a native VLAN mismatch. tcpdump -i eth1 -e vlan on the router shows tags on arriving frames — if you expect vlan 30 and see untagged frames, the native VLAN is eating them.

“Home Assistant lost half its devices.” mDNS and SSDP are link-local by design: discovery broadcasts do not cross a router. Segmenting IoT away from the controller breaks every discovery protocol simultaneously. You need an mDNS reflector or an Avahi repeater bridging the two VLANs, and be deliberate about which ones — a reflector between every VLAN quietly undoes the isolation you just built.

“Names resolve to the wrong address.” Once services are reachable at different addresses from different VLANs, DNS has to answer differently depending on who asked, which is a whole topic of its own.

“I locked myself out of the switch.” Traditional and avoidable. Configure management VLAN access last, keep a physical access port on the management VLAN, and know where the reset pinhole is. I have twice reset a switch to factory defaults over precisely this.

Is it worth it?

For anything with IoT devices in it: yes, unequivocally. The IoT VLAN alone justifies the whole exercise, because the alternative is a network where a £12 plug with 2019 firmware sits at the same trust level as the machine holding your photos. Two VLANs — trusted and IoT — capture most of the available benefit and take an evening.

Six VLANs is a weekend, and it is worth it if you already have a managed switch and a real firewall. If you are running an ISP router, buy the managed switch first; the VLANs are theoretical until something can enforce rules between them.

The honest cost is complexity forever. Every new device raises a question about which VLAN it belongs in. Every broken thing has one more layer to check. mDNS will annoy you approximately once a quarter. In exchange, the compromise of a cheap device stays a compromise of a cheap device. Given how many indefensible things we plug in now, I have made that trade twice and would make it again.