My Sonos Beam is where I want smart TVs, voice assistants, and other media devices to live: in a separate, restricted network segment of my home network. They are too chatty – and too fond of phoning home – to share a trusted network. My supposedly trusted devices – PCs, laptops, and phones – stay in the client network. Yes, calling a phone “trusted” is debatable.
That separation is useful until Spotify opens its device picker and the Beam has apparently left the building. The speaker was online, Spotify worked, and ordinary routing between the networks was available in the permitted direction. Discovery still failed. The Sonos app behaved the same way: the Beam did not appear. The segmentation was doing exactly what I had asked – perhaps a little too well.
The missing pieces:
- Local service discovery across network boundaries using mDNS and DNS-SD, commonly associated with Bonjour
- Multicast routing between network segments
- Reliable multicast delivery across VLANs and Wi-Fi access points
This turned out to be a multi-layer problem.
Note: All hostnames, interface names, SSIDs, VLAN IDs, and IP addresses in this article are anonymized examples. The configuration is based on my running OpenWrt setup, reduced to the parts relevant to Sonos and Spotify.
The topology
The example uses two VLAN-backed network segments. CLIENTS (VLAN 10) contains the phone, while MEDIA (VLAN 50) contains the Sonos Beam and the other media devices. Four VLAN-aware OpenWrt access points carry both SSIDs over tagged uplinks to the core router (gateway).
flowchart LR
Phone["Phone + Spotify<br/>CLIENTS / VLAN 10<br/>10.0.0.20"]
APs["VLAN-aware WiFi APs<br/>VLAN 10/50"]
Router["OpenWrt based core-router<br/>Firewall<br/>Avahi reflector<br/>OMCPROXY"]
Beam["Sonos Beam<br/>MEDIA / VLAN 50<br/>10.0.2.30"]
Cloud[(Spotify services)]
Phone <-->|"WiFi / VLAN 10 / CLIENTS"| APs
Router <-->|"802.1Q trunk<br/>VLAN 10/50"| APs
APs <-->|"WiFi / VLAN 50 / MEDIA"| Beam
Phone -. "WEB" .-> Cloud
Beam -. "WEB" .-> Cloud
classDef trusted fill:#d9f2e6,stroke:#237a57,color:#111;
classDef media fill:#fff0cc,stroke:#a66a00,color:#111;
classDef infra fill:#e7ecf8,stroke:#3e5b9a,color:#111;
class Phone trusted;
class Beam media;
class APs,Router infra;Why normal routing is not enough?
Discovery traffic used to locate the Sonos Beam is normally confined to a single network segment. mDNS (multicast DNS) uses the IPv4 multicast address 224.0.0.251 on UDP port 5353. SSDP commonly uses 239.255.255.250 on UDP port 1900. This multicast traffic normally stops at a Layer-3 boundary unless it is explicitly reflected, proxied, or routed.
There is no single setting that fixes the problem. Spotify Connect, Sonos discovery, cloud sessions, and local control are related but distinct paths. So, I fixed the layers: mDNS reflection, multicast proxying, and Wi-Fi multicast delivery.
1. Install the required router packages
Install the required packages from an SSH session on the core router. The following example uses OpenWrt 25.x and its apk package manager.
The LuCI package is optional but useful when checking the final omcproxy configuration.
For details, see OpenWrt’s opkg-to-apk cheat sheet:
opkg-to-apk-cheatsheet
apk update
apk add avahi-dbus-daemon avahi-utils omcproxy luci-app-omcproxyOlder OpenWrt releases use opkg; do not mix package-manager instructions between releases.
2. Reflect mDNS with Avahi
To inspect the DNS-SD services currently visible on the network, I use the iPhone app Discovery – DNS-SD Browser. It provides a useful overview of discoverable TVs, voice assistants, printers, and speakers.
Because mDNS does not cross Layer-3 boundaries, the router needs an Avahi reflector. In this example, Avahi listens on the MEDIA and CLIENTS interfaces and republishes mDNS records between them, making services visible across the VLAN boundary.
The interface allow-list is the key security control. Do not attach the reflector to every guest, VPN, and management network: doing so unnecessarily expands the discovery domain and creates additional multicast traffic. Enable it only where required.
[server]
enable-dbus=no
use-ipv4=yes
use-ipv6=yes
allow-interfaces=br-clients,br-media
[reflector]
enable-reflector=yes
reflect-ipv=noReplace br-clients and br-media with the actual Linux device names on the core router. In my full setup Avahi also serves other local segments, but they are intentionally omitted here.
If you are unsure of the Linux device names, use ip link show. Names such as eth0.10 or lan1.10 often denote an 802.1Q subinterface for VLAN 10, but verify the mapping in /etc/config/network rather than relying on the suffix alone.
Once configured, enable and restart avahi-daemon. Additional services may then appear in the DNS-SD browser. Look for Sonos- and Spotify-related service records such as _sonos._tcp and _spotify-connect._tcp.
/etc/init.d/avahi-daemon enable
/etc/init.d/avahi-daemon restart3. Proxy multicast with omcproxy
The next step is to forward the required multicast traffic from MEDIA to CLIENTS. Control devices such as my phone reside in CLIENTS, whereas the media devices reside in MEDIA. I use omcproxy because it is a small, lightweight multicast proxy available as a native OpenWrt package.
MEDIA is the omcproxy uplink, and CLIENTS is a downlink.
config proxy 'media'
option scope 'realm'
option uplink 'MEDIA'
list downlink 'CLIENTS'/etc/init.d/omcproxy enable
/etc/init.d/omcproxy restartThe direction matters. omcproxy is not a universal broadcast repeater, and it does not make every discovery protocol bidirectional. In this design it carries subscribed multicast traffic and announcements from the MEDIA side towards interested receivers on the CLIENTS side. Avahi separately handles mDNS reflection.
4. Keep the firewall stateful and directional
The firewall must permit the required traffic from CLIENTS to MEDIA. OpenWrt uses zone-based firewalling.
The MEDIA zone remains unable to initiate arbitrary connections into the CLIENTS zone. My trusted clients may initiate connections towards media devices, and the stateful firewall permits the replies.
Caution: the
inputpolicies below block access to services on the router itself unless an explicit input rule permits it. Adjust the rules to match your DNS and management requirements before applying them.
config zone
option name 'CLIENTS'
list network 'CLIENTS'
option input 'REJECT'
option output 'ACCEPT'
option forward 'DROP'
config zone
option name 'MEDIA'
list network 'MEDIA'
option input 'DROP'
option output 'ACCEPT'
option forward 'DROP'
config forwarding
option src 'CLIENTS'
option dest 'MEDIA'Avahi and omcproxy also need the core router to accept their local multicast control traffic. The following is deliberately limited to the two relevant zones.
config rule
option name 'Allow-mDNS-from-clients'
option src 'CLIENTS'
option proto 'udp'
option dest_port '5353'
option target 'ACCEPT'
config rule
option name 'Allow-mDNS-from-media'
option src 'MEDIA'
option proto 'udp'
option dest_port '5353'
option target 'ACCEPT'
config rule
option name 'Allow-IGMP-from-clients'
option src 'CLIENTS'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-multicast-from-media'
option src 'MEDIA'
option proto 'udp'
option family 'ipv4'
option dest_ip '224.0.0.0/4'
option target 'ACCEPT'My production firewall contains broader shared multicast rules because it serves more applications than Sonos. Copying those unrelated ports into this article would be convenient but wrong. For a stricter policy, capture the required unicast flows and replace the broad CLIENTS-to-MEDIA forwarding with explicit rules.
5. Make multicast survive the Wi-Fi path
This is probably the most challenging part:
Routing and reflection can be perfect while multicast quietly dies on an access point. Wi-Fi multicast is sent at conservative rates and is buffered around DTIM beacons. Busy airtime, power-saving clients, bridge filtering, and driver-specific behaviour make it less forgiving than unicast.
Each AP maps the two SSIDs to their VLAN-backed networks. Where the driver supports it, I explicitly enable multicast-to-unicast so the AP can deliver multicast frames as reliable per-client unicast frames.
config wifi-iface 'clients_5g'
option device 'radio1'
option mode 'ap'
option ssid 'clients-example'
option network 'CLIENTS'
option dtim_period '3'
option multicast_to_unicast '1'
option disassoc_low_ack '0'
config wifi-iface 'media_5g'
option device 'radio1'
option mode 'ap'
option ssid 'media-example'
option network 'MEDIA'
option dtim_period '3'
option multicast_to_unicast '1'
option disassoc_low_ack '0'multicast_to_unicastis the relevant reliability option here.- A
dtim_periodof 3 is the value used in my network; it is a latency/airtime/battery trade-off, not a universal constant. disassoc_low_ack=0is also present in my AP profiles, but it is a client-stability choice rather than the mechanism that crosses VLANs.
I also enable IGMP snooping on the VLAN-aware bridge where the hardware and driver expose it:
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'wan'
option stp '1'
option igmp_snooping '1'IGMP snooping limits multicast flooding; it does not route multicast. It also needs a working querier somewhere in the Layer-2 domain; otherwise, memberships may age out and discovery becomes mysteriously intermittent – the most annoying kind of failure.
Different OpenWrt targets and wireless drivers do not always expose identical knobs. Configure the option where supported and verify the effective packet path on every AP model, rather than assuming a fleet is homogeneous because the SSID names match.
Verification: follow the packets
After restarting the services, first confirm that both daemons are running:
pgrep -af 'avahi|omcproxy'
logread -e avahi -e omcproxyThen capture on both sides of the gateway while opening Spotify’s device picker:
tcpdump -ni br-clients 'igmp or udp port 5353 or udp port 1900'
tcpdump -ni br-media 'igmp or udp port 5353 or udp port 1900'The goal is not merely to see packets somewhere. Check that queries, announcements, and membership reports appear on the expected interfaces, and that the Beam’s unicast replies are allowed back to the initiating clients. If discovery works only while the phone and speaker sit on the same AP, inspect that AP’s VLAN membership and wireless multicast settings.
A compact troubleshooting map
- The Beam never appears: verify Avahi’s interface allow-list, UDP 5353 input rules, omcproxy direction, and the VLAN tags.
- It appears and disappears: inspect IGMP membership ageing, querier availability, DTIM behaviour, multicast-to-unicast support, and roaming between APs.
- It appears but playback or volume control fails: discovery is working; inspect the stateful unicast policy between the clients and media zones.
- Spotify works remotely but not locally: cloud reachability does not prove that local discovery or control traffic can cross the VLAN boundary.
My final head-banging moment was above the network layer. If packet captures indicate that discovery is working but Spotify still cannot see the Beam, remove Spotify from the Sonos app, update and restart the app, reconnect the Spotify account, and allow 10–15 minutes for the integration to settle. This fixed my installation, but it is a troubleshooting observation rather than proof of a network problem.
The result
With Avahi reflecting mDNS, omcproxy carrying multicast from the MEDIA VLAN towards the CLIENTS VLAN, one-way trusted-to-media forwarding, and consistent multicast handling on the APs, the Sonos Beam becomes discoverable and controllable from Spotify on the iPhone without moving either device out of its intended security zone.
Once discovery crosses the VLAN boundary, other services may also become visible. Visibility does not automatically grant access, but the firewall policy determines what can actually be reached.
The larger lesson is pleasantly unglamorous: inter-VLAN media discovery is a chain. Reflection, multicast membership, firewall policy, VLAN tagging, and Wi-Fi delivery all have to agree. Packets are not impressed by architectural intent.