IoT VLAN vs a Flat LAN with Pi-hole: What Isolation Actually Breaks in Home Assistant

A flat LAN plus Pi-hole is how most Home Assistant houses start. Everything can see everything. Discovery works. Cast works. The cheap camera can phone home and also scan your NAS. An IoT VLAN is how you stop the second sentence. It is also how you break the first three unless you punch holes you can name. Isolation is not a checkbox. It is a list of protocols Home Assistant assumed were local.

I have run both. I still isolate cameras and random Wi-Fi junk. I do not isolate the Zigbee coordinator from HA. I do not pretend mDNS will cross a firewall because a blog said “just enable reflector.” This is what actually breaks, and what I leave flat on purpose.

What Pi-hole does not isolate

Pi-hole filters names. It does not stop a bulb from TCP-scanning 445. A flat LAN with gravity lists is cleaner browsing, not a security domain. People pair them in their head because both feel like “I took control.” They are different layers. You can have Pi-hole on a flat LAN. You can have VLANs with the ISP resolver. You can have both. Pi-hole on the IoT VLAN only, with laptops on a clean VLAN using another resolver, is a coherent design. Pi-hole as a substitute for VLANs is not. Guests are the easier isolation story: a guest VLAN does not have to keep Home Assistant discovery alive.

What Home Assistant loses when you split

Discovery. SSDP, mDNS, DHCP discovery, and vendor sprays expect one broadcast domain. Across VLANs they die unless you reflect, route multicast, or set static IPs and integrations by address. Cast, some vacuums, some printers, and a lot of “works with HA” first-run flows assume flat. The integration may work after you type an IP. The happy path will not.

Voice and media. Speakers that need to be found every boot will flake. A media player that resolved via mDNS will go unavailable after a DHCP change the reflector missed. I put speakers on the trusted LAN or I accept static configuration and less magic.

Firmware and apps. Vendor apps on your phone (trusted VLAN) talking to a device (IoT VLAN) need a path. If you block IoT-to-LAN and forget LAN-to-IoT for those ports, the app is “broken” and you will disable isolation to finish a firmware update. Write the exception. Time-box it if you can.

NTP, DNS, and the internet. IoT should reach a DNS you control and maybe NTP. It should not reach your NAS. Allowing 53 to Pi-hole and 443 to the world while denying 22/445/139 to LAN is the usual skeleton. Devices that need peer-to-peer to a phone on LAN will still surprise you. Matter and Thread add IPv6 requirements that a v4-only inter-VLAN ACL will silently drop.

A split that does not make HA miserable

Trusted LAN: laptops, phones, HA, Pi-hole, the Zigbee/Thread coordinator, printers you like. IoT VLAN: Wi-Fi bulbs you do not trust, cameras, plugs from brands you cannot spell. Guest: no HA, no Pi-hole gravity if you do not want to support visitors.

HA needs to initiate to IoT. IoT should not initiate to HA except the few webhooks you chose. That asymmetry is the whole point. Stateful firewalls do this if you allow LAN-to-IoT and deny the reverse. Discovery still needs help: avahi reflector or static entries. I prefer static for cameras and I live with worse UX on the rest.

Pi-hole: put it on trusted, give IoT a DHCP DNS of that IP, allow 53 from IoT to Pi-hole only. Do not give IoT 1.1.1.1 as secondary unless you accept unfiltered escape. Same rule as the earlier Pi-hole piece, now with a VLAN story.

Do not put HA on IoT “so discovery works.” You just moved the crown jewel onto the junk network. Do not put the coordinator on IoT and HA on trusted without a route. The coordinator is HA’s radio. It is not a lightbulb.

Pi-hole as a weapon and as a crutch

On IoT, blocking cloud names can brick a device that needs a vendor login every week. That is a feature if you wanted local-only. It is an outage if you did not. Use a group in Pi-hole for IoT clients with a harsher list, and a milder group for laptops. Client groups need DHCP names that stay stable. Reservations help. If every plug is “ESP-1234” that changes, your groups are fiction.

Do not use Pi-hole to “isolate” by sinking internal hostnames. A camera that cannot resolve nas.lan can still hit the NAS by IP if the route exists. DNS is not a firewall. I have seen that design in a screenshot with pride. The scan did not need the name.

What I still leave flat

A studio apartment with five devices and a Pi. VLANs are a hobby tax. Pi-hole plus a guest SSID on the AP is enough. A house with cameras that have a history of being trash: isolate the cameras even if the bulbs stay flat. Isolation is per risk, not per aesthetic.

Zigbee and Z-Wave do not need an IoT VLAN. Their radios are not IPv4. The Ethernet coordinator does. People VLAN “all smart home” and then trap the SLZB. Read the packet path.

IPv6 will ignore your pretty v4 rules

You built deny-IoT-to-LAN in iptables for 192.168.10.0/24 and you feel finished. Devices still have GUA or ULA addresses. Home Assistant on v6 can be reachable in ways your v4 diagram never showed. Matter wants v6. Thread border routers want v6. If you do not firewall IPv6 with the same story, you have a guest badge on v4 and an open atrium on v6.

Either run IoT as v4-only and prove RA is off on that VLAN, or write the v6 ACLs. Half-stacks are how “isolation did nothing” reports start. I have been that report.

Pi-hole must advertise on the VLAN’s DHCP and, if v6 is on, in RDNSS. Otherwise IoT uses the ISP resolver and your gravity list is a suggestion. This is the same leak as the flat-LAN piece, now with two scopes to get wrong.

Cameras are the reason to bother

A Wi-Fi bulb is annoying if it is owned. A camera is a microphone and a stream. Isolate cameras even if you leave bulbs on trusted. Give HA a unicast path to RTSP. Do not give the camera a path to the NAS or to phones except through HA or a viewer you chose. Vendor clouds will want 443 out. That is a different argument. You can block cloud and keep RTSP if the camera allows it. Many do not. Then you are choosing isolation versus features, not isolation versus HA.

NVRs that sit on trusted and pull from IoT are a clean pattern. NVRs on IoT that your laptop must browse are how you add another hole. Put the viewer on trusted.

Debugging isolation without turning it off

When a device “does not work,” tcpdump on HA and on the firewall. See whether the packet leaves, whether it arrives, whether the return is blocked. Ninety percent of my tickets were deny-back or multicast. Ten percent were “I put the phone on IoT to test.”

Keep a documented hole list. If the list grows every week, you are recreating a flat LAN with more steps. Collapse the tame devices back to trusted. Leave the cameras in the penalty box. A hole list with twelve ports for one bulb is a confession. Replace the bulb. Isolation should get simpler over time, not denser. If it gets denser, you are collecting junk faster than you are designing networks, and Pi-hole will not save the diagram.

The close

Pi-hole on a flat LAN is a filter. An IoT VLAN is a trust boundary. Home Assistant will lose discovery, some voice toys, and vendor apps until you add routes and static config. Put HA and radios on trusted. Put junk Wi-Fi on IoT. Allow HA out, deny junk in. Reflect multicast only if you must, and hate it a little.

If isolation breaks something you cannot configure statically, you have a device that wanted a flat LAN. Give it trusted or replace it. Do not flatten the cameras to save a bulb. That trade is how the NAS gets scanned again.

I keep a one-page map: VLAN IDs, who may initiate where, where Pi-hole lives, where HA lives, where the coordinator lives. When something flakes after a router update, I read the map before I enable any-any. Any-any is how VLANs become cosplay. Cosplay is a flat LAN with extra SSIDs and a story you tell on the internet.