Technology & smart home · 4 min read

Smart Devices Disappear After Moving Them to an IoT Network

Segmentation can improve separation while blocking the local discovery and control your smart-home apps need.

YKCA Journal · Sources reviewed October 3, 2026

Explore the guide
Smart Devices Disappear After Moving Them to an IoT Network: Cloud works, local app fails; Device visible, control fails; mDNS enabled, still absent; Matter pairing/control fails

Isolation or firewall policy may block discovery and local control even while internet access works. Map the required communication paths, configure supported exceptions narrowly, and test both function and separation.

Networking & Wi-Fi service ↗All service guides ↗

The key decision

Isolation or firewall policy may block discovery and local control even while internet access works. Map the required communication paths, configure supported exceptions narrowly, and test both function and separation.

Internet access and local discovery are different

Smart devices not discovered on an IoT VLAN may still have working internet access. Map local discovery and control requirements separately, then verify narrow supported communication paths without discarding the separation the network was designed to provide.

A UniFi owner on Reddit could cast to devices on the same VLAN but not to targets on the IoT VLAN, and also reported a HomeKit pairing timeout despite enabling mDNS. The actual problem crosses discovery and connection stages. A toggle labeled mDNS is therefore a lead to inspect, not proof that all required paths work.

A separate wireless name alone does not describe the security policy. Guest isolation, virtual local area networks, firewall rules, and multicast handling determine which devices can see and contact each other.

Source: mDNS enabled but inter-VLAN casting and HomeKit discovery fail

Discovery advertises a service; control still needs a path

Multicast DNS, or mDNS, lets devices advertise and find local services. Ubiquiti’s proxy can forward selected service discovery between configured networks. An advertised device address still has to be reachable for the later control or media session. A phone may see a speaker in a list while the firewall blocks the connection used to play audio.

Simple Service Discovery Protocol, or SSDP, is another discovery method used by UPnP devices. An mDNS proxy does not automatically forward SSDP. Identify which mechanisms the actual products use instead of opening every multicast protocol. Permit the documented control traffic and its return path narrowly; discovery permission is not a blanket permission for all traffic.

Source: UniFi Gateway - Multicast DNS (mDNS) Proxy – Ubiquiti Help Center · Microsoft: SSDP Provider and UPnP discovery

Matter adds IPv6 requirements

Matter uses IPv6 for normal device communication. Thread devices reach the home Wi-Fi or Ethernet infrastructure through a Thread border router. An IPv4 rule set and working cloud app therefore do not establish that Matter’s local IPv6 path is usable.

IPv6 link-local addresses are limited to their link; an mDNS reflector does not make those addresses routable across VLANs. Check the controller, border router, address scope and supported multicast/routing behavior as one design. A public IPv6 internet service is a different question from working local IPv6. If a consumer ecosystem does not support the intended segmentation, keep its required components together in a suitable trusted network or choose a supported architecture.

Source: Google Home Developers: Thread and IPv6 · RFC 4291: IPv6 link-local address scope

Illustrative scenario: speakers work in the vendor app

Imagine speakers on an isolated network still stream internet music, but the household’s casting interface cannot find them. Their internet route is functioning; local discovery or control between the phone network and speaker network may be blocked.

Temporarily testing the authorized phone and speaker on the same trusted network can help isolate the policy issue. Restore the intended segmentation and implement the vendor-supported communication requirements. Keep changes documented so later troubleshooting does not depend on remembered exceptions.

Source: UniFi Gateway - Multicast DNS (mDNS) Proxy – Ubiquiti Help Center

Prove security and function together

Test setup, discovery, ordinary control, controller restart, and a guest device’s lack of access to private equipment. A successful pairing is not a complete policy test. Keep the management interface restricted and preserve owner access for recovery.

Some products have limited support for segmented networks. If reliable operation requires a different architecture, say so before purchase. A network design should state both what the smart devices can reach and what the household expects to work across the boundary.

Source: UniFi Gateway - Multicast DNS (mDNS) Proxy – Ubiquiti Help Center

Put it into practice

A decision table to keep handy

Observed condition or choiceWhat it establishesNext evidence
Cloud works, local app failsInternet access does not prove discoveryPhone/controller/device network map
Device visible, control failsLater session may be blockedService-specific traffic and return path
mDNS enabled, still absentOther discovery or policy may matterActual protocol and isolation settings
Matter pairing/control failsIPv6 or border-router path may be incompleteLocal IPv6 scope and supported topology

Bring this to the conversation

Your next-step checklist

Common questions

Why do smart devices disappear on a separate IoT network?

Isolation or firewall policy may block discovery and local control even while internet access works. Map the required communication paths, configure supported exceptions narrowly, and test both function and separation.

Check the original guidance

Sources & review date

Primary guidance and available source excerpts reviewed October 3, 2026. Requirements and program terms can change; verify the current instructions for your property and project before committing to work.

Reader discussions behind this guide

These discussions illustrate reader problems; they are not technical instructions or a measure of how common a problem is. The guidance above draws on the primary sources listed here.

Ready to discuss work at your property?

Discuss this service with YKCA ↗
×

Contact Us

For More Info!