UniFi IoT VLANs for Home Assistant: Keep Discovery Working

An IoT VLAN is one of the few security changes on a home network that pays for itself. It is also the change that quietly empties Home Assistant's list of discovered devices, usually the same afternoon it goes in.

Nothing is broken, exactly. Home Assistant finds most devices by listening for multicast announcements, and those announcements stop at the edge of a VLAN by design.

That tension sits at the center of every segmented smart home. The reason to build an IoT network is to keep a cheap camera or a forgotten smart plug away from your laptop and your NAS.

In fact, the VLAN fundamentals guide makes that case. The trouble afterwards is that discovery, casting and Matter all assume devices share a network.

The answer is not to tear the segmentation down. Instead, decide where Home Assistant lives, relay only the traffic that has to cross, and write firewall policies that match the layout rather than fight it.

What follows walks through each of those decisions for UniFi Network 9.0 and later, the release where Ubiquiti introduced zone-based firewalling. Every integration requirement comes from Home Assistant's own documentation, and every UniFi setting from Ubiquiti's help center.

Three layouts work, and each one trades a different kind of effort:

• Home Assistant on the IoT VLAN. Discovery works natively, because Home Assistant hears every announcement on its own network. The trade is that every IoT device can reach its login page, so multi-factor authentication and monthly updates matter more here. The firewall needs one deliberate opening: trusted clients reaching Home Assistant's web interface, plus casting from phones to speakers and TVs if you want it.
• Home Assistant on the trusted VLAN, reaching in. Every discovery protocol must be relayed or replaced with typed-in addresses. What's more, some integrations, Sonos and Cast among them, need the device to open a connection back to Home Assistant. The IoT side then ends up with holes into the trusted side, the very direction segmentation exists to close.
• Home Assistant with a leg in each VLAN. Home Assistant OS can add a tagged VLAN interface to an Ethernet port from its command line (ha network vlan), and its network settings let you choose which adapter integrations use. That works, although it makes Home Assistant the one host that can reach both sides.

The first layout wins for most homes, and the reasoning is Home Assistant's own. Its Google Cast documentation says automatic discovery across subnets is not supported.

Its Matter documentation goes further and asks that Matter devices using Wi-Fi, including Thread border routers, sit on the same VLAN as Home Assistant.

Keep in mind that this moves more than Home Assistant. If your Thread border router is an Apple TV 4K, a HomePod mini or a Nest Hub (2nd Gen), it joins the IoT side too.

Accordingly, phones on the trusted network reach those devices through the mDNS relay described below, which is the job Ubiquiti built it for.

Home Assistant also needs an address that never changes, since firewall policies and media URLs will point at it. In UniFi Network, open the device under Client Devices, enable Fixed IP Address to create a DHCP reservation, and add a Local DNS Record if you want a hostname the gateway resolves.

Home Assistant runs three network discovery methods by default. Zeroconf, also known as mDNS or Bonjour, finds the most integrations.

SSDP, part of UPnP, finds many of the rest, and Home Assistant's SSDP documentation lists Sonos, Roku, several TV brands and UniFi Protect among the integrations it discovers. The third, DHCP discovery, watches for devices requesting an address, and those requests are broadcasts that stay inside their own subnet.

The integrations people hit first fail in different ways, and each one's documentation spells out what it needs from the network:

• Google Cast. Automatic discovery works only on the same subnet, so across VLANs you either forward mDNS or list the devices as known hosts. Chromecasts also generally ignore the DNS server DHCP hands them and use Google's 8.8.8.8 and 8.8.4.4, which means media and text-to-speech URLs must be an IP address or a publicly resolvable name.
• Sonos. Speakers push updates by connecting back to Home Assistant on TCP port 1400, and if they cannot, the integration falls back to slower polling and raises an alert. Announcements and text-to-speech need the reverse path: Home Assistant to each speaker on TCP port 1443.
• HomeKit Bridge. The documentation lists UDP 5353 and TCP 21063 as the ports to open, and it says the iOS device must be on the same local network as Home Assistant to pair. In this layout, pair from a phone joined to the IoT SSID.
• HomeKit Device. Bringing HomeKit accessories into Home Assistant from another VLAN needs an mDNS reflector for discovery and pairing to work.
• Matter. It relies on IPv6 and mDNS moving freely, and the documentation warns that VLANs, multicast filtering and malfunctioning IGMP snooping may not integrate well with it.

Of course, discovery is only half of it. Sonos and Cast also need specific unicast paths that a strict firewall will cut.

That is why the zone policies below matter as much as the relay does.

UniFi gateways include an mDNS proxy that repeats discovery traffic between networks. Ubiquiti's mDNS Proxy article describes three modes: Auto relays common services across all VLANs, Off stops relaying, and Custom relays chosen services between chosen networks.

Custom also accepts new service types written as _service._protocol.local. Ubiquiti's switch settings reference lists the services Auto covers and adds an All mode that forwards every service.

The proxy is enabled automatically on newly created networks, and the switch reference says all mDNS traffic is forwarded by default. So check which mode your networks actually use before assuming anything is blocked.

With Home Assistant on the IoT VLAN, most of that list stops mattering. The relay's remaining job is letting phones and laptops on the trusted network see the speakers, TVs and printers on the IoT side.

For instance, a phone that casts to a Chromecast or AirPlays to an Apple TV needs _googlecast._tcp or _airplay._tcp relayed, and both are on the Auto list.

Be aware that relaying has a cost. Ubiquiti's broadcast-traffic guidance notes that a few hundred Kbps of mDNS can use as much airtime as a few hundred Mbps of unicast, because Wi-Fi sends multicast at the lowest supported data rate.

In addition, every gateway caps how many networks the proxy can serve:

Gateway	Networks with the mDNS relay
UniFi Express, UXG Lite	2
Dream Router, Dream Router 7, Express 7	30
Cloud Gateway Ultra, Cloud Gateway Max, Cloud Gateway Fiber	50
UDM-Pro, Dream Machine SE, Dream Machine Pro Max	50

On an Express or a UXG Lite, 2 networks is the whole allowance, which covers a trusted-plus-IoT pair and nothing else. Accordingly, enable the relay only on the networks that need it, which is also Ubiquiti's advice when performance drops.

Zone-based firewalling arrived in UniFi Network 9.0 and needs a gateway on version 4.1 or newer. Networks are grouped into zones, and policies govern traffic between zones rather than between individual VLANs.

One default matters more than the rest. In Ubiquiti's zone matrix, traffic from the Internal zone to the Internal zone is Allow All.

In other words, an IoT VLAN left in the Internal zone is a separate subnet with no firewall isolation by default, however tidy it looks in the network list.

The fix is a custom zone. Ubiquiti allows up to 30 zones, a network can belong to only one, and a policy you create takes precedence over the built-in ones.

Here is the sequence that fits this layout:

1. Create an IoT zone and move the IoT network into it, out of Internal.
2. Allow Internal to IoT with Auto Allow Return Traffic switched on, so trusted clients can open Home Assistant and reach casting targets. Narrow the destination to Home Assistant's address and web port only if nobody on the trusted side casts to IoT devices.
3. Block IoT to Internal with the connection state set to New. That stops connections the IoT side starts without catching the replies that step 2 allows.
4. Keep IoT to Gateway open. Ubiquiti warns that blocking the Gateway zone can disrupt DHCP and DNS, so read the new zone's row in the zone matrix and confirm the gateway is allowed. Home Assistant's UniFi Network integration also talks to the console, on port 443 by default.
5. Decide IoT to External deliberately. Most devices need the internet for firmware and cloud features, and Chromecasts expect to reach Google's DNS servers directly.

Order matters within your own policies, so place specific allows above broader blocks. Ubiquiti's guidance says the same: create the allow for the traffic you need before the block that denies everything else.

Note that zone policies apply in both directions, so a flow blocked one way stays blocked even if the reverse is allowed.

Of course, Home Assistant itself sometimes needs the trusted side, too. A NAS that receives its backups or a media server it controls each needs a narrow allow.

Point each allow from Home Assistant's address to that host and port, and place it above the block in step 3.

Use Home Assistant's web port in step 2. It is shown under Settings › System › Network: existing installations keep the port they had, usually 8123, while new Home Assistant OS installations since the 2026.8 release use port 80.

Finally, skip the one-click alternative for this network. Ubiquiti describes Network Isolation as automatically configuring "the necessary firewall rules to block inter-VLAN traffic", which is blunt when one host on the IoT side must stay reachable.

For a guest network, where nothing should be reachable, Network Isolation fits well, and the guest network guide covers that case.

Several SSID options that help a laptop network quietly hurt an IoT one. Ubiquiti's SSID settings reference describes each of them, and the ones worth checking on the network Home Assistant shares include:

• Bands. Keep 2.4 GHz on the SSID, since Home Assistant's Matter documentation notes that Wi-Fi Matter devices often use it. Ubiquiti recommends multi-band SSIDs and warns that a 6 GHz-only SSID can lead to discovery issues, because many clients scan on 2.4 or 5 GHz first.
• Security. WPA2/WPA3 is Ubiquiti's recommendation for most networks, and WPA2 alone may be necessary for legacy IoT devices. Leave MLO off here, because enabling it also enables WPA3, which Ubiquiti says may limit connectivity with IoT clients. The Wi-Fi 7 MLO guide explains the security requirement.
• Client Device Isolation. It blocks device-to-device traffic on the same access point, including discovery and casting. Ubiquiti suggests it for guest or IoT networks whose devices don't need to talk to each other. That rarely describes a network where a Wi-Fi hub serves the accessories around it or speakers group together.
• Multicast Enhancement. Ubiquiti calls it especially helpful with Chromecast, Apple TV or Sonos. That said, Home Assistant's Matter documentation warns that settings which "optimize" multicast can harm Matter's discovery traffic, so it is the first toggle to test when commissioning fails.
• Multicast and Broadcast Control. It restricts multicast to approved clients and blocks discovery across access points, so leave it off unless you maintain its exception list.
• Data rates and DTIM. Raising the minimum data rate can lock out legacy IoT devices, and Ubiquiti warns that a longer DTIM period may hurt airtime efficiency, battery life and IoT connectivity. Ubiquiti's DTIM defaults are 1 on 2.4 GHz and 3 on 5 and 6 GHz.

Enhanced IoT Connectivity is the exception worth knowing about. Although Ubiquiti describes it as generally unnecessary, it can help legacy or low-power devices that struggle to stay connected.

The roaming-oriented toggles on the same page are covered in the Wi-Fi roaming guide.

IGMP snooping is a switch feature that forwards multicast only to ports whose devices have asked for it, which cuts flooding on busy networks. Home Assistant's HomeKit Device documentation reports it being blamed for discovery problems and also suggested as the fix.

Ubiquiti's switch settings reference shows why IPv4 mDNS survives it. Multicast in the 224.0.0.0/24 range is always flooded, and mDNS over IPv4 uses 224.0.0.251, but the reference makes no such promise for the IPv6 multicast Matter depends on.

Unknown multicast, however, is handled differently. It defaults to Drop, and Ubiquiti itself notes that some AV and IoT devices expect multicast to be flooded regardless of group membership.

What's more, Home Assistant's HomeKit Bridge documentation adds a field report. Router IGMP settings have caused every bridged accessory to go "not responding" a few minutes after a restart, and the default IGMP settings typically work best.

That said, none of this makes snooping wrong on an IoT VLAN. It is simply the first setting to revert when multicast-dependent devices misbehave after a change.

If you do run it, the options to check are Forward Unknown Multicast Traffic and Flood Known Protocols, which floods SSDP among others.

Test the layout with one device of each kind before migrating the whole house. Each check below exercises a different part of the design, and the order runs from the firewall outward:

1. From a trusted laptop, open Home Assistant at its fixed address and web port. A timeout means the Internal-to-IoT allow is missing or sits below a block.
2. From Home Assistant, open Settings › System › Network and use the Zeroconf Browser and SSDP Browser. Devices listed there are being discovered, so a missing one usually points at its network placement rather than at the integration.
3. From a phone on the trusted network, cast to a speaker and AirPlay to a TV. A failure here is the mDNS relay or the Internal-to-IoT policy.
4. From the IoT side, using Home Assistant's own terminal app, try to reach a trusted host you have not allowed. If it answers, the IoT network is probably still in the Internal zone or the block sits below an allow.
5. In Home Assistant, confirm that Sonos has not raised its polling alert and that a Matter device commissions cleanly.

Once those pass, move the rest in batches rather than all at once, so a failure points at a small set of devices. After all, every zone and relay setting above applies to a whole network, not to a single device.

Remote access follows the same zones. A phone on Teleport or a WireGuard server arrives in the VPN zone, so it needs its own path to the IoT zone.

Phones also make useful presence trackers once the UniFi integration can reach the console.