Home Network VLAN Guide: Segment Like a Professional

I audit networks for a living. Enterprise networks, carrier networks, and — more often than you'd think — the home networks of executives who just got phished. The single most common problem I find at home is the same one every time: a flat network. One subnet, one SSID, and 40+ devices all sitting on it together. The $12 smart plug from a brand you can't pronounce is two hops from the laptop you do your banking on. This home network VLAN guide is the fix. By the end you'll have a concrete segmentation plan, the exact UniFi configuration steps, and the firewall rules that make it actually mean something.

I run this exact setup in my own house. It's not theoretical.

Home Network Security Checklist →

Why VLANs Matter at Home

A VLAN — virtual LAN — splits one physical network into multiple logical networks. Devices on VLAN 20 can't talk to devices on VLAN 10 unless a firewall rule explicitly allows it. Same cables, same switches, same access points. Different trust zones.

Here's why that matters in a house in 2026.

The IoT problem

Count the "smart" devices in your home. Plugs, bulbs, cameras, doorbell, thermostat, TV, robot vacuum, garage door opener, the kids' game consoles. Most homes I look at have 30 to 50 of these. Almost none of them get security updates after the first year. Many of them phone home constantly — I packet-captured a $15 smart plug last year that was talking to three different servers in a region I had no business relationship with, every 30 seconds, forever.

On a flat network, any one of those devices getting compromised puts the attacker on the same subnet as your laptop, your phone, and your NAS. ARP scanning, SMB probing, credential relay — all of it works because nothing is in the way. Segmentation doesn't make the smart plug secure. It makes the smart plug's compromise irrelevant to everything you care about.

Guests

Your guests' phones have apps you didn't vet and update habits you can't control. A guest network is table stakes. A guest network on its own VLAN, with client isolation and zero access to your internal subnets, is doing it properly.

Cameras and NVRs

Security cameras are the most-compromised device category I see, full stop. Cheap cameras ship with hardcoded credentials and open telnet ports. Even good cameras don't need internet access if you record locally to an NVR — my Protect cameras have never sent a packet to the internet directly, and they never will. Cameras get their own VLAN with no internet egress at all. If you run local recording, the NVR is the only thing that needs to reach out (for remote viewing), and even that can be tightened.

UniFi Protect Camera System Guide →

Kids' devices

This one is less about attackers and more about policy. A dedicated VLAN for the kids' tablets, consoles, and laptops lets you apply content filtering, scheduled cutoffs, and DNS policies to their devices only. It also contains the fallout when a teenager installs something they shouldn't have. They will.

The Example VLAN Plan I Actually Recommend

You can over-segment. I've seen home labs with eleven VLANs, and the owner spends more time debugging firewall rules than using the network. For most homes, five or six zones is the ceiling. Here's the plan I deploy for clients and run myself:

Notes on the choices:

• VLAN 1 stays for management only. Router, switches, APs, and nothing else. No user devices on the default VLAN. This is the plane you administer everything from, so keep the population at zero beyond infrastructure.
• The VLAN ID matches the third octet. VLAN 20 is 10.0.20.0/24, VLAN 30 is 10.0.30.0/24. Six months from now, when you're staring at a firewall log at midnight, you'll thank yourself. This convention has saved me real debugging time more than once.
• "Reply-only" means established/related traffic. Your laptop on VLAN 10 can open a connection to the TV on VLAN 20, and the TV's responses come back. The TV cannot initiate a connection to your laptop. That asymmetry is the entire point, and I'll show you the rules below.
• Cameras get no internet. If a camera can't reach the internet, it can't exfiltrate footage and it can't join a botnet. Local recording only. This is my strongest opinion in this whole article.

What's overkill for most homes: separate VLANs for work devices, a DMZ for self-hosted services, a dedicated VoIP VLAN. If you know you need those, you don't need me to tell you. If you're not sure, you don't.

The Hardware You Need

VLANs require gear that speaks 802.1Q — VLAN tagging. Your ISP's combo box almost certainly doesn't, at least not in any way you'd want to manage. I standardize on UniFi for home deployments because the gateway, switches, APs, and firewall are managed from one interface, and the price-to-capability ratio is hard to argue with:

• Gateway: the UniFi Dream Machine Pro (~$379) is the workhorse. Routing, the Network controller, IDS/IPS, and a bay for a Protect hard drive in one box. For smaller homes, the UniFi Express covers the basics, but the UDM Pro is what I install when someone says "do it right."
• Switch: the UniFi Switch Lite 8 PoE (~$109) gives you eight ports, four with PoE for cameras and APs, and full VLAN support. One of these per floor or per cluster of wired devices.
• Access point: the UniFi U6 Pro (~$159) handles multiple SSIDs mapped to multiple VLANs without breaking a sweat. One AP per ~1,500 square feet is my rule of thumb, adjusted for construction.

Total for a serious three-VLAN-capable setup: roughly $650. That's less than one incident-response engagement costs per hour.

UniFi Dream Machine Review →

Creating VLANs in UniFi, Step by Step

No screenshots here, so I'll describe exactly what you'll see. This is UniFi Network 9.x on a UDM Pro; the flow is the same on any UniFi gateway.

Step 1: Create the network

1. Open the UniFi Network application and go to Settings (the gear icon in the left sidebar), then Networks. You'll see a list of your existing networks — on a fresh install, just "Default."
2. Click New Virtual Network. A panel opens with a Name field at the top. Call it something unambiguous: IoT, not Network 2.
3. Under the name, UniFi auto-assigns a Router IP/subnet. Override it. Set the gateway IP and subnet to 10.0.20.1/24 for IoT. The VLAN ID field sits alongside — set it to 20. Newer versions auto-derive the VLAN ID; check it anyway and set it explicitly to match your plan.
4. Expand Advanced (toggle from Auto to Manual). Confirm DHCP Mode is set to DHCP Server, and set the DHCP range — I use 10.0.20.100 to 10.0.20.254, which leaves .2 through .99 free for static assignments like an NVR or a hub you'll want at a fixed address.
5. While you're in Advanced: for the IoT and camera networks, leave mDNS off for now (more on that later), and for Guest, look for the Isolate Network and client isolation options.
6. Click Add (or Apply Changes). The network appears in your list with its VLAN ID and subnet shown in the row.

Repeat for VLANs 30, 40, and 50. Five minutes each.

Step 2: Understand what just happened

Creating the network does three things: the gateway now answers on 10.0.20.1, runs DHCP for that subnet, and tags traffic for VLAN 20 on its trunk ports. Every UniFi switch and AP adopted by the controller automatically carries all VLANs on its uplinks — you don't configure trunking manually, which is 80% of why I recommend UniFi to non-network-engineers.

Step 3: Assign wired ports

For wired devices — an NVR, a wired TV — go to the Ports tab under your switch in the Devices section, click the port, and set its Primary Network to the VLAN you want. That port now drops untagged traffic onto that VLAN. A camera plugged into a port set to Cameras is on 10.0.30.0/24, no camera-side configuration needed.

Firewall Rules: Where Segmentation Becomes Security

VLANs without firewall rules are just organized subnets. By default, UniFi routes between all your VLANs freely — your IoT devices can reach your LAN out of the box. The rules are the actual security control.

The Zone-Based Firewall (Network 9.0+)

UniFi shipped a zone-based firewall in Network 9.0 (early 2025), and it made this dramatically easier than the old model. Go to Settings → Security (or Policy Engine, depending on version) and you'll see a zone matrix: Internal, External, Gateway, VPN, Hotspot, DMZ, plus any zones you create.

Here's my setup:

1. Create a zone called IoT and assign the IoT and Cameras networks to it. Create a zone called Untrusted for Guest and Kids. Your Trusted LAN stays in the Internal zone.
2. In the zone matrix, click the cell where IoT (source) → Internal (destination) intersect. Set the policy to Block.
3. Leave Internal → IoT as Allow.

That's the whole trick. The zone firewall is stateful, so return traffic for connections your LAN initiates is allowed automatically as established/related — your phone can control the smart bulb, the bulb's replies get back to your phone, but the bulb can never open a connection toward your phone. One block policy, correct asymmetric behavior.

Then, for the camera network's internet cutoff: block IoT zone → External for the Cameras network specifically, or put Cameras in its own zone and block it to External outright. If you run UniFi Protect on the UDM Pro, the cameras talk to the gateway itself, which lives in the Gateway zone — that path keeps working.

The older model, if you're on Network 8.x

Before 9.0, you built this with rules under Settings → Firewall & Security → Firewall Rules on the LAN In ruleset. The classic three-rule pattern, in order:

1. Allow established/related — Action: Accept, Source: Any, Destination: Any, States: Established + Related checked. This is what lets return traffic flow.
2. Block IoT to Gateways — Action: Drop, Source: IoT network, Destination: All local gateway IPs (I keep an IP group for this). Stops IoT devices from reaching the router's management interface on other VLANs. Punch a hole above it for DNS (port 53 to the gateway) or your IoT devices lose name resolution — I've been paged for that one.
3. Block IoT to RFC1918 — Action: Drop, Source: IoT network, Destination: an address group containing 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.

Rule order matters in this model — established/related must sit above the drops. If you're on 9.0 or later, use zones instead. It's the same logic with far fewer ways to shoot yourself in the foot.

Rules I add beyond the basics

• Guest → everything internal: block. No exceptions, no printer access. Guests get internet and nothing else, plus client isolation on the SSID so guest devices can't even see each other.
• Kids → Trusted LAN: block, except the printer. One accept rule for 10.0.50.0/24 → 10.0.10.31 (printer IP) on ports 9100 and 631, above the block. Homework still prints.
• Kids → External: filtered. Point the Kids network's DHCP DNS at a filtering resolver, then block outbound port 53 and 853 from that VLAN to anything except your chosen resolver. Otherwise a console with hardcoded DNS walks straight around your filtering — most of them try.

Mapping Wi-Fi SSIDs to VLANs

Wired ports are easy. Wireless is where VLANs earn their keep, because one access point serves every zone simultaneously.

Go to Settings → WiFi and click Create New (or edit an existing SSID). Below the name and password fields there's a Network dropdown — it lists every network you created earlier. Pick IoT, and every client that joins this SSID lands on VLAN 20 and pulls a 10.0.20.x address. That's the entire mapping. The AP tags the traffic; the switch and gateway do the rest.

My SSID layout:

• Walsh → Trusted LAN (VLAN 10). WPA3, long passphrase.
• Walsh-IoT → IoT (VLAN 20). WPA2 — a lot of IoT gear still chokes on WPA3, and on this VLAN I care more about compatibility than cipher strength, because the firewall is doing the real work.
• Walsh-Guest → Guest (VLAN 40), with the Hotspot/guest portal options and client isolation enabled.
• Walsh-Kids → Kids (VLAN 50).

Four SSIDs is my ceiling per AP. Every SSID adds beacon overhead, and past four or five you'll measure the airtime cost. Cameras don't need an SSID at all if they're wired — and they should be wired; PoE is half the reason the UniFi Switch Lite 8 PoE is on my list.

The alternative to one-SSID-per-VLAN is RADIUS-assigned VLANs: one SSID, and the RADIUS server places each client on a VLAN at authentication based on identity (UniFi supports this in the SSID's RADIUS settings, with private pre-shared keys as a lighter-weight option). Elegant, but more moving parts than most homes need. I run it in offices. At home, separate SSIDs are simpler to reason about and to explain to your family.

The mDNS Problem: When Casting Breaks

Fair warning, because this generates the most support calls: the day after you segment, someone will try to cast YouTube to the TV and the TV won't show up. AirPlay, Sonos, printers, Home Assistant discovery — same story.

The cause: Chromecast and AirPlay discover devices using mDNS — multicast DNS on 224.0.0.251:5353 — and multicast doesn't cross VLAN boundaries. Your phone on VLAN 10 shouts "any Chromecasts out there?" and the shout never reaches VLAN 20. Your firewall rules would allow the streaming connection — discovery fails before it ever gets there.

The fix is an mDNS repeater, which UniFi builds in. In current Network versions it's under Settings → Networks, in each network's Advanced settings — enable Multicast DNS on the specific networks that should share discovery (older versions had a single global toggle under Advanced Features). Enable it on Trusted LAN and IoT only. The gateway then relays mDNS announcements between those two VLANs: your phone's query gets repeated into VLAN 20, the Chromecast's answer gets repeated back, and casting works. The actual video stream is your phone initiating a connection into the IoT VLAN — allowed by your LAN → IoT policy — with return traffic riding the established state.

Two rules I hold on this:

• Never enable mDNS on Guest. Guests don't need to discover your TV, and your TV definitely doesn't need to announce itself to guests.
• Don't enable it on Cameras. Nothing on that VLAN should be discoverable by anything.

If something IoT still won't behave across VLANs after mDNS relay (a few cheap ecosystems do discovery with broadcast packets instead of multicast), decide whether that gadget deserves a place on your trusted network. Usually the answer is no, and it lives with reduced function or gets returned.

A Saturday Afternoon Migration Plan

Real-world sequencing, because the order matters:

1. Inventory first. Export your client list from the UniFi controller and sort every device into a VLAN. This takes longer than the configuration will.
2. Build all networks and SSIDs, then the firewall zones and rules, before moving anything. The new SSIDs can coexist with your old flat network during migration.
3. Move the IoT devices by re-joining each to Walsh-IoT. Tedious — budget two minutes per device and a beer for after.
4. Move wired devices by reassigning switch ports.
5. Test the pairs that matter: cast to the TV, view a camera, print from a kid's laptop, join the guest SSID and confirm you can't ping 10.0.10.1.
6. Verify the blocks, not just the allows. From an IoT device (or a laptop temporarily joined to Walsh-IoT), try to reach your NAS. It should time out. A firewall rule you haven't watched fail isn't a rule — it's a hope.

While you're in there, this is also the right moment to review the rest of your wireless posture. How to Secure Your Home WiFi

The Bottom Line

Segmentation is the highest-value change most home networks will ever get. Five VLANs, one afternoon, roughly $650 in gear if you're starting from an ISP box — and the cheap camera that gets popped in 2027 hits a firewall instead of your NAS. Every home network VLAN guide should end with the same instruction, so here's mine: don't stop at creating the VLANs. The block rules are the product. Build them, test them from the untrusted side, and check the logs a week later to see what your IoT devices were trying to reach. That log review is usually the moment people stop thinking of segmentation as paranoia.

If you want a second set of eyes on your design, this is exactly the work I do at Ryno Systems.