I have a little over 80 WiFi devices in this house — plugs, bulbs, cameras, ESP32 boards, a robot vacuum, two thermostats, and a depressing number of things that have no business being on the internet but insist on trying. For the first couple of years they all sat on the same flat network as my laptops, phones, and the NAS that holds every photo my family has ever taken.
That arrangement bothered me for a long time before I did anything about it, which I suspect is the normal sequence. This post is the segmentation setup I eventually built on UniFi, the things that broke immediately, the mDNS rabbit hole, and a candid accounting of whether it was worth it.
Why bother segmenting at all
Three reasons, in the order they actually motivated me:
I wanted to see what was phoning home. Before segmentation, IoT traffic was mixed into everything else and effectively invisible. Once the devices were on their own network, the UniFi traffic stats became legible: one brand of smart plug was making DNS lookups every 15 seconds, around 5,700 a day, per plug. A cheap camera I’d retired to a closet shelf — but not unplugged — was still attempting connections to a CDN in another country. You don’t un-see that.
Blast radius. The realistic threat isn’t a movie-style hacker targeting my house. It’s that one of these devices ships with a vulnerable firmware, gets swept up in a botnet, and starts scanning whatever network it sits on. On a flat network, “whatever network it sits on” includes the NAS, the laptops, and every unlocked service I run. On a segmented network it includes 80 other IoT devices and nothing else.
Chatty devices degrade the network for everything else. This one surprised me. A handful of devices doing constant multicast and broadcast traffic is background noise at 10 devices and a real airtime tax at 80. Moving them to their own SSID let me tune that network differently (more on that below) without punishing the devices I actually care about being fast.
The network layout
The design is boring, which is the point:
| Network | VLAN | Who lives here |
|---|---|---|
| Default / Trusted | 1 | Laptops, phones, NAS, Home Assistant |
| IoT | 20 | All 80+ smart devices |
| Cameras | 30 | PoE cameras, NVR traffic |
| Guest | 40 | Visitors, kids’ friends’ devices |
Two decisions worth calling out:
Home Assistant lives on the trusted LAN, not the IoT VLAN. You’ll see people put HA on the IoT network “with the devices it talks to.” I think that’s backwards. HA is the most trusted, most capable box in the whole system — it holds credentials for everything. It belongs on the trusted side, reaching into the IoT VLAN through firewall rules, not sitting among the devices it supervises.
Cameras got their own VLAN, not the IoT one. Camera traffic is high-bandwidth, continuous, and the devices themselves are the sketchiest hardware in the house. Splitting them out means I can give the camera VLAN zero internet access without writing exceptions, and their traffic doesn’t drown out the stats for everything else.
Each VLAN gets its own SSID. Yes, that’s three SSIDs plus guest. The IoT SSID is locked to 2.4GHz and WPA2 (not WPA3 — more devices choke on WPA3 than you’d hope in 2026), with band steering off and minimum data rates left conservative, because a $12 plug with a terrible radio doesn’t respond well to aggressive airtime policies.
The firewall rules that make it work
The core policy is one sentence: trusted can reach IoT, IoT cannot reach trusted, and established connections can answer back.
In UniFi’s zone-based firewall this comes out to roughly:
1. ALLOW LAN (Trusted) → IoT # HA, laptops can reach devices
2. ALLOW IoT → LAN (established/related only)
3. ALLOW IoT → IoT # devices can talk to each other
4. BLOCK IoT → LAN # everything else, dropped
5. BLOCK IoT → Gateways/Router UI # no config pages for youRule 2 is the one people miss, and its absence produces the most confusing failure mode I hit: HA could send a command to a device (rule 1 allows the outbound packet), the device would turn on, and then its state in HA would show unavailable — because the return traffic and the device-initiated updates were being dropped by rule 4. Lights that obeyed commands while showing as dead in the dashboard. If you see that exact symptom, it’s your established/related rule.
The order matters. Allow rules before block rules, and the “block IoT from reaching the gateway’s management interfaces” rule earns its place the first time you realize your smart TV can otherwise browse to your router’s login page.
ESPHome devices deserve a specific note: the ESPHome native API is HA-initiated — HA opens a TCP connection to port 6053 on the device. That flows through rule 1 and works with no special handling. If I were running MQTT instead, the devices would be initiating connections toward a broker; if that broker sits on the trusted LAN you’d need a pinhole rule for port 1883. All 5 of my ESP32 builds worked unmodified after segmentation, which was a pleasant surprise in a weekend that didn’t contain many.
mDNS: where the weekend actually went
Everything above took about two hours. Multicast discovery took the rest of the weekend.
mDNS (the thing behind Chromecast discovery, HomeKit, AirPlay, and ESPHome’s .local hostnames) is link-local by design. It does not cross VLANs. The moment I moved devices, every phone in the house lost the ability to cast, and my wife’s opinion of the project was registered and logged.
UniFi’s answer is mDNS reflection (Settings → Networks → Multicast DNS, per-network toggles depending on your Network application version). Turn it on for the pair of networks that need to discover each other, and the gateway repeats mDNS announcements across them. Three quirks I learned the slow way:
-
Reflection is not instant or reliable for every service type. Chromecasts became castable within seconds. HomeKit devices took multiple announce cycles — sometimes a minute — to show up after a restart. If discovery seems broken, wait before you start changing settings, or you’ll be debugging two changes at once.
-
Reflection announces the device, but the follow-up connection still needs a firewall path. Discovery tells your phone the Chromecast exists at some IP; the actual cast session is a unicast connection to ports 8008–8009. Phone is on trusted, Chromecast on IoT, rule 1 allows it. But if you’re trying to make guest network casting work, you need both reflection and an allow rule from guest to those specific hosts — and at that point I decided guests can be told the WiFi password for the IoT network’s Chromecast or live without it.
-
Don’t reflect more than you need. My first attempt turned on mDNS everywhere, and the trusted network’s service browser filled with 80 devices’ worth of announcements — exactly the multicast chatter I was trying to contain. Reflect between the two networks that need it and leave the camera and guest VLANs out of it.
ESPHome’s .local hostnames stopped resolving from my laptop until reflection was on. HA itself never noticed, because I add ESPHome devices by static IP, which brings me to: give every IoT device a fixed IP reservation. When discovery is flaky — and cross-VLAN, it will occasionally be — static addressing is what keeps the automation layer indifferent to it.
Who gets internet, and who doesn’t
Segmentation made a second policy possible: per-group internet access. Roughly a third of my IoT devices have no internet access at all, enforced by a block rule on a UniFi device group.
Blocked entirely, works perfectly: all ESPHome boards (local API only), Zigbee and Z-Wave devices never touch IP anyway, the robot vacuum (runs fine after setup; its map lives on the device), most smart plugs after their firmware is current, and the retired-camera-in-a-closet, permanently.
Needs internet, grudgingly: the thermostats (cloud API is the only integration path), the doorbell (ditto), anything with a voice assistant in it, and the TV — which technically works offline but degrades into nagging.
The test method: block the device, use it normally for a week, see what breaks. The failure modes are usually loud (app shows device offline) or silent-but-fine (device keeps doing local automation and simply stops reporting to its mothership, which is the goal). One brand of plug did a factory reset sulk after two weeks without its cloud — that brand got replaced with ESPHome-flashable hardware over the following months rather than given its internet back.
What it actually bought me
Real observability. I can open one screen and see exactly which IoT device is talking, how much, and to where. The DNS-every-15-seconds plug got firmware-updated into decency; the mystery CDN camera got unplugged.
A meaningful security boundary. A compromised bulb can now scan 80 other bulbs. The NAS, the laptops, the HA credentials — different network, default-deny.
A calmer trusted network. Multicast noise from the device swarm stays on the IoT side. The difference isn’t dramatic on a wired laptop; it’s noticeable on busy WiFi evenings.
Cleaner WiFi tuning. IoT SSID tuned for cheap 2.4GHz radios, trusted SSID tuned for throughput. Before segmentation those goals fought each other on one network.
What it costs, honestly
Every device onboarding got slower. New device setup apps assume your phone and the device share a network. The dance is now: join phone to IoT SSID, run setup, assign the IP reservation, move phone back. Five extra minutes, every device, forever. With 80+ devices and a steady churn of replacements, this is the tax I feel most.
Cloud-first devices misbehave in creative ways. Devices that assume phone-and-device-on-same-LAN for ongoing control (not just setup) either need the phone app to fall back to cloud relay — slower, sometimes broken — or need a firewall exception. I keep a short, documented list of pinhole rules and I audit it when I’m bored. It has never gotten shorter.
You will debug discovery again. Every UniFi Network application update, I check casting still works. It usually does. The two times it didn’t, the fix was toggling mDNS reflection off and on, which is not a sentence that inspires confidence, but there it is.
Complexity has a maintenance cost. The firewall rules, the reservations, the device groups — that’s all state that lives in my head and a notes file. Flat networks have no such file.
Would I do it again
Yes, without hesitation — but I’d do it in one weekend instead of letting it sprawl, and I’d write the device inventory first. The single most useful artifact from the whole project isn’t a firewall rule; it’s the spreadsheet of every device, its MAC, its reserved IP, and whether it needs internet. Segmentation forced me to make one. The network is better for the VLANs; I’m better for finally knowing what’s actually in my house.
If you’re on the fence: start with just two networks, trusted and IoT, with the three rules from above. Cameras-on-their-own-VLAN and per-device internet policies can come later. The 80/20 of the whole project is IoT-can’t-reach-LAN plus established/related — an afternoon of work, most of a flat network’s risk retired.
Related guides: Layered home security in HA · Fixing an unreliable Zigbee mesh · Monitoring the smart home with Uptime Kuma