My home network grew the way most do: one flat /24, everything on it, no plan, just years of plugging things in. Last weekend I finally split it into VLANs, and it was more painful than it should have been, almost entirely because of mistakes I made that you can skip. So here is the order I wish I had done it in, and the traps I fell into.
The motivation was overdue. A flat network means every device can talk to every other device, and the population of "every device" had quietly become alarming: servers I care about, my laptop and phone, a games console, and a growing crowd of cheap IoT gadgets running firmware I would not trust to tell the time. One compromised smart plug should not be able to reach my file server, and on a flat network it absolutely could.
The plan, such as it was
Four segments, which I think is the sensible minimum for a homelab that has stopped being a toy:
- VLAN 10, servers: the things I actually care about and back up.
- VLAN 20, trusted: laptops, phones, the devices I personally control.
- VLAN 30, IoT: the smart plugs and sensors and anything running mystery firmware.
- VLAN 40, guests: internet only, nothing else.
The principle is simple. Trusted can reach servers. IoT and guests cannot reach anything but the internet and the specific services they genuinely need. Default deny between VLANs, with holes punched only where I can name the reason.
Where it got painful
The first mistake was doing the addressing live without writing it down first. I started reconfiguring the router before I had a clear table of which subnet was which VLAN, which gateway, which DHCP scope, and I ended up with VLAN 30 handing out addresses on the VLAN 20 subnet for a confusing half hour. Write the table first. On paper. Before you touch anything.
VLAN 10 servers 10.0.10.0/24 gw .1
VLAN 20 trusted 10.0.20.0/24 gw .1
VLAN 30 iot 10.0.30.0/24 gw .1
VLAN 40 guests 10.0.40.0/24 gw .1
The second mistake, the expensive one, was forgetting how trunking works on the switch and locking myself out. I changed the management interface onto VLAN 10, but the port my laptop was plugged into was an untagged access port on the old default VLAN, so the moment the router config applied, my laptop and the router were on different segments with no route between them and a firewall that defaulted to deny. I had cut the branch I was sitting on.
The fix was a console cable and a slightly sheepish twenty minutes. The lesson: always keep one known-good way back in that does not depend on the change you are making. Console access, or a dedicated management port left untouched until the very end, or at minimum a second device on the old VLAN you can fall back to. Do not migrate the path you are standing on first.
The bit that always bites: IoT discovery
Once the VLANs were up and the inter-VLAN rules were in, everything worked, and then half my smart home stopped working, which is the moment you remember why people leave their networks flat.
The problem is multicast discovery. mDNS and SSDP, the protocols Chromecast, AirPlay, Sonos, smart speakers and friends use to find each other, are link-local by design. They do not cross subnets, on purpose. So the instant you put your trusted phone on VLAN 20 and your speaker on VLAN 30, the phone cannot find the speaker, because the discovery packets never leave their own segment.
There are two honest answers. One is an mDNS reflector or repeater on the router that forwards those discovery packets between the specific VLANs you choose, so trusted can still find the IoT devices it is allowed to use without IoT being able to reach anything else. The other is to decide that the convenience is not worth the boundary and put the casting devices on the trusted VLAN with their owners, accepting they are slightly less isolated. I went with a reflector between VLAN 20 and VLAN 30 only, and tight firewall rules so the discovery is the only thing that crosses.
This is the part nobody warns you about and the part that turns a clean segmentation plan into an evening of "why can't the telly see the phone". Budget for it. Segmentation breaks discovery, and rejoining the bits you actually want, deliberately and narrowly, is the real work.
Where I landed
It works now, and it is genuinely better. My IoT VLAN can reach the internet and nothing on my server VLAN, full stop. A compromised gadget is contained to a segment full of other gadgets and no data I care about. Guests get internet and a warm feeling of isolation. My laptop can reach the servers, the casting still works through a narrow reflector, and the whole thing is documented in a table I will thank myself for in a year.
If you are sitting on a flat network and have been meaning to do this, the migration is worth it, but do it in the right order. Write the addressing down first. Keep a guaranteed way back in. Expect multicast discovery to break and plan how you will heal the parts you actually use. Do those three things and you will avoid the console-cable walk of shame that I did not. Skip them and, well, the cable is only twenty minutes, but it is a long twenty minutes.