Hi,
I have removed my original posts to avoid confusion. Changes to Sonos networking resulted in these no longer being relevant. See the solution in this thread for latest working solution in 2025
1 Like
Thank you very much for these details. I recently got a new router (Xiaomi Mi Router 4A gigabit). I wanted to configure it as second wireless AP (with adblock and SQM). It worked quite well. I am using a 21.02 snapshot build.
I've been following the sonos instructions carefully (and fiddled with it all Sunday). I just can't get it to work. 
Tried multiple times double checked the firewall rules etc. MCProxy is also running but apart from that it's hard for me to troubleshoot.
My config: 5 Sonos speakers in WAN (the WAN port of the Xiaomi Router connects to another upstream Modem-Router which connects to DSL internet - Xiaomi Router gets 192.168.171.61 from this upstream subnet). Sonos Apps (controllers) shall work in Xiaomi's br-lan (192.168.9.X).
mcproxy:
# Use your own MCProxy config file disabled
config mcproxy 'mcproxy_file'
option disabled '1'
option respawn '1'
option file '/etc/mcproxy.conf'
# Use OpenWrt UCI config enabled
config mcproxy 'mcproxy'
option disabled '0'
option respawn '1'
option protocol 'IGMPv3'
config instance
option disabled '0'
option name 'proxy1'
list upstream 'wan'
list downstream 'br-lan'
config instance
option disabled '0'
option name 'proxy2'
list upstream 'br-lan'
list downstream 'wan'
Sonos Firewall Rules:
config rule
option name 'SonosAccesAllow'
option src 'lan'
option dest 'wan'
option target 'ACCEPT'
option family 'ipv4'
list dest_ip '192.168.171.32'
list dest_ip '192.168.171.33'
list dest_ip '192.168.171.34'
list dest_ip '192.168.171.35'
list dest_ip '192.168.171.36'
list proto 'tcp'
list proto 'udp'
config rule
option name 'SonosRelayTCP'
list proto 'tcp'
option src 'wan'
option dest 'lan'
option target 'ACCEPT'
option family 'ipv4'
option dest_port '445 554 1400 1443 3400 3401 3405 3445 3500 3501 3689 4070 4444 5297 5289'
list src_ip '192.168.171.32'
list src_ip '192.168.171.33'
list src_ip '192.168.171.34'
list src_ip '192.168.171.35'
list src_ip '192.168.171.36'
config rule
option name 'SonosRelayUdp'
list proto 'udp'
option src 'wan'
option dest 'lan'
option dest_port '136-139 554 1900-1905 5353 6969 30000-65535'
option target 'ACCEPT'
option family 'ipv4'
list src_ip '192.168.171.32'
list src_ip '192.168.171.33'
list src_ip '192.168.171.34'
list src_ip '192.168.171.35'
list src_ip '192.168.171.36'
I can ping the Sonos and show their /support/review HTML pages. But issue is: Sonos Controller App on iPhone i.e. 192.168.9.120 cannot control the speakers (throws error: "Unable to connect to Sonos.."). Any help troubleshooting this would be highly appreciated.
Did you get it to work? I currently have a similar problem and I don't know how to identify the error.
I have three different interfaces
HOME - eth0.1
IOT- eth0.2
GUEST - eth0.3
Home is the one where my iPhone is located at. The Sonos speakers are connected to the IOT network.
I added the following lines to /etc/config/mcproxy
Is this correct or do you really have to add it to /etc/mcproxy.conf?
What is the difference?
# Use your own MCProxy config file
config mcproxy 'mcproxy_file'
option disabled '1'
option respawn '1'
option file '/etc/mcproxy.conf'
# Use OpenWrt UCI config
config mcproxy 'mcproxy'
option disabled '0'
option respawn '1'
option protocol 'IGMPv3'
config instance
option disabled '0'
option name 'proxy1'
list upstream 'IOT'
list downstream 'LAN'
config instance
option disabled '0'
option name 'proxy2'
list upstream 'LAN'
list downstream 'IOT'
I also added to /etc/config/firewall the following lines:
config rule
option name 'Access-Sonos-From-User-VLAN'
option dest 'IoT'
option src 'lan'
option target 'ACCEPT'
list dest_ip '192.168.102.128'
list dest_ip '192.168.102.187'
list dest_ip '192.168.102.198'
list dest_ip '192.168.102.222'
option family 'ipv4'
list proto 'tcp'
list proto 'udp'
config rule
option name 'Allow-Sonos-Reply-To-User-VLAN-TCP'
option dest 'lan'
option src 'IoT'
option target 'ACCEPT'
list src_ip '192.168.102.128'
list src_ip '192.168.102.187'
list src_ip '192.168.102.198'
list src_ip '192.168.102.222'
option family 'ipv4'
list proto 'tcp'
option dest_port '445 554 1443 3400 3401 3405 3445 3500 3501 3689 4070 4444 5297 5298'
config rule
option name 'Allow-Sonos-Reply-To-User-VLAN-UDP'
option dest 'lan'
option src 'IoT'
option target 'ACCEPT'
list src_ip '192.168.102.128'
list src_ip '192.168.102.187'
list src_ip '192.168.102.198'
list src_ip '192.168.102.222'
option family 'ipv4'
option dest_port '136-139 554 1900-1905 5353 6969 30000-65535'
list proto 'udp'
Unfortunately, I can't access the speakers (IOT) from the Sonos app (Home).
Do you have any tips on how I can identify the problem?
Does really nobody have an idea?
it drives me crazy ... i am able to control 1 of 4 sonos speakers and also a phone at the same vlan. but 3 sonos speakers are missing ...
also i am able not to control from my phone my pc (other direction)
This config worked for me for >6 months, and seems to have stopped since I recently upgraded my router to 22.03.3 (this is the only thing that has changed on my network that I can think of)
If anyone is still struggling with this - found a write up here that has got me up and running again:
Operating Sonos Speakers in a Multi-VLAN Network :: packetmischief.ca
I kept the config in place from Blowfly's write up, as this is in line with the instructions in the link too.
Configuring my firewall rules accordingly for my IoT and LAN zones for mcproxy as per the link, seems to now allow me to control my Sonos gear (in the IoT zone) from my phone (in the LAN zone)
Similar FW implementation applies to my avahi mDNS proxy service (this allows me to cast media to TV's and google speakers sitting in the IoT zone) link here:
Resolving mDNS across VLANs with Avahi on OpenWRT – Just another Linux geek (christophersmart.com)
Quite an old thread, but I still wanted to share my experience on this matter with you.
I didn’t get it to work with mcproxy, as apparently the UCI interface is broken. (Described in GitHub issues and also on the Wiki) I haven’t tried the explicit config file option yet.
In the end the solution for me was to use igmpproxy. However this didn’t work out of the box as well. For some reason someone decided the init script should create a firewall rule to block SSDP specifically. See here.
Unfortunately there is no real commit log for this repo, as it was migrated from an old SVN I guess and thus I don’t get the reason for explicitly blocking SSDP.
If you change the drop to accept in that init script, the device discovery starts working based on the described configuration.
2 Likes
@nbd You are listed as maintainer of that package. Do you have any idea why SSDP is blocked explicitly? Could we add a config parameter for choosing to allow SSDP? If so, i would create a pull request.
Thanks for the guidance. I was able to reproduce the results and successfully implemented on my network!
I am using OpenWrt 22.03.5 r20134-5f15225c1e on Ubiquiti ER-X with igmpproxy 0.4.1.
If you're still up for it, I'd say create a PR so this issue will get more exposure/fix gets merged.
May be a tangential question - igmpproxy manual says there can be only one upstream but multiple downstreams. Yet to me it looks more like one would want to isolate the Sonos speakers in one vlan and control them from more (for example trusted phones/PCs and say internet blocked home assistant instance on iot vlan.) . Is this others have considered? Is there such a solution?
I just started with the changes and setting up a environment to test my changes. Might take some time, as it will be my first contribution towards the OpenWRT project.
For anyone looking for a solution still, I was able to solve this using the udp-broadcast-relay-redux package on opkg.
The package is kina old, and the original source is now archived, but seems to work without issue for me.
I used this post for Sonos on OPNsense to get it up and running.
My 'controllers' are in the user network and the Sonos speakers are in the iot network.
After running opkg install udp-broadcast-relay-redux I updated the config to be:
# /etc/config/udp_broadcast_relay_redux
# mDNS
config udp_broadcast_relay_redux
option id 1
option port 5353
list network user
list network iot
option src_override 1.1.1.1
option multicast 224.0.0.251
# SSDP
config udp_broadcast_relay_redux
option id 2
option port 1900
list network user
list network iot
option multicast 239.255.255.250
# Sonos
config udp_broadcast_relay_redux
option id 3
option port 1902
list network user
list network iot
option multicast 239.255.255.250
I then created firewall rules to match what is shown in the reddit post:
config rule
option name 'Allow-Sonos-from-user'
option family 'ipv4'
option src 'user'
option dest 'iot'
option target 'ACCEPT'
list proto 'tcp'
option dest_port '1400 1443 4444'
option ipset 'SonosGroup dest' # all sonos IPs set as destination from ipset
config rule
option name 'Allow-Sonos-to-user-TCP'
option family 'ipv4'
list proto 'tcp'
option src 'iot'
option dest 'user'
option dest_port '445 3400 3401 3500'
option target 'ACCEPT'
option ipset 'SonosGroup src' # all sonos IPs set as source from ipset
config rule
option name 'Allow-Sonos-to-user-UDP'
option family 'ipv4'
list proto 'udp'
option src 'iot'
option dest 'user'
option dest_port '1901 6969 49152-65535'
option target 'ACCEPT'
option ipset 'SonosGroup src' # all sonos IPs set as source from ipset
Connection to speakers works without issues!
You could easily add addition VLAN as a controller group with the list network VLAN option in the config file. You would just need a corresponding firewall rule as well for that network. Or create a zone with both networks in it.
Hope this helps someone out!
EDIT: typos
I lost a little focus over the summer months, but as the last upgrade did override my adjusted config/scripts I took another run on setting up a dev environment and add a pull request for the igmpproxy. And I finally succeeded:
igmpproxy: Add config parameter to enable SSDP by thebub · Pull Request #25156 · openwrt/packages (github.com)
Now its up to the maintainers to merge the PR.
1 Like
See this Github based tutorial for step by step instructions and config examples for setting up Sonos with VLANS after the infamous 2024 major updates: https://github.com/itiligent/Sonos-OpenWRT-VLANs
The @thebub igmpproxy fix works great, but in my recent tests I can see there are some security isses that those attempting this should take note of before removing this restriction in the IGMPproxy launch script..
I believe the reason that UDP to 239.255.255.250 is specifically blocked in IGMPproxy script when all other multicast to 224.0.0.0/4 is allowed is twofold:
-
The default igmpproxy config attaches to the initial OpenWRT LAN and WAN interfaces, (until re-configured by the user).
-
uPnP uses 239.255.255.250 - therfore there is much potential here to inadvertently multicast uPnP directly to the WAN if uPnP package(s) are installed and active. See OpenWRT's warning on uPnP to WAN here: https://openwrt.org/docs/guide-user/firewall/upnp/start
As can be imagined, spamming uPnP to the WAN is a very bad idea, and I suspect many posts on this topic over the years have not taken this into consideration.
uPnP is somewhat legacy nowadays, but if in use, careful firewall rules and multicast configuration will be important here.
The solution in this thread takes a belt and braces approach by limiting the IP addresses available to IGMP proxy, locking down all implicit input & forwards at the router (input and forward traffic requires explicit firewall rules) and then blocking all 224.0.0.0/4 to, from and through the WAN interface as the starting point to prevent accidents.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.