You set up a guest network for visitors. You moved your kid’s gaming devices to a separate subnet. Now your smart bulbs work in some apps but not others, and your voice assistants cannot find half your devices. Cross-subnet smart home communication is a real challenge because consumer routers default to isolating subnets entirely.
Why subnets exist
A subnet (or VLAN) is a logical network segment. Devices on the same subnet talk freely. Devices on different subnets need explicit routing to talk to each other.
Common reasons to use multiple subnets:
- Guest network for visitors (security)
- IoT VLAN for smart home isolation (security)
- Kids’ network with content filtering
- Work network separated from home
Each subnet has its own IP range and broadcast domain.
What breaks across subnets
Most smart home protocols use broadcast and multicast, which do not cross subnet boundaries:
- mDNS (Apple Home, Hue Bridge discovery)
- SSDP (smart speakers, UPnP)
- Bonjour (AirPlay, casting)
- Custom protocols (some manufacturer-specific)
A device on the main subnet cannot discover a device on the IoT subnet unless the router actively forwards these broadcasts.
Configure mDNS reflection
For Apple Home and most consumer smart home, mDNS reflection (or Bonjour gateway) is the primary fix. This causes the router to forward mDNS announcements between subnets.
- Unifi: enable Multicast DNS in network settings, choose source and destination networks.
- OPNsense/pfSense: install avahi or mdns-repeater package.
- Mikrotik: configure mdns-repeater package.
- Consumer routers: usually no native support; requires firmware that does (DD-WRT, OpenWrt with avahi).
After enabling, devices on one subnet can discover devices on others. Two-way reflection is usually required.
SSDP and UPnP forwarding
For smart speakers and casting protocols, SSDP forwarding is needed. This is less commonly supported than mDNS.
OPNsense and Unifi both support SSDP forwarding via plugins or settings. If your router does not, casting between subnets may not work and you have to keep cast sources and destinations on the same subnet.
Firewall rules
Even with discovery forwarding, you still need firewall rules to allow actual traffic between subnets. Smart home traffic typically uses:
- HTTPS (port 443) for cloud-relayed control
- Custom TCP ports for direct device control
- mDNS (UDP 5353) for discovery announcements
Allow these as needed. Be selective: do not blanket-allow main subnet to IoT subnet; that defeats the purpose of isolation.
Direction matters
For most cases, you want:
- Main subnet can initiate connections to IoT subnet (your phone can control smart bulbs)
- IoT subnet cannot initiate connections to main subnet (compromised bulb cannot attack your laptop)
This is a one-way firewall rule. Stateful inspection allows the return traffic (the bulb’s response to your phone’s command) without needing a separate inbound rule.
Hub on which subnet
The hub’s location relative to subnets matters. Common choices:
- Hub on main subnet: simplest for client access, but the hub is exposed if the main subnet is compromised.
- Hub on IoT subnet: more secure, but main-subnet clients need cross-subnet discovery.
- Hub on a dedicated management subnet: most secure, most complex to configure.
For typical home use, hub on the IoT subnet with mDNS reflection is a good balance.
The voice assistant on a different subnet
If your Echo is on the main subnet and your smart bulbs are on the IoT subnet, Echo’s local control of the bulbs requires either:
- Cross-subnet routing with mDNS reflection
- Cloud-relayed control (which always works regardless of subnets)
Cloud-relayed is the simpler path. Cross-subnet local is faster but more complex.
Matter and subnets
Matter uses mDNS, so its subnet behavior is similar to Apple Home. With mDNS reflection enabled, Matter devices on the IoT subnet are reachable from Matter controllers on the main subnet.
Thread devices are slightly different. Thread itself is a separate radio network and does not use Wi-Fi subnets. Thread border routers (HomePod, Apple TV) need to be on the same network as the controller for proper discovery.
The guest network specifically
Most consumer guest networks have client isolation enabled by default. This means guests cannot see each other or the main network. It also means smart devices on the guest network cannot see other smart devices, even on the same guest network.
If you must use a guest network for some IoT devices (some users do this as a simpler alternative to VLANs), disable client isolation on the guest network. This loses some security but enables smart home functionality.
Testing cross-subnet setup
After configuring cross-subnet support:
- From a device on the main subnet, try to discover services on the IoT subnet using a tool like Bonjour Browser (Mac) or Service Discovery Browser (cross-platform).
- Verify mDNS announcements from the IoT subnet appear.
- Try a real smart home action: control a light, ask a voice assistant.
- Test isolation: try to ping or SSH into an IoT device from the main subnet using its IP (not its mDNS name). If allowed, your firewall is too permissive.
The diagnostic when it does not work
If after configuration cross-subnet discovery fails:
- Check the router log for mDNS reflection activity.
- Verify your firewall rules actually allow the traffic.
- Verify the source and destination subnets are correctly identified in the reflection rule.
- Test mDNS with a manual query from each subnet.
Most reflection issues trace to incorrect source/destination configuration in the router.
When to simplify
If cross-subnet smart home is causing too much trouble, consider whether the subnet split is worth it for your situation. For households without sensitive workloads, a single subnet with good IoT device hygiene (strong passwords, firmware updates) may be acceptable.
For households where security matters, the investment in proper cross-subnet setup is worth it.
The mDNS reflection test
If you suspect cross-subnet discovery is broken, the test is to use a tool like Bonjour Browser (Mac) or Service Discovery Browser (Android) to scan from each subnet. Healthy reflection means services from the other subnet appear in the list. Missing means reflection is not configured.
This isolates the discovery layer from the firewall layer. Once you know discovery works, any remaining issues are firewall rules. The full setup including which protocols need explicit allowance is in our IoT VLAN setup guide.
