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

carving VLANs out of a flat network without taking the house offline

A staged migration from a single flat /24 to a segmented VLAN setup at home, the mistakes that bit me, and how I avoided locking myself out.

A bundle of network cables behind a rack

Everything at home lived on one flat 192.168.1.0/24. The laptop, the servers, the printer, a dozen IoT gadgets of questionable provenance, the kids' tablets, the lot. It worked, in the sense that packets went where they were addressed. It was also a single broadcast domain where a cheap smart plug could talk directly to my NAS, and every time I thought about that I liked it less.

So I finally segmented it. Here is how it went, including the bits where I locked myself out, because that part is the actual lesson.

the plan

The target was four VLANs:

  • 10, trust: my machines, the laptop, the workstation.
  • 20, servers: NAS, the hypervisor, anything that holds data I care about.
  • 30, iot: the smart plugs, the bulbs, the telly. No outbound except what it needs, and absolutely no lateral access to anything.
  • 40, guest: internet only, isolated from everything.

The router is an old box running pfSense. The switch is a managed Netgear that does 802.1Q. The access points do multiple SSIDs mapped to VLANs. On paper it is a textbook diagram.

A simplified network diagram showing segmented VLANs

the mistake everyone makes first

I created the VLAN interfaces on pfSense, assigned subnets, set up DHCP for each, and then changed the switch port my laptop was on to be an access port for VLAN 10. At which point I lost the management interface, because the switch's own management VLAN was still untagged VLAN 1, and my laptop was now tagged into 10 with no route back to it.

Lesson one: decide what manages the switch, and never strand it. I ended up keeping a single "management" access port on VLAN 1 with a sticky label on it, plugged a laptop straight into that, and did the rest of the work from there. If you only take one thing from this post: keep one known-good way back into the kit before you touch anything, and physically label it so you do not later "tidy it up".

doing it without an outage

The trick that made this bearable was running old and new in parallel. I did not migrate the flat network in place. I built the new VLANs alongside it, with the old 192.168.1.0/24 still alive as VLAN 1, and moved devices across one group at a time.

The order mattered. I moved the least important things first.

  1. Guest and IoT first. If I broke the smart bulbs for an evening, nobody filed a complaint that mattered. This is where I found that half my IoT devices hardcode a DNS server and sulk when they cannot reach it, so the firewall rules on VLAN 30 needed a DNAT to redirect port 53 to my own resolver rather than a clean block. Good to learn that on the bulbs and not on the NAS.
  2. Servers next, with a maintenance window I actually announced to myself, because the NAS changing subnet meant every backup job, every mount, and every hardcoded IP in a script needed updating. There are always more hardcoded IPs than you think. I grepped my configs and still missed three.
  3. Trust last, the machines I do my work from, once everything they depended on was already in its new home.

Between each group I let it bake for a day. Nothing teaches you about a missed firewall rule like a service that works on Tuesday and mysteriously fails on Wednesday when its dependency moved.

inter-VLAN rules, the actual point

Segmentation with permit-any-any between VLANs is just colourful subnets. The rules are the whole exercise. Roughly what I settled on, in pfSense's pass-by-default-deny model:

# trust (10) -> can reach servers (20) on specific ports
pass in on vlan10 proto tcp to 192.168.20.0/24 port { 22 80 443 445 5000 }

# iot (30) -> internet only, no RFC1918
block in on vlan30 to { 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 }
pass  in on vlan30 to any  # everything else, i.e. the internet

# guest (40) -> internet only, identical RFC1918 block
block in on vlan40 to { 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 }
pass  in on vlan40 to any

The IoT block-then-pass ordering caught me out for an embarrassing afternoon. pfSense evaluates rules top to bottom, first match wins, so the broad RFC1918 block has to sit above the permissive internet rule or the smart telly happily chats to the NAS. Read your rule order out loud. It is faster than packet captures.

was it worth it

Yes, plainly. The smart plug can no longer see the NAS, the guest network genuinely is just the internet, and when I add a new dubious gadget I know exactly which blast radius it lands in. The cost was two evenings, one self-inflicted lockout, and the lasting habit of labelling the one cable that gets me back in. Cheap, for finally knowing what can talk to what.