This is the first guide in the home lab series, and it starts with the network because everything else sits on top of it.
Fair warning: this is not a clean-slate build from a diagram. My network grew over several moves, a piece of gear at a time, and I am still pulling it together. That is how most home networks actually get built, so this guide shows where it stands today, what broke, and what I am fixing next.
What you are building
One router, one ISP connection, and three separate networks that cannot see each other unless you say so:
- Home: everything hardwired, including the Home Assistant server.
- Work: the work computer only. Internet access and nothing else.
- IoT: smart plugs, bulbs, cameras, and the rest of the gadgets, on their own Wi-Fi network. Internet access plus the Home Assistant server, and nothing else.
The smart TVs get no network access at all.
The idea is simple. Cheap smart devices get the fewest security updates, so they get the least access. If one gets compromised, it can reach the internet and Home Assistant, not your laptop or your work machine.
Parts list
- UniFi Cloud Gateway Max: router, firewall, and the UniFi controller in one box.
- UniFi USW Lite 8 PoE: the main switch. Powers devices over the network cable.
- UniFi US 8 60W: an older PoE switch. Read the “what broke” section before you buy one of these for access points.
- 2x UniFi U7 Pro: Wi-Fi 7 access points, powered over Ethernet.
Total: roughly $1,000, bought over time. You do not need all of this to start. A gateway and one access point will get you VLANs and separate Wi-Fi networks.
Step 1: Get rid of double NAT
Most ISP gateways are a router too. Plug your own router in behind it and you get two layers of NAT: two routers, two firewalls, and port forwarding that breaks in confusing ways.
The fix is to put the ISP gateway in IP passthrough mode, so it hands the public IP straight to your router and gets out of the way. Look for it in the gateway’s admin page under the firewall or WAN settings. Depending on the ISP it may be called IP passthrough, bridge mode, or modem mode, and some gateways ask you to pick your router’s MAC address as the passthrough device. Search your gateway model plus “IP passthrough” for the exact steps.
While you are in there, turn off the ISP gateway’s own Wi-Fi. I did, so it is not competing with the access points or handing out a fourth network nobody manages.
Step 2: Create the VLANs
In the UniFi Network app, under Settings and then Networks, create a new virtual network for each segment. Your default network can stay as Home. Give Work and IoT their own VLAN IDs, for example 10 and 30. The number does not matter much. Being consistent does.
Step 3: Map Wi-Fi to VLANs
Under Settings and then WiFi, create a dedicated SSID for IoT devices and set its network to the IoT VLAN. Anything that joins that Wi-Fi network lands on IoT automatically, which makes onboarding new gadgets easy.
Step 4: Lock it down with firewall rules
VLANs by themselves only separate traffic. The firewall decides what can cross between them. The rules here:
- Work: allow internet. Block everything else.
- IoT: allow internet. Allow the Home Assistant server. Block everything else.
- Smart TVs: block all network access.
Every wired device on my Home network has a static IP, including the Home Assistant server. At a minimum, give HA a fixed IP before you write the IoT rule. If its address changes, the rule silently stops matching and your automations break.
Building the rules on the zone-based firewall
Current versions of UniFi Network use a zone-based firewall. Networks are grouped into zones, and policies control traffic between them. Out of the box, every regular network lands in the Internal zone, and networks in the same zone can talk to each other freely. That default is exactly what you are trying to undo.
You can give IoT and Work their own custom zones, but I kept all three networks in Internal and used block policies with specific sources and destinations. It keeps everything in one place in the policy list. Create these policies from Internal to Internal:
- Allow IoT to Home Assistant. Source: the IoT network. Destination: the Home Assistant server. Action: Allow. Turn on the option to automatically allow return traffic.
- Block IoT from everything else internal. Source: the IoT network. Destination: Internal, any. Action: Block. Connection state: New and Invalid.
- Block Work from everything internal. Source: the Work network. Destination: Internal, any. Action: Block. Connection state: New and Invalid.
- Block everything internal from Work. Source: Internal, any. Destination: the Work network. Action: Block. Connection state: New and Invalid.
Internet access is allowed by default, so IoT and Work can still reach the internet without an extra policy. For the smart TVs, add one more policy with the TVs as the source device and External as the destination, set to Block.
Two things that trip people up. First, policies are checked top to bottom, so the allow policy for Home Assistant has to sit above the IoT block. Second, set block policies to New and Invalid, not All. Blocking New stops IoT devices from starting connections into your network, but still lets them answer when Home Assistant talks to them. Blocking All kills those replies too, and your automations quietly stop working.
UniFi moves menus around between releases, so labels may not match word for word. The policies are what matter.
What broke
A PoE switch that cooks itself
I needed a switch fast, so I bought the US 8 60W without checking the specs. It does power one of the U7 Pro access points, but the load is more than it wants to carry. The switch overheats and shuts down on thermal protection, and that access point drops with it. Until the switch trips, the access point runs fine, which makes it a confusing problem to chase.
The lesson: before buying a PoE switch, check two numbers. The PoE standard per port (802.3af, 802.3at/PoE+, or 802.3bt) and the total power budget. Add up what your devices draw at maximum and leave headroom. A U7 Pro calls for PoE+.
IoT control is a pain
Most of my IoT devices can only be controlled from the IoT network. Right now that means switching my phone over to the IoT Wi-Fi when I need to change something, then switching back. It works, but it is clunky.
The firewall is not the cause. Home is allowed to reach IoT. The problem is discovery: most vendor apps find devices by broadcasting or multicasting on the local network, and that traffic does not cross from one VLAN to another. The app on the Home network never hears the devices answer, so it acts like they do not exist.
No DNS filtering right now
My Pi-hole is down after an SD card failure, so every network is using public DNS for now. The rebuild is the next guide.
What is next
- Fix the overheating switch. Options: move the second access point to the Lite 8 PoE (it has PoE+ ports and enough budget for two U7 Pros), put a PoE+ injector in front of it, or replace the US 8 60W.
- Stop switching Wi-Fi networks. Two fixes. Turn on mDNS for the Home and IoT networks in UniFi’s network settings so apps can discover devices across VLANs. That covers anything using mDNS, like Apple devices, but not every vendor app. The fix that covers everything is controlling the devices through the Home Assistant app, since HA already talks to all of them.
- Bring back DNS filtering. Rebuild the Pi-hole, then add a firewall exception so IoT devices can use it.
I will cover the fixes in a follow-up post and link it here.
What this teaches for an IT job
This one small network covers a big chunk of Network+ and day-one sysadmin work:
- VLANs and network segmentation
- Firewall rules and least privilege access
- NAT, and why double NAT causes problems
- PoE standards and power budgets
- Static IP addressing
On a resume, under Projects:
Home network segmentation (UniFi): Designed a three-VLAN network separating home, work, and IoT traffic. Wrote least-privilege firewall policies restricting IoT devices to internet and home automation access only. Eliminated double NAT by configuring the ISP gateway in IP passthrough mode.
That is a real project with real decisions behind it, and you can talk about every line of it in an interview.
Leave a Reply