Sonos, AirPlay, and Chromecast across VLANs on UniFi: the mDNS problem, explained and fixed

Multicast DNS is defined in RFC 6762, published February 2013 by Stuart Cheshire and Marc Krochmal of Apple. It exists so devices on the same local network can discover each other and resolve each other's hostnames without a configured DNS server. The machinery is simple: any query for a name ending in .local is sent as a UDP multicast to a fixed address — 224.0.0.251 for IPv4, FF02::FB for IPv6 — on UDP port 5353. Devices that match respond on the same multicast channel, and everyone on the link sees the conversation.¹

The protocol is link-local by specification, not by accident. RFC 6762 §3 reads, verbatim: “any fully qualified name ending in ‘.local.’ is link-local, and names within this domain are meaningful only on the link where they originate.”¹ The “link” in question is the broadcast domain — in practice, a single VLAN. The same RFC, in §11, requires responses to be sent with “IP TTL set to 255”and instructs receivers to check that the packet's source address is on the local subnet, silently discarding anything that fails the check.¹ Routers that follow normal forwarding rules decrement TTL and drop link-local multicast — that is the entire explanation for why discovery does not cross VLANs on its own.

On top of mDNS, a companion specification — RFC 6763, same authors, same publication date — defines how service types are named and discovered. A Sonos speaker advertises itself as _sonos._tcp.local. An AirPlay receiver as _airplay._tcp.local. A Chromecast as _googlecast._tcp.local. These are DNS-SD service strings, and they are how clients filter the noise on the multicast channel down to “just the speakers” or “just the AirPlay receivers.”² Apple's implementation of mDNS + DNS-SD is what Apple calls Bonjour.³

AirPlay 2

Apple's own enterprise deployment guide for AirPlay says it plainly: “Bonjour works by using multicast traffic to advertise the availability of services. Because multicast traffic is usually not routed across subnets, it requires Apple TV devices and AirPrint printers to be on the same IP subnet.”⁴ That is Apple — the company that wrote mDNS — telling IT administrators that AirPlay does not cross subnets without help. The same guide instructs networks that bridge AirPlay across subnets to advertise both _airplay._tcp and _raop._tcp services.⁴

AirPlay also has an out-of-band peer-to-peer fallback. Apple's guide notes that “Apple TV also broadcasts its AirPlay capabilities using a Bluetooth Low Energy (BTLE) advertisement that contains the IP address of the Apple TV,” which lets Apple devices in close proximity establish an AirPlay session without seeing each other on the network.⁴ Useful in a hotel room. Not useful for a household-wide speaker setup.

The port table is published. Apple lists UDP 5353 for mDNS / Bonjour and TCP 7000, 5000, and 6000as AirPlay's data ports.⁵

Chromecast — two protocols, depending on age

Modern Chromecasts and Cast-enabled receivers use mDNS / DNS-SD, advertising _googlecast._tcp.local on UDP 5353 and listening for control traffic on TCP 8009. These behave like AirPlay and like Sonos at the discovery layer.

The original first-generation Chromecast (and a handful of older DIAL-based casting apps) discovers via SSDP — a Simple Service Discovery Protocol that uses a different multicast address (239.255.255.250 on UDP 1900) with its own description path served on port 8008. This matters for the UniFi fix: the gateway's Multicast DNS Proxy bridges mDNS, not SSDP. Modern Chromecasts cross VLANs through the proxy. A 2014 Chromecast v1 will not, no matter what is configured.

Sonos

Sonos's own “System requirements” support article lists exactly one network requirement: “Sonos app and all Sonos products are on the same subnet.”⁶ The companion article on running Sonos with a managed switch is more direct still: “Sonos products must be on the same VLAN as all devices running the Sonos app. Devices on separate VLANs will not be able to connect to Sonos products.”⁷ That sentence is Sonos's vendor disclaimer for any cross-VLAN configuration. It is the headline citation of this article.

Sonos has two specific managed-switch requirements beyond same-subnet: the switch must have Spanning Tree Protocol enabled, and it must flood BPDUs. “Your managed switch must have Spanning Tree Protocol (STP) enabled and BPDU flooding enabled,” the Sonos article reads; “many managed switches have STP and BPDU flooding disabled by default.”⁷ Sonos uses STP to maintain communication between its products in a wired setup, and an aggressive BPDU Guard / Edge-Port policy on UniFi switches can — and does — shut down the ports that wired Sonos units are sitting on.

Sonos's published firewall guidance lists TCP 1400, 1410, 1443, 1843, 3400, 3401, 3500, and 7000 for control traffic, plus a long list of UDP ports including 1900, 1901, 5353, and 6969.⁸ If a household ever needs explicit firewall rules between a Sonos VLAN and a controller VLAN — which it should not, per the “same VLAN” guidance — that list is what to allow.

A VLAN is, by definition, a separate Layer 2 broadcast domain. Devices on VLAN 10 see each other's ARP requests, each other's mDNS multicast, each other's broadcast traffic; devices on VLAN 20 see a different set. Traffic between the two VLANs is routed, not switched — it has to pass through a Layer 3 device (the UniFi gateway) and is governed by inter-VLAN firewall rules.

For unicast traffic — your phone's HTTPS connection to a service running on another VLAN — this works fine. The router has an entry in its routing table; the firewall has a rule that allows the traffic; the packet gets forwarded. For mDNS, three things conspire to stop the packet at the gateway:

• The packet is addressed to 224.0.0.251, a link-local multicast group. The router has no routing-table entry for link-local groups, by design.
• The packet's TTL is 255, and a normal router would decrement it on forwarding. RFC 6762 receivers check for TTL 255 on arrival and discard anything else — so even if a router did forward the packet, it would be silently dropped at the destination.
• The receiving device, on the other VLAN, checks the source address against its own subnet and discards anything that doesn't match. The whole point of the “Source Address Check” in RFC 6762 §11.¹

One related question comes up often: does IGMP snooping break mDNS? No — and the reason is in RFC 4541. Section 2.1.2 of that document requires that “packets with a destination IP (DIP) address in the 224.0.0.X range which are not IGMP must be forwarded on all ports.”⁹ mDNS lives at 224.0.0.251 — inside the link-local control range — and must be flooded by any compliant IGMP-snooping switch. IGMP snooping is what prevents Apple TV and Sonos from drowning the network in unrelated multicast video traffic; it is not what stops them from discovering each other.

Every modern UniFi Gateway — UDM, UDM-Pro, UDM-SE, UCG-Max, UCG-Fiber, UDR — includes a feature Ubiquiti calls the Multicast DNS Proxy (sometimes informally called the mDNS reflector or repeater). It lives at Settings → Networks → Global Network Settings → Multicast DNS. The Ubiquiti help center describes it directly: it “forwards multicast traffic from devices between different networks (VLANs),” intended for “features like AirPlay, AirPrint, or Chromecast” that need to discover each other across VLANs.¹⁰

The proxy has three modes:

• Off — no mDNS forwarding. Each VLAN is fully isolated for discovery.
• Auto — mDNS for the common service types (AirPlay, AirPrint, Chromecast, Cast-enabled apps, generic _services._dns-sd._udp) is rebroadcast across the VLANs the proxy is enabled for. This is the right default for almost every residential network.
• Custom — a specified list of service strings of the form _service._protocol.local. Use when only one or two services need to cross — for example, bridging _airplay._tcp.local for media but not _workstation._tcp.local for random device noise.

What the proxy does notdo: it does not bridge SSDP (the older 239.255.255.250 multicast that first-generation Chromecasts and some DIAL apps use); it does not perform any firewall or trust-boundary logic of its own; and Ubiquiti's documentation notes — without naming a number — “each UniFi Gateway model has a limit on the amount of networks that Multicast DNS can be enabled on. Adding more networks to the UniFi Gateway with Multicast DNS enabled will also increase the amount of traffic forwarded between the networks.”¹⁰ For residential setups with two to four VLANs the limit does not bite; for larger deployments, scope the proxy to only the VLANs that actually contain discovery clients.

Ubiquiti's own best-practices article for AirPlay and Chromecast frames the conclusion succinctly: “ensure mDNS is enabled for both your client network and the network associated with your AirPlay/Chromecast devices.”¹¹ Both sides of the conversation need to be on the proxy.

The single-toggle answer (“turn on mDNS”) is necessary but not sufficient. Three more things have to line up. Here is the complete sequence, with the UniFi screen for each.

Step 1 — Enable the Multicast DNS Proxy across the relevant VLANs

Settings → Networks → Global Network Settings → Multicast DNS. Set the mode to Auto for most residential setups, or Custom if scope matters. Check the VLAN list and confirm both the client VLAN (phones, laptops) and the AV / IoT VLAN (Apple TV, Sonos, Chromecast) are included.¹⁰

Step 2 — Allow Established / Related return traffic on the inter-VLAN firewall

UniFi's default firewall stance for inter-VLAN traffic is deny-by-default — necessary for security, fatal for discovery if there is no companion rule for return traffic. The pattern: a stateful rule on the inter-VLAN path that allows packets in the Established and Related states. This lets the mDNS response come back to the asking client without opening a blanket inter-VLAN allow. Most UniFi templates ship with this rule already in place; a hand-built zone-based firewall can lose it.

Step 3 — Turn off Client Device Isolation on the SSIDs that need discovery

Settings → WiFi → [SSID] → Client Device Isolation. When this is on, devices on the same SSID — even on the same VLAN — cannot talk to each other. The mDNS proxy bridges across VLANs, but it cannot rescue a device that is being blocked from its own VLAN-mate. Client isolation is the right choice for a Guest SSID; it is the wrong choice for the SSID that hosts the Apple TV or the Sonos speakers.¹²

Step 4 — Verify the SSID-level multicast and broadcast settings

Settings → WiFi → [SSID] → Advanced.The two relevant toggles, both documented in Ubiquiti's “Managing Broadcast Traffic with UniFi” article: Multicast Enhancement (converts multicast to unicast for reliability — leave on for AirPlay-heavy SSIDs) and Multicast and Broadcast Control(suppresses multicast/broadcast except to whitelisted devices — leave off for SSIDs that need AirPlay or Chromecast discovery, or whitelist the receivers' MAC addresses explicitly).¹³

Step 5 — For Sonos specifically, keep the units on the same VLAN as the controllers

Sonos's own guidance is unambiguous: same VLAN, STP enabled, BPDU flooding enabled.⁷ The audit pattern is to put Sonos hardware on the same VLAN as the phones and laptops that control it — usually the trusted VLAN, not the IoT VLAN. If a household wants Sonos “on the IoT VLAN” for aesthetic reasons, the right answer is to move it to the trusted VLAN. Bridging Sonos across VLANs through the mDNS proxy is community-known-working in some configurations, but it is explicitly disclaimed by Sonos as unsupported, and homeowners who set it up that way lose vendor support when something breaks.

Step 6 — Disable BPDU Guard on switch ports facing Sonos (only if Sonos is wired)

Ubiquiti's own Sonos best-practices article notes that Sonos uses STP, and aggressive STP-edge / BPDU Guard configurations on the UniFi switch ports connected to wired Sonos units can shut those ports down on the first BPDU they see.¹⁴ For wired Sonos installations, set the port profile to allow BPDU traffic and avoid BPDU Guard on those ports specifically. For wireless Sonos this step is not needed.

After these six steps — proxy on, return rule in place, isolation off, broadcast control off, Sonos same-VLAN, BPDU Guard off the Sonos ports — discovery works the way users expect.

1. Client Device Isolation, on by accident

On the SSID where the speakers and the casting devices live. The mDNS proxy reflects packets across the router, but if the receiving SSID has Client Device Isolation enabled, the device next to the speaker on the same SSID still can't reach it. Every “I turned on mDNS and nothing changed” thread on the Ubiquiti community forum ends with this finding at least 30% of the time.

2. The inter-VLAN return rule, missing

The proxy forwards the discovery query into the AV VLAN. The AirPlay receiver answers. The answer reaches the gateway. The gateway looks for a stateful Established / Related rule on the inter-VLAN firewall back to the client VLAN — and finds nothing. The response is dropped. From the user's perspective, the device flickers in and out of the AirPlay list, or shows up briefly on the first scan and then disappears.

3. The SSID-level multicast control, on too aggressively

“Multicast and Broadcast Control” was added to UniFi specifically for high-density deployments where multicast traffic was drowning the air. In a home, that's rarely the problem. Turned on without a whitelist, it suppresses exactly the multicast discovery traffic the AirPlay or Chromecast receivers are trying to advertise — making them silent on the air. Ubiquiti's own best-practices article for AirPlay and Chromecast warns about this.¹¹

Of the three platforms in this article, Sonos is the one where the vendor explicitly does not support cross-VLAN operation. Sonos's own managed-switch article puts it directly: “Devices on separate VLANs will not be able to connect to Sonos products.”⁷

That sentence is not a statement of fact about whether cross-VLAN Sonos can be made to work — community-built configurations using the UniFi mDNS proxy plus hand-tuned firewall rules sometimes do, on some firmware combinations. It is a statement of vendor support: if a homeowner runs a cross-VLAN Sonos configuration and opens a ticket with Sonos when something stops working, the first thing Sonos will ask is whether everything is on the same VLAN, and the response to anything else will be to consolidate first.

The most recent comprehensive guide on integrating Sonos with UniFi is a Sonos Community staff post from April 8, 2026. It documents the recommended settings — IGMP Snooping enabled, mDNS enabled, Multicast to Unicast disabled, Multicast and Broadcast Control disabled, Client Device Isolation disabled, Proxy ARP disabled, STP priorities of 4096 / 8192 / 12288 across primary / secondary / tertiary switches — and on the mDNS question specifically: “mDNS: Enabled. Technically speaking, this helps with device discovery. However, if you are running a complex setup with separate Sonos systems on different VLANs, mDNS might actually need to be disabled — but for 99% of home users, keep this ON.”¹⁵

For a residential UniFi audit, the recommendation is:

• All Sonos units — wired and wireless — on the same VLAN as the controllers (phones, laptops, tablets running the Sonos app).
• STP enabled globally on the UniFi switches; STP priority tuned so the central UniFi switch is the root bridge, not a Sonos unit.
• BPDU Guard off on the switch ports facing wired Sonos hardware.
• No “Block LAN to WLAN Multicast and Broadcast” on the SSID the wireless Sonos units are on.
• Client Device Isolation off on that SSID.

If a household truly needs Sonos on a separate VLAN — for a multi-tenant building, a commercial property, a guesthouse with its own AV system — the right path is a second, completely independent Sonos system with its own controllers and its own SonosNet, not cross-VLAN bridging of a single system.

• AirPlay 2 and IGMP snooping. Apple's own documentation does not state that AirPlay 2 requires IGMP snooping. The IGMP-snooping-on recommendation comes from the enterprise wireless vendors — Cisco's Enterprise Mobility design guide is the canonical reference, framed in the context of large WLAN deployments.¹⁶ On a small UniFi residential network, IGMP snooping matters less than it would on a hundred-AP campus, but enabling it does not hurt and Sonos's own community guide recommends it.¹⁵
• Per-gateway VLAN limits for the mDNS proxy. Ubiquiti states explicitly that limits exist but does not publish the per-model numbers.¹⁰ For two to four VLANs (the residential norm) the limit is not a concern. For deployments with more, scope the proxy explicitly to the VLANs that actually contain discovery clients rather than enabling it globally.
• First-generation Chromecasts are out of scope. The UniFi mDNS proxy bridges mDNS (224.0.0.251 / UDP 5353) and not SSDP (239.255.255.250 / UDP 1900). Original Chromecasts and a handful of older DIAL apps that discover via SSDP will not cross VLANs through the proxy. The remediation is either to put those receivers on the same VLAN as the clients, or to retire them.
• Sonos S1 versus S2. Sonos splits its systems into an older S1 platform and a current S2 platform; the two cannot share a single system. Households with a mix sometimes run two separate Sonos systems intentionally — different controllers, different speaker groups. This article is written about S2; the same protocol-level reasoning applies to S1, but BPDU and SonosNet specifics differ.
• Multicast-to-unicast trade-offs. UniFi's “Multicast Enhancement” feature converts multicast packets to unicast — this is well-behaved for AirPlay/Chromecast streams on busy SSIDs but can confuse devices that expect to see real multicast on the air. The Sonos Community staff post recommends leaving it disabled;¹⁵ Ubiquiti's AirPlay/Chromecast best-practices article recommends enabling it on busy SSIDs.¹¹ The reconciliation: enable it on the SSID hosting the AV receivers, leave it off on the SSID where Sonos units live (if those are different SSIDs at all).
• This article does not cover unmanaged Wi-Fi extenders.Some households solve the “mesh doesn't work” problem by adding consumer-grade range extenders to the UniFi network. Those devices have their own multicast behaviour and frequently break discovery in ways this article's configuration cannot fix. The recommendation is to remove the extender and add a properly-meshed or wired UniFi access point.

None of this changes the high-level picture. Discovery across VLANs on UniFi is solved by the gateway's Multicast DNS Proxy plus three companion settings, with Sonos as the explicit same-VLAN exception. The fix is documented in Ubiquiti's own help center; the reason it is needed is in the original RFC. Both are in the references below.