Wi-Fi & Network

Casting & AirPlay broke after VLAN setup

After putting devices on a separate VLAN, Chromecast/AirPlay/AirPrint vanish. It's mDNS not crossing the VLAN — reflect discovery and allow the media path.

Problem summary

Discovery protocols (mDNS/Bonjour) are link-local by design, so they don't cross VLAN boundaries. After you segment, phones on the trusted VLAN can't see speakers/TVs/printers on the IoT VLAN until you reflect mDNS between the VLANs and allow the actual media traffic, not just discovery.

Operator snapshotEvidence first

First proof

Put the controller (phone) temporarily on the same VLAN as the target device and retry.

Screen to open

ping <device-ip> then check the inter-VLAN firewall log

Expected signal

Casting/AirPlay works when both are on one VLAN.

Stop boundary

If only Thread devices fail, verify the border router's reachability before changing the whole topology.

Layer path

1Discovery protocols (mDNS/Bonjour, used by AirPlay, Chromecast/Google Cast, AirPrint, and HomeKit/Matter commissioning) are link-local: they're multicast that, by design, does not cross a VLAN/subnet boundary.

2So after you segment (trusted vs IoT/cameras/guest), the controller and the target device can be perfectly healthy yet invisible to each other. The fix is to reflect mDNS between the relevant VLANs and to allow the actual media/control traffic, not just the discovery packets.

3Two layers fail separately: discovery (does the device appear in the list?) and the session (does it actually play once selected?). Reflection fixes the first; firewall rules and AP multicast handling govern the second.

4These platforms are stateful, so return traffic for an allowed connection is automatic — the correct model is 'allow trusted → IoT for the needed services and let state handle the replies', not a manual 'allow established' rule placed first.

Runbook

Step-by-step runbook

Start here. Do each check in order, compare it to the expected result, and stop when the evidence explains the failure or the safe stop point applies.

Reproduce with a same-VLAN control test

Check: Temporarily move the controller onto the device's VLAN and confirm casting/AirPlay/printing works.

Expected result: Same-VLAN success proves the device is fine and the boundary is the problem.

If not: If it fails even same-VLAN, troubleshoot the device/app itself before blaming segmentation.

Decide: discovery problem or session problem

Check: Note whether the device fails to appear at all, or appears but won't play.

Expected result: You know which layer to fix — reflection vs firewall/AP.

If not: Handle both if symptoms are mixed, but verify each independently.

Enable mDNS reflection for the right VLANs

Check: Turn on the platform's reflector/proxy and scope it to the trusted and IoT VLANs (UniFi mDNS Proxy; OPNsense os-mdns-repeater with 2–5 interfaces; pfSense Avahi; Firewalla reflector).

Expected result: The device now appears in the controller's list from the trusted VLAN.

If not: If it still doesn't appear, check AP multicast filtering before assuming the reflector failed.

Allow the media/control path in the inter-VLAN firewall

Check: Permit trusted → IoT to the target device for the needed services; rely on stateful return traffic rather than a manual allow-established rule.

Expected result: Selecting the device now actually starts playback/printing.

If not: Keep IoT → trusted blocked; you only need the controller-initiated direction open.

Handle Matter/Thread and printers explicitly

Check: For Matter, ensure commissioning multicast is reflected and the controller can reach the Thread border router; for AirPrint, reflect the printing services and allow the printer.

Expected result: Commissioning/printing succeeds without collapsing the VLANs.

If not: If only Thread devices fail, confirm border-router reachability rather than changing the whole topology.

Special-case device-to-device systems

Check: For Sonos or similar, co-locate the controller and players on one VLAN instead of relying on reflection.

Expected result: Control is reliable for those systems.

If not: Document the exception so a future re-segmentation doesn't silently break them again.

Decision tree

If: Works when controller and device share a VLAN, fails across.

Then: Segmentation boundary is the cause.

Action: Add mDNS reflection for those two VLANs and an inter-VLAN rule allowing the media path.

If: Device never appears in the cast/AirPlay list.

Then: Discovery isn't crossing — reflection missing or not covering these VLANs.

Action: Enable the mDNS reflector/proxy (UniFi mDNS Proxy Auto/Custom, OPNsense os-mdns-repeater, pfSense Avahi, Firewalla reflector) for the right interfaces.

If: Device appears but playback fails after you select it.

Then: Discovery works; the session is blocked.

Action: Open trusted → IoT to the device's media/control ports and check AP multicast filtering.

If: Matter/Thread device won't commission across the VLAN.

Then: Commissioning needs link-local multicast and (for Thread) border-router reachability.

Action: Reflect mDNS and ensure the controller can reach the Thread border router; don't collapse VLANs as the 'fix'.

Safe stop: If only Thread devices fail, verify the border router's reachability before changing the whole topology.

If: Only Sonos (or another device-to-device system) fails.

Then: VLANs break its peer protocol independently of mDNS.

Action: Keep controller and players on one VLAN; treat it as its own case, not an mDNS misconfig.

Evidence

Evidence table

Symptom	Evidence to collect	Likely layer	Next action
TV/speaker missing from the cast list after segmenting.	Whether mDNS reflection covers the trusted↔IoT pair; same-VLAN retest result.	Discovery / mDNS not crossing VLAN	Enable the gateway's mDNS reflector/proxy for those VLANs.
Device shows up but won't actually play.	Inter-VLAN firewall rule for trusted → IoT media ports; AP multicast filtering state.	Firewall media path / AP multicast	Allow the media/control path and adjust AP multicast handling.
AirPrint printer invisible from the trusted VLAN.	Reflection of _ipp/_ipps services; firewall allowance to the printer.	mDNS service scope	Reflect the printing services and allow trusted → printer.
Matter device won't commission cross-VLAN.	mDNS/IPv6 link-local reflection; reachability to the Thread border router.	Commissioning multicast / Thread BR	Reflect discovery and ensure border-router reachability; keep VLANs intact.
Sonos uncontrollable across VLANs despite reflection.	Which VLAN the controller vs players sit on.	Device-to-device protocol	Co-locate controller and players on one VLAN.

Reference

Commands and settings paths

Can the controller even reach the device's IP?

ping <device-ip> then check the inter-VLAN firewall log

Where: From a trusted-VLAN client toward the IoT-VLAN device.

Expected: Ping succeeds (or is intentionally blocked but the media ports are allowed), confirming routing/firewall intent.

Failure means: If blocked entirely, discovery reflection won't matter — the session can never open.

Safe next step: Set the inter-VLAN rule to allow the needed trusted → IoT traffic, then retest.

Is mDNS being seen on the client's segment?

dns-sd -B _airplay._tcp / _googlecast._tcp (macOS) • avahi-browse -a (Linux)

Where: On a trusted-VLAN client after enabling reflection.

Expected: The IoT-VLAN device's service is discovered from the trusted side.

Failure means: Nothing discovered means the reflector isn't covering these VLANs or the AP is filtering multicast.

Safe next step: Enable/scope the reflector for the correct interfaces; check AP multicast filtering.

Confirm the reflector configuration

UniFi: Settings > (gateway) mDNS Proxy (Auto/Custom) • OPNsense: Services > mDNS Repeater • pfSense: Avahi package

Where: In the gateway/firewall admin UI.

Expected: The reflector is enabled and lists the trusted and IoT interfaces (OPNsense requires 2–5 interfaces).

Failure means: If the legacy per-network 'Multicast DNS' toggle is what you're looking for on UniFi, it's gone — use mDNS Proxy.

Safe next step: Scope the reflector to the needed VLANs/services and save.

Check AP multicast handling

UniFi: WiFi settings > Multicast Filtering / Multicast Enhancement

Where: In the wireless/AP settings for the SSIDs involved.

Expected: Multicast required for discovery and streaming is allowed to wireless clients.

Failure means: Aggressive multicast filtering can drop reflected mDNS or the media stream even with the reflector on.

Safe next step: Adjust per the vendor's Chromecast/AirPlay best-practice guidance and retest.

Hardware boundary

Hardware and platform boundary

Change only when

If your current gateway can't reflect mDNS or scope it per-service, that's the time to move to gear that does (a UniFi gateway with mDNS Proxy, or OPNsense/pfSense with the reflector/Avahi).

Evidence that matters

Whether the firewall is stateful with per-service inter-VLAN rules, whether it can reflect/scope mDNS per VLAN, and how its APs handle multicast.

Evidence that does not matter

Raw throughput of the gateway — mDNS reflection is tiny; this is a features-and-rules problem, not a speed problem.

Avoid

Flattening your VLANs to 'make casting work' (throws away the isolation you built), or adding broad any→any rules instead of scoped trusted→IoT allowances.

Related tool/checklist

Use the linked tool when you need a guided plan from your exact symptoms instead of a static checklist.

Device setup troubleshooter

Last reviewed

2026-06-02 · Reviewed by HomeTechOps. Built from June-2026 research verified against Ubiquiti's mDNS Proxy and Chromecast/AirPlay best-practice docs and the OPNsense multicast-DNS how-to; reflects the current UniFi 'mDNS Proxy' terminology (not the legacy toggle), the stateful-firewall truth about return traffic, and the Matter-over-Thread border-router nuance. Complements the segmentation setup guide.

Sources/assumptions

Assumes a working VLAN/firewall segmentation (trusted vs IoT/cameras/guest) — see the segmentation setup guide for building it.
Assumes prosumer gear (UniFi, OPNsense/pfSense, Firewalla, OpenWrt). Vendor UIs and terminology change — verify the current control name before following steps.
These platforms are stateful firewalls: return traffic for an allowed connection is permitted automatically; you do not need a manual 'allow established' rule first.

Source-backed checks

HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.

Apple Support: Wi-Fi and internet troubleshooting on MacUsed for safe first checks around Wi-Fi status, diagnostics, VPN/security software, and external network devices.Microsoft Support: Fix network connection issues in WindowsUsed for Windows network baseline checks before changing router-wide settings.Ubiquiti Help: UniFi Gateway mDNS ProxyUsed for the current UniFi mDNS Proxy (Auto/Off/Custom) terminology and per-gateway network limits — replaces the legacy per-network 'Multicast DNS' toggle.Ubiquiti Help: Best practices for Chromecast and AirPlayUsed for the AP-level multicast-filtering caveat and the requirement to permit media traffic, not just mDNS discovery.OPNsense docs: Multicast DNS (mDNS repeater)Used for the os-mdns-repeater plugin path and its 2–5 interface constraint on OPNsense.Apple Support: Recommended settings for Wi-Fi routers and access pointsUsed for router security, band, naming, and access-point settings that affect mixed home devices.

Diagnostic rule

1. Check the simplest signal first.
2. Change one thing at a time.
3. Avoid unsafe electrical or data-loss steps.
4. Stop when the evidence says the risk moved.

FAQ

I enabled mDNS reflection but casting still doesn't work — what's missing?

Reflection only fixes discovery. The cast/AirPlay session itself then opens its own connection (often a different port range) from your phone to the device — if your inter-VLAN firewall blocks that, the device shows up but won't play. Allow the trusted VLAN to reach the IoT device on the media path, and check AP-level multicast filtering, which can silently drop the stream even when reflection is on. See Ubiquiti's Chromecast/AirPlay guidance for the AP-side caveat.

On UniFi, where's the 'Multicast DNS' toggle? I can't find it.

UniFi replaced the old per-network 'Multicast DNS' checkbox with an mDNS Proxy on the gateway, with Auto / Off / Custom modes. Auto retransmits common services across VLANs; Custom lets you scope specific services (for example `_airplay._tcp.local`) to specific VLANs. Older guides showing the legacy toggle are stale. Note there are per-gateway limits on how many networks mDNS Proxy covers.

Does this mean Matter and Thread devices need everything on one VLAN?

No — that's an over-broad myth. Matter-over-Wi-Fi is IP and can work across subnets, but commissioning uses link-local multicast (mDNS/IPv6) that won't cross a VLAN without reflection, and Matter-over-Thread additionally needs the controller to reach the Thread border router. So the fix is reflection plus border-router reachability, not collapsing your VLANs. See Matter/Thread pairing.

Sonos still won't show up even with mDNS reflected — why?

Sonos and some similar systems use device-to-device protocols that VLAN boundaries break independently of mDNS, so reflection alone often isn't enough. The reliable patterns are keeping the controller and speakers on the same VLAN, or placing the controlling device on the same segment. Treat it as its own failure class rather than assuming the mDNS fix covers it.