← all writing

Designing a five-VLAN home network from scratch

The first time I looked at my home network's DNS query log, my IP cameras were phoning home to servers in three different countries every few minutes. Each camera had a microphone. Each camera had a video feed. Each camera was trustingly reporting to whoever its manufacturer's cloud provider had sold it to that month. I had bought the cameras for security. They were doing the opposite.

That was the moment I stopped tolerating a flat home network.

Before segmenting, every device on my LAN sat on the same subnet — my work laptop next to the kids' tablets, the cameras-with-microphones next to the document server, and any guest who had the WiFi password sitting on the same network as everything else. A compromised smart plug could have reached the server with my tax returns. A guest could have wandered into the camera feeds.

This is how I segmented it. Five VLANs, off-the-shelf hardware, and a clear principle for what each tier is allowed to do.

#The trust-decreasing tier

The whole architecture follows one rule: trust decreases as the VLAN number increases. The lower the number, the more privileged the access. The higher the number, the more isolated the device.

The Main LAN is the management plane — that's where the trusted devices, the Home Assistant host, the file server, and the firewall management interface live. Every other tier is reasoned about as "what does this device need access to in order to function, and not one byte more."

Cameras have zero network access. Not the internet. Not other VLANs. Not even DNS. They sit in their isolated subnet and the camera management system on the Main LAN initiates RTSP connections to them. The stateful firewall allows the return traffic because the connection originated from a trusted side. If a camera is compromised, it cannot exfiltrate anything because it cannot reach anything.

That's the whole concept. The five-tier model is just an organized way of applying it.

#The hardware budget

You do not need an enterprise switch and a full-time network engineer to do this. The full setup runs on three pieces of off-the-shelf gear that punch above their price together:

• A small fanless pfSense firewall that handles routing, DHCP, DNS forwarding, firewall rules, and VPN endpoints
• A managed PoE switch with 802.1Q VLAN trunking
• A single WiFi 6 access point that supports multi-SSID with per-SSID VLAN tagging

All-in, somewhere under a thousand dollars in hardware. Compare that to the Cisco Meraki license-and-hardware bundle for similar capability and you're saving roughly an order of magnitude.

The piece that surprised me was the AP. One physical access point can broadcast multiple SSIDs, each tagged to a different VLAN. The IoT devices join one SSID, the kids' devices join another, the guests join a third — and the AP transparently puts each one on the right VLAN. From the user's perspective there are several networks; from the hardware's perspective there's one box doing the multiplexing.

#The firewall rules that actually matter

VLAN tags by themselves don't secure anything. They just label traffic. The firewall is what enforces the policy.

A few rules matter more than the others.

The cameras get an unconditional outbound block. Not just to other VLANs — to the internet. Any block rule that allows internet access for cameras defeats the entire point. The camera vendor's "cloud features" are exactly the cloud features I bought the cameras to not use.

Specific allows always come before broad blocks. Each downstream VLAN gets one or two narrow allow rules — "IoT can reach the Home Assistant IP on the smart-home control port" — followed by a broad block to the rest of the LAN. The order matters. The firewall evaluates rules top-down, and if the broad block fires first, the allow never gets a chance.

The kids' VLAN forces DNS through one specific server. Any kid (or any phone) that knows about 8.8.8.8 or 1.1.1.1 can bypass DNS-level content filtering by setting an alternate DNS in their device settings. The fix is at the firewall: allow DNS only to the filtering server, block all other DNS traffic. The bypass is impossible at the network layer, regardless of what's set on the device.

That third one is the most underrated network rule in home filtering setups. Most people set up content filtering on a DNS server and stop there. Without the firewall block, every smart kid eventually defeats it in an afternoon.

#DNS as a control plane

DNS-level filtering does more than block ad networks.

The DNS server I run for the whole network supports per-client filtering policies — different rules based on which subnet the request came from. The Main LAN gets light filtering (just ad networks and known malware). The IoT subnet gets no filtering, but every query is logged. The Kids subnet gets aggressive filtering with parental controls. The Guest subnet gets the same default as the Main LAN.

The IoT logging turned out to be the most useful piece. I'm not blocking the smart devices' queries — I'm watching them. Which domains they contact, how often, what changes when I plug in a new piece of hardware. I caught one device pinging an analytics endpoint every fifteen seconds, and another silently retrying a hard-coded DNS server my IoT VLAN doesn't allow it to reach. That second one is now on the do-not-buy list for replacements.

DNS is the cheapest possible network observability. Most people don't think of it as monitoring at all.

#Cameras need to be locked in a closet

The single most worth-it decision in the whole project was full camera isolation.

Before isolation, the cameras were contacting servers in places I had no business sending audio and video. Random IP addresses. Hardcoded DNS lookups for vendor cloud endpoints. Some of them tried to use UPnP to punch through my firewall and open ports automatically. I am not exaggerating when I say the cameras tried harder to reach the internet than my work laptop did.

After isolation — no internet, no cross-VLAN traffic, no exceptions — the cameras work fine. The local management system streams the RTSP feeds. The doorbell rings. The motion alerts fire. The features I actually paid for all work, because they don't require a vendor cloud to function. The features I didn't want — telemetry, "smart features" that learn about my household, firmware updates served over plaintext HTTP — all stop working, because they can't reach anything.

If you take one thing from a network segmentation project, take this: IP cameras should never have internet access. Treat them as untrusted devices in your house. Lock them in a closet, network-wise, and connect to them on your own terms.

#Configuration as code, even at home

A pfSense firewall has hundreds of settings. VLAN interfaces, DHCP scopes, static reservations, firewall rules, DNS host overrides, per-client filtering policies, switch port assignments. Every one of those is a click in a web UI somewhere.

I wrote shell scripts that define all of it as code. The scripts live in version control. If the firewall hardware fails tomorrow, I can rebuild the entire configuration from the repo on a fresh box in an evening. Every change is a commit. Every commit is a reason.

This is the same infrastructure-as-code principle enterprises apply with Terraform — just expressed in pfSense's configuration formats. The point isn't that pfSense is special. The point is that complex networks should not live in the brittle memory of a tired admin clicking through a browser tab at midnight. Either the configuration is in version control, or it's a single bad click away from gone.

#What I learned

Defense in depth isn't a slogan. VLANs separate traffic. Firewall rules enforce policy. DNS adds content filtering. WiFi client isolation prevents lateral movement on the guest network. None of these alone secures anything. Together they make a network where compromising one device gets the attacker nowhere interesting.

Design for the least trusted device. The right question isn't "what does this device need to access?" It's "what's the minimum access this device needs in order to function?" Start from zero and add only what's required. The vacuum needs internet for firmware updates. It does not need access to the file server. The thermostat needs to talk to the smart-home hub. It does not need to make outbound connections to a vendor cloud.

Cameras are the highest-leverage isolation target. Of every device class on a typical home network, the cameras are the most likely to be a privacy disaster, the most likely to have an unpatched CVE, and the most likely to be silently exfiltrating data you didn't authorize. Total isolation is non-negotiable. Everything else can be argued. Cameras can't.

The bypass-resistant DNS rule is the one most setups miss. You can run the most aggressive AdGuard or Pi-hole policy in the world. It's worth nothing the first time a teenager (or a poorly-configured smart device) sets a different DNS server. The firewall rule that forces all DNS to your server is the rule that turns your filtering from advisory into mandatory.

A flat home network in 2026 is a bad default. Routers have shipped with unsegmented LANs for twenty years. Smart devices have shipped with internet-everything assumptions for ten. The combination is a security model that wasn't designed; it's a security model that nobody bothered to design. Five VLANs, one weekend, off-the-shelf gear. There's no good reason not to.

#The result

Every device class is isolated. Cameras can't phone home. Kids get filtering they can't bypass. Guests get internet and nothing else. IoT devices are watched but functional. The whole configuration is reproducible from version-controlled scripts.

Total cost: under a thousand dollars in hardware. Time investment: a few weekends for planning, scripting, testing, and the inevitable "why is the printer offline now" round of debugging.

The security improvement is significant and permanent. The operational complexity, after the initial setup, is approximately zero. The cameras are still locked in their closet, network-wise, and will stay there as long as they're plugged in.

← all writing