My home network grew the way most do: one flat /24, everything talking to everything, added to whenever I bought a thing. It worked, in the sense that a single room with no internal walls works. The problem was not performance. The problem was that a cheap smart plug and my actual computers shared a broadcast domain and a trust boundary, and the more devices of dubious provenance I added, the less comfortable I was with that.
So: VLANs. The plan was sensible. The execution is where I would like to save you some grief.
The target layout
I settled on four segments, which is about as far as I wanted to manage by hand:
- VLAN 10, trusted: my machines, the NAS, the things I actually administer.
- VLAN 20, IoT: smart plugs, the TV, anything with firmware I did not write and do not trust.
- VLAN 30, guests: internet only, nothing else.
- VLAN 99, management: switch and router management, locked down hard.
Inter-VLAN routing happens on the firewall, default-deny between segments, with explicit allows for the handful of flows that genuinely need to cross. The IoT segment can reach the internet and almost nothing on the trusted side. That last point is the whole reason for the exercise.
Doing it without a flag day
The temptation is to reconfigure everything in one heroic evening. I have done flag-day migrations at work and they are stressful even with a maintenance window and people to help. At home, alone, with a partner who would quite like the internet to keep working, it is a bad idea.
So I did it incrementally. The old flat network stayed alive on its existing VLAN, untagged, as the default. I built the new VLANs alongside it, got routing and firewall rules working between them with a single test device, and only then started moving real devices across one segment at a time. The guest network first, because nothing important depends on it. Then IoT, which was the fiddliest because some devices hated being moved. Trusted last, when I was confident the routing was solid.
The things that broke
This is the useful part. Here is what I did not anticipate.
mDNS and discovery stopped working the moment devices were on different VLANs. Obvious in hindsight: multicast does not cross a routed boundary on its own. The phone on trusted could no longer see the speaker on IoT. I ended up running an mDNS reflector on the firewall to bridge discovery between the two segments I cared about, which mostly works and is mildly horrible.
DHCP needed a scope per VLAN, which is fine, except I had one device with a static lease tied to the old subnet that I had completely forgotten existed until it went quiet. The fix was trivial once I found it. Finding it took an embarrassing amount of tcpdump.
A trunk port to a downstream switch was passing the wrong native VLAN, so a chunk of devices ended up untagged on a segment they had no business being on. The symptom was "some things work, some do not, intermittently", which is the worst kind of symptom. The lesson, relearned: be explicit about native VLAN on every trunk and never assume the default matches at both ends.
# the kind of explicit trunk config I should have started with
interface ether5
vlan-mode tagged
tagged-vlans 10,20,30,99
# no untagged native here on purpose
Was it worth it
Yes, but I would budget more time than I did. The actual VLAN configuration is an hour of work. The migration, the discovery breakage, the forgotten static lease, the trunk misconfiguration, that was the better part of a weekend in twenty-minute increments around not breaking the household internet.
The payoff is real though. The IoT segment is now genuinely walled off, and when I add the next questionable device it lands somewhere it can do little harm. The flat network was simpler, and simple has value, but it was simple the way leaving your front door open is simple. I will take the slightly more complex arrangement and the better night's sleep.