HomeKit and Matter across VLANs: mDNS, IPv6 and firewall rules

The short version

• The simplest setup that matches Apple's documentation: keep your iPhones, home hubs (HomePod, Apple TV) and HomeKit or Matter accessories on one network, and put everything else you don't trust (cloud-only gadgets, cameras outside Apple Home, guests) on separate networks. Apple's troubleshooting asks for the iPhone, accessories and hubs to be on "the same Wi-Fi network".
• Discovery stops at the VLAN edge by design. HomeKit and Matter find devices with multicast DNS (mDNS), which uses link-local addresses (224.0.0.251 and FF02::FB) that routers don't forward. An mDNS reflector on the gateway can copy the announcements across, but that's discovery only.
• A reflector isn't enough for Matter. The accessory also needs a routable IPv6 address on its VLAN, your gateway has to route IPv6 between the VLANs, the firewall has to let some traffic start from the accessory side, and a phone can reach Thread accessories directly only from the border routers' network. UniFi shares all mDNS services by default, but its documented "Auto" list doesn't include _matter._tcp, the service Matter uses to find devices that are already set up.
• No one guarantees it. We found no Apple, CSA, Ubiquiti, TP-Link, Netgate, OPNsense or Firewalla page that documents HomeKit or Matter control working across VLANs. The Matter specification describes one shared network, or Thread networks joined to it through border routers. The documentation for the Matter server behind Home Assistant recommends a flat network, or one VLAN shared by the server, the devices, the border routers and the phone, and says not to enable mDNS forwarders.

Why discovery breaks at the VLAN boundary

A VLAN is a separate network segment. Ubiquiti's VLAN guide puts it this way: VLANs work at Layer 2, "meaning that communication between multiple VLANs requires Layer 3 routing at the gateway." Three standards decide what that routing does to a smart home:

• mDNS is link-local. RFC 6762 says mDNS queries go to "the mDNS IPv4 link-local multicast address 224.0.0.251" or "its IPv6 equivalent FF02::FB" on UDP port 5353, and that names ending in .local "are meaningful only on the link where they originate." The 224.0.0.0/24 block, per RFC 5771, carries traffic "that is not forwarded off link". And a phone must discard answers sent to it directly (unicast) from outside its own subnet, so answers have to reach it from a relay on its own network.
• DNS-SD rides on it. DNS-Based Service Discovery (RFC 6763) is how a phone asks "which HomeKit accessories are here?" HomeKit accessories advertise _hap._tcp (the service name in Apple's open-source HomeKit ADK). Matter devices waiting to be set up advertise _matterc._udp, and devices already set up advertise _matter._tcp (the names in the CSA's Matter SDK). Over Wi-Fi and Ethernet those questions and answers travel as mDNS.
• IPv6 route announcements are link-local too. A Thread border router tells phones how to reach the Thread mesh with IPv6 Router Advertisements. RFC 4861 says a receiver accepts one only if its hop limit is 255, "i.e., the packet could not possibly have been forwarded by a router."

RFC 8766, the IETF's standard for discovery across links, sums up the problem: "link-local Multicast DNS packets, by design, are not propagated onto other links." It also explains why: multicast is costly on Wi-Fi, where it's "sent at lower data rates, and is not acknowledged." Ubiquiti makes the same point about airtime and recommends VLANs partly to contain discovery traffic, then adds: "Use mDNS relaying only where needed."

What Matter, HomeKit and Thread need from the network

Matter: one network, or Thread networks behind border routers

The Matter 1.6.1 Core Specification (CSA, September 2026) describes two topologies:

• Single network: all devices on one logical network. For Wi-Fi and Ethernet, it "could in fact span multiple Wi-Fi and/or Ethernet segments provided that all the segments are bridged at the link layer." In that case "link-local IPv6 addressing is sufficient - no additional IPv6 network infrastructure is required."
• Star: a hub network ("typically be the customer's home network") with peripheral networks, which "can be of any supported network type" (in this version of the spec that mainly means Thread), joined to it "via one or more Border Routers". Communication that crosses a network boundary "SHALL flow through a Border Router", and the spec gives border routers jobs: advertising routes and proxying discovery.

Two Wi-Fi/Ethernet VLANs joined by an ordinary gateway fit neither description: the segments aren't bridged, and the gateway isn't doing the border router's jobs. That's RouterHaus's reading of the spec, not a CSA statement; the spec does say Matter "supports local communications spanning one or more IPv6 subnets", but the topologies it defines are the two above. Four more details from the spec matter for VLANs:

• Across networks, devices need routable IPv6 addresses. In a multiple-network setup, "both the infrastructure and stub networks require routable IPv6 addresses to communicate across networks", meaning a global (GUA) or unique local (ULA) address. The spec says this about Thread stub networks, but the addressing point holds for any hop through a router. A device that only has a link-local fe80:: address can't be reached from another VLAN, and RFC 8766 says a discovery proxy should suppress link-local addresses for clients off the link for that reason.
• There's no fixed port to open. DNS-SD discovers "both the unicast IPv6 address and port", "freeing Matter from requiring a single preallocated fixed port." The SDK's default is UDP and TCP 5540 (CHIP_PORT in its configuration), and the spec lists 5540 as the IANA-assigned port for Matter's multicast messages, but a firewall rule that only opens 5540 rests on a default, not a requirement.
• Accessories sometimes start the conversation. For long-lived requests (subscriptions are the obvious case, in RouterHaus's reading), "the requester may have changed IPv6 address or port, so the responder may have to discover the current IPv6 address and port of the initiator in order to send the response." Battery-saving devices (Matter's intermittently connected devices, or ICDs) also send a sessionless Check-In message to a registered controller when their subscriptions are lost, Silicon Labs' ICD guide explains. Either way, the accessory side needs to discover and reach the controller.
• Group commands use site-scoped IPv6 multicast (addresses starting FF35, and FF05::FA). Crossing VLANs would need IPv6 multicast routing, which none of the router documentation we read describes for these gateways.

HomeKit over Wi-Fi and Ethernet

In Apple's open-source HomeKit ADK (a reference implementation whose repository Apple archived in 2022), an IP accessory advertises _hap._tcp and runs a TCP server; the controller connects to it, and the accessory sends its event notifications (an EVENT/1.0 message) back over that connection. RouterHaus's reading of that code: for HomeKit-over-IP accessories, a firewall that allows return traffic on connections the hub or phone opened covers control and status, as long as the connection stays open. Apple doesn't document any of this for network admins: its "TCP and UDP ports used by Apple software products" page lists mDNS on UDP 5353 for Bonjour and AirPlay, and no entry for HomeKit or Matter.

Thread: the routes don't cross

Thread accessories never join a VLAN; they reach your network through border routers, which for Apple Home are your Thread-capable HomePods and Apple TVs. OpenThread's Border Routing Manager advertises the Thread network's prefix "as an IPv6 Route Information Option (RIO)" inside Router Advertisements on the border router's own Wi-Fi or Ethernet link, which the spec calls the adjacent infrastructure network. RFC 4191 defines RIOs as information "from routers to hosts". A phone on another VLAN never receives them, so it sends Thread-bound packets to its default gateway instead.

Whether the Home app then falls back to sending the command through a hub is something Apple doesn't document. Since your Apple hubs are the border routers, the practical rule is that Thread accessories are effectively on whichever network the hubs are on, and your iPhone belongs there too. Thread 1.4's Thread over Infrastructure feature, which the Thread Group says lets border routers "use Wi-Fi and Ethernet connections to extend the Thread mesh network", is also found through DNS-SD on that link (OpenThread advertises it as _trel._udp). RouterHaus's inference: border routers on different VLANs can't use it to link up unless both its discovery and its traffic cross the boundary, and no maker we checked documents that case.

What Apple, the CSA and router makers document

Checked November 7, 2026:

The options, side by side

RouterHaus's comparison, built from the requirements above. "Breaks" means what the sources say stops working or isn't documented, not a measured failure rate.

For most homes, A plus E is the answer: segment the devices that aren't in Apple Home, which is also what our Apple Home guide recommends. Option B is the one Apple itself built: on a HomeKit-enabled router, Apple's platform security guide says "Restrict to Home" allows "No access to the internet or the local network except for the connections required by HomeKit", using a per-accessory Wi-Fi key. Firewalla takes a similar approach with VqLAN, which keeps devices in one network but blocks traffic between groups with access lists; for a smart home hub, Firewalla says, "We recommend grouping all smart devices and the home hub in a VqLAN." Note that VqLAN doesn't restrict multicast and broadcast between groups, and works only for devices connected directly to Firewalla hardware.

Option C: moving the hubs to the IoT VLAN

Putting HomePods and Apple TVs next to the accessories keeps hubs, border routers and accessories on one link, so the Thread routes and Matter discovery between them work as designed. The costs:

• Your iPhone is off the hubs' network, which is the situation Apple's "Network mismatch" troubleshooting tells you to fix. With Thread, the phone also loses the direct route described above.
• Media gets harder. AirPlay to an Apple TV or HomePod on the IoT VLAN needs the AirPlay services reflected and more than return traffic: Ubiquiti warns that services "such as AirPlay or screen mirroring, may require devices to establish separate connections and will not work when the receiving device is only allowed to respond."
• The hubs sit next to the devices you distrust. If the reason for the VLAN is that an accessory might be compromised, your hubs are now on its network.

mDNS reflector settings by vendor

If you segment anyway (options C and D), the gateway's mDNS feature is step one. What each maker documents:

Avahi's own manual adds a warning that applies everywhere: "Make sure to not run multiple reflectors between the same networks, this might cause them to play Ping Pong with mDNS packets." Pick one reflector, on the gateway.

A minimal firewall rule set

A vendor-neutral starting point for options C and D, written by RouterHaus from the requirements above, not taken from any vendor's guide. "Trusted" means the network with your phones; "hubs" means your Apple hubs and any other Matter controller (Home Assistant, for example). Rules are evaluated top to bottom.

Two things first. Give both VLANs routable IPv6 from the gateway (a delegated prefix or a ULA), because link-local addresses don't route; Ubiquiti's IPv6 guide says to set up IPv6 on the WAN before configuring it on VLANs. And make sure every rule below covers IPv6 as well as IPv4; UniFi's policies have an IP version option, and its switch-level L3 Network Isolation "Blocks all IPv4 traffic", which says nothing about IPv6.

Why rule 3 exists when rule 1 already allows return traffic: Matter runs mostly over UDP, and a firewall only remembers a UDP "connection" for a while. Linux's defaults, for example, are 30 seconds, or 120 seconds for what it detects as a UDP stream (your gateway's values may differ). Silicon Labs' ICD examples use idle intervals of 600 and 3,600 seconds, and it explains that the SDK by default sets such a device's subscription liveness interval to its idle interval. A report an accessory sends after a quiet spell that long can arrive as new traffic, not return traffic, and rule 5 would drop it. That's RouterHaus's inference from the documented timers, not a measured result.

Troubleshooting order

1. Prove it works on one network. Put a phone, the hub and the accessory on the same network (Omada's troubleshooting makes the same check). If it still fails, it isn't a VLAN problem: work through the single-network checklist.
2. Remove Wi-Fi-level blocks on both networks: client isolation, guest mode, and multicast filtering such as UniFi's Multicast & Broadcast Control, which Ubiquiti says blocks cross-access-point discovery. On managed switches, check IGMP and MLD snooping.
3. Check discovery from a Mac on the trusted network. In Terminal, dns-sd -B _hap._tcp lists HomeKit accessories, dns-sd -B _matter._tcp lists commissioned Matter devices and dns-sd -B _matterc._udp lists ones waiting to be set up (the two Matter commands are the ones the Matter SDK documents). Missing? Look at the reflector's service list, whether both networks are enabled, the gateway's network limit, and whether it handles IPv6.
4. Check the address. The Matter spec's own example: dns-sd -L <instance> _matter._tcp gives the host name and port, and dns-sd -Gv6 <host>.local gives its IPv6 addresses. Only an fe80:: address usually means the accessory has no routable address on the IoT VLAN; some responders publish just one address (the spec notes Avahi sends a single AAAA record), so check the VLAN's IPv6 settings too.
5. Check the path both ways. Ping that address from the Mac, then look at the firewall's log (UniFi's Flows page shows which policy blocked traffic). If commands work but status updates go missing after a quiet period, suspect rule 3.
6. For Thread accessories, confirm the iPhone and every Apple border router share a network. A reflector can't fix this one.
7. Only then restart hubs, update firmware, or remove and re-add the accessory.

If you're still choosing hardware for a segmented home, our UniFi gateway guide covers the models; note the mDNS network limits above: the original UniFi Express and the Gateway Lite allow only two networks, the Express 7 allows 30. For separating guests and business devices, see how each vendor documents separation.