Home Network Segmentation: VLANs for Cameras and IoT

Camera firmware updates are a roll of the dice, smart bulbs live on the vendor's cloud, and guests ask for the Wi-Fi password on arrival — and all of it was sitting in the same L2 domain as my NAS and my computers. The more I thought about it, the less I liked it. VLANs aren't enterprise-only; three segments are plenty for a home. This post follows the real migration order — from a page of principles, to trunking, to moving devices and the "why is the printer suddenly gone" fallout — instead of leading with a vendor model list.

Phase Zero: Write the Principles, Don't Touch a Cable

Before touching anything, I pinned four rules into the notes. Every firewall rule since then is checked against these, not against whatever was in a shopping cart one afternoon:

1. IoT cannot reach the trusted segment by default.
2. Trusted clients may reach IoT on demand (manage cameras, water the plants).
3. Guests get internet only — no NAS, no management addresses.
4. All segments get internet; DNS points at our own AdGuard where possible.

Models change; principles don't. A lot of tutorials lead with a switch port diagram but never say "who's allowed to talk to whom," and the rule table grows into spaghetti.

The target logical topology also got finalized in this phase: VLAN 10 trusted (computers, phones, NAS management), VLAN 20 IoT/cameras, VLAN 30 guests. The gateway is OpenWrt or any router that supports VLANs; the switch does 802.1Q; the AP maps multiple SSIDs onto different VLANs.

Phase One: Router and Switch — Reachable First, Strict Later

Saturday morning, infrastructure only. Three VLAN interfaces and DHCP pools on the router, with non-overlapping subnets, and the management interface staying on the segment I already knew — so I didn't lock myself out. The switch uplink got trunked with 10/20/30 allowed; the AP port trunked the same way; wired computer ports stayed access on VLAN 10. Don't trunk everything just because it's less typing.

Firewall rules can stay loose in this phase — the goal is just three networks with internet and a reachable gateway, so a laptop hopping between SSIDs can verify DHCP and egress. Loose is temporary; the notes got a line saying "phase one egress policy needs tightening," so the loose rules don't survive the night and become permanent.

Phase Two: Wireless SSIDs and a "Spare Devices" Pilot

Created SSIDs "IoT" and "Guest", bound to VLAN 20 and 30. Then I tossed my old tablet and a spare phone into the IoT network and checked: internet works, default route and DNS are right, and IoT can't ping the NAS management address (rules permitting). The guest network got the isolation option enabled, blocking client-to-client traffic, per AP capabilities.

A pilot's whole point is letting low-stakes, cheap devices surface the problems: do you want a captive portal, is speed being throttled by mistake, does IPv6 bypass rules you only wrote for IPv4. If you don't have IPv6 under control yet, turn it off on that SSID for now — otherwise you get "isolated on v4, naked on v6."

Phase Three: Moving Cameras and the NVR

Cameras moved one at a time to the IoT SSID or an IoT wired port, with the stream confirmed in Frigate/NVR after each one. The firewall tightened to steady state in this phase: IoT → trusted denied by default; trusted → IoT allows only necessary ports (camera HTTP/RTSP, as minimal as reality allows); IoT → internet allowed, but outbound 53 can be restricted to AdGuard only, cutting down hardcoded DNS workarounds.

Don't kick every camera offline on a Saturday afternoon and then debug for two hours. Pick a window when nobody's watching a recording back, and keep one camera on the old network as a control — a reference that still works when something breaks.

Phase Four: The Printer, Screen Mirroring, and the Broadcast Bill

Cross-VLAN, mDNS/broadcast discovery breaks: AirPlay, some printers, smart-speaker "find devices" all fail. That's not proof you misconfigured something; it's the bill for isolation. Handling strategy, in priority order:

• Put the printer on the trusted network, or accept "trusted devices add it by IP and print."
• Screen-mirroring devices and the TV share a segment.
• Don't re-bridge IoT and trusted into one broadcast domain just for perfect zero-config.

If you insist on mDNS reflection, know that you're re-poking holes — write rules finer than "allow all 5353", or the isolation is isolation in name only.

Phase Five: Watch for a Week Before Touching Critical Devices

Critical computers and the NAS management plane moved last — or never left VLAN 10; only the things that shouldn't be trusted moved out. The observation week tracks three things: whether weird overnight outbound traffic from IoT dropped, whether a guest code is safe to hand out, and how much of the family's complaints are real breakage versus habit (the TV needs one re-pair after an SSID change).

On the DNS side: DHCP hands out AdGuard on every segment; switch port roles are fixed — APs trunk, endpoints access — and the final diagram goes into the docs. The phase log keeps "which rule I loosened and when," so a week later I can check that no temporary hole was left open. How it feels afterward: the sampling traffic scanning my cameras can't reach the NAS segment, and handing out a guest password no longer gives me pause. Complexity went up a notch; in exchange, the attack surface got layered. Home security rarely comes from one magic device; it comes from not keeping every egg in one broadcast domain. And the migration actually lands because it was phased — not one Saturday gamble.