Ramblings of an aging IT geek
← Ramblings of an aging IT geek
networking

carving up a flat network into vlans, the hard way

Migrating a home network from one flat /24 into segmented VLANs for trusted, IoT, and guest traffic, and all the small ways it went sideways.

Patch cables fanning out from a switch

For years my entire house lived on one flat /24. The router, the NAS, the laptops, the printer, my partner's phone, the slightly sketchy smart plug I bought to test a hunch, all of it in one broadcast domain talking to everything else with nothing in the way. It worked, in the sense that a house of cards works right up until it doesn't.

This weekend I split it into VLANs. It was more painful than I planned, entirely because of decisions past-me made, and it is now the single best thing I have done to my network. Here is how it went and where it bit me.

why segment at all

The smart plug was the trigger. I do not trust it. I do not trust most consumer IoT, not because any one device is obviously malicious but because the average smart-anything ships firmware that was abandoned the moment it left the factory. The idea that it sat on the same flat network as my NAS, free to scan and connect to anything, finally bothered me enough to act.

The plan was four segments:

  • trusted: laptops, phones, the machines I actually control.
  • servers: NAS, the homelab boxes, anything that serves.
  • iot: the smart plug and its dubious friends, allowed out to the internet, allowed nothing inward.
  • guest: visitors, internet only, isolated from the lot.

Simple on paper. The paper, as ever, was lying.

the switch and the router

My managed switch does 802.1Q tagging, so the trunk between switch and router carries all four VLANs tagged, and access ports are assigned to a single VLAN each, untagged. The router does inter-VLAN routing and, crucially, the firewall rules that decide who may talk to whom.

The mental model that finally made it click: a VLAN is just a separate wire that happens to share physical hardware. Treat each one as if it were a genuinely different network plugged into a different port, because as far as the firewall is concerned that is exactly what it is.

A network rack with tidy cabling and a managed switch

where it actually hurt

DHCP. Obvious in hindsight. The moment a device moved to a new VLAN it needed an address from a scope on that VLAN. I had one DHCP server handing out one range. So the first thing every freshly-migrated device did was fail to get an address and sulk. I stood up a scope per VLAN, each on its own subnet, and order returned. If you do this, do the DHCP first, before you move a single port.

mDNS and discovery. This is the one that nearly broke my resolve. The whole point of segmentation is that broadcast and multicast do not cross between VLANs. The whole point of half my devices is that they find each other using exactly that multicast. So the printer vanished. The Chromecast vanished. The NAS stopped appearing in Finder. Everything technically worked if you typed an IP, but nothing was discoverable, and a network where nothing is discoverable feels broken even when it isn't.

The fix is an mDNS reflector (avahi can do this) that selectively forwards discovery between the trusted and servers VLANs while leaving IoT and guest firmly out of it. It is fiddly and it slightly undermines the purity of the segmentation, but the alternative is a household revolt, and I value domestic peace.

firewall ordering. I wrote my rules, tested from a trusted machine, everything worked, declared victory. Then nothing on IoT could reach the internet. I had a default-deny at the bottom, as you should, but I had forgotten that IoT still needs DNS and DHCP from the router itself. A device that cannot resolve a name might as well be unplugged. Two small allow rules later, for DNS to the router and the established/related return traffic, and the plug was happily phoning home to whatever questionable cloud it phones home to. Isolated, but functional.

the rules that matter

The shape of the policy, in plain English, ended up as:

trusted  -> any            allow
servers  -> internet       allow
servers  -> trusted        deny (default)
iot      -> internet       allow
iot      -> everything     deny
guest    -> internet       allow
guest    -> everything     deny
any      -> servers:443    allow from trusted only

The asymmetry is the point. Trusted reaches in to servers; servers do not reach back out to trusted unless I explicitly say so. IoT and guest are sandboxes with a single door to the internet and nothing else. The moment I had that written down and enforced, the smart plug stopped being something I worried about and became something I simply did not have to think about.

One detail that paid off later: I logged the default-deny rules rather than silently dropping. The first week after the migration, every time something did not work, the firewall log told me exactly which VLAN had tried to reach which thing and been refused. That turned a dozen mystery faults into ten-second diagnoses. Once the network settled I turned the logging back down, but during a migration it is the difference between debugging with the lights on and debugging by feel.

was it worth the weekend

Completely. The migration was a comedy of small omissions, every one of them mine, and none of them hard once spotted. But the end state is a network where a compromised toy cannot see my files, a guest cannot stumble onto my infrastructure, and I can reason about traffic instead of hoping for the best.

If I did it again I would change the order: DHCP scopes first, then discovery reflection, then move devices a VLAN at a time and confirm each one before touching the next. I did it the other way round, which is to say I did it wrong, and the network spent an afternoon in a state best described as "loud". It is quiet now, in every sense that counts.