A lot has changed with Sonos and their recent (controversial) software and networking updates, making most previous Sonos VLAN discussion obsolete in 2025.
The above Github link contains a complete step by step guide that will walk you through getting a 100% functional Sonos system in most common LAN + Guest access to IOT VLAN scenarios (including Airplay, Spotify, new device discovery etc.)
Sequenced steps allow easy cut/paste configuration, plus additional reference system config files from /etc/config are provided to help demonstrate all the main OpenWRT concepts such as bridge device VLAN filtering & VLAN interface creation with DSA, IGMP snooping, multicast proxying & locking down via explicit (rather than implicit) firewall strategy.
Thanks for this. It will serve as a useful reference.
Quick question -- do you know if this applies equally to Sonos S1 and S2? Since the systems were bifurcated some years back, I don't know if the network architectures have bee updated on both series (I can confirm, though, that the S1 system has continued to get updates, I just don't know how those updates might affect the networking aspects).
Edited after a little more thought:
I have not tested as I dont have any S1 devices. The 2025 solution might work right out of the box. The fireweall settings are geared for both old and new Sonos networking.
As far as I know:
Device discovery with S1 and S2 up to 16.1 use uPnP/SSDP 5353. and brodcast UDP on 6969. IGMProxy might relay all these just fine
If the 2025 solution does not work as is, a possible hybrid S1/S2/S80 solution could be to use this python script in conjunction with the 2025 guide: https://github.com/alsmith/multicast-relay
and run it with --homebrewNetifaces --ifNameStructLen=32 --noMDNS --interfaces br-lan br-iot br-guest . I used to use this some time back, and it worked ok. Not as snappy as the 2025 solution though.
Can someone tl:dr what’s this about. A few of my friends have Sonos and they all have a typical run of the mill wireless router. It works fine, and should, as that’s what 99.99% of all Sonos users use.
Why on earth would I want to use this guide if I had Sonos?
The title "Sonos with VLANs" should be a sufficient TL;DR, but for completeness sake... if your Sonos system is on a different VLAN relative to the phones/tablets/computers used to control the system, the controller app will not be able to connect unless the additional measures are taken as described in the GitHub link.
Yeah it should, but I needed that spoonfed. Thanks.
Anyways, so in layman’s terms, you would want this because you don’t trust the Sonos hardware, and the software/firmware innit and it’s communication with Sonos over the cloud because of potential privacy issues?
That and because you’re born a skeptic and are a tad anal about these things, so therefore you put the Sonos hardware on an untrusted iot clan while your phone/ipad/etc aka «the controller» on the trusted LAN vlan?
Personally, I have my Sonos devices on my trusted network, but others may feel differently about the trustworthiness of the hardware/firmware. However, the other angle could be a guest network -- you might want to allow your guests to control the music.
While Sonos does use cloud based music services, the controller connection is made locally -- it is expected that this will be an L2 connection (same network). It does not work over the cloud. If it did, none of this would be necessary.
There are lots of reasons one might structure their network with Sonos and other devices on different VLANs. Could be security, could be the organization of their devices, could be guest access, or anything else.... or maybe they're just into VLANs and networking concepts as a hobby or opportunity to learn new things.
Not anal at all if you look look at what Sonos is doing more closely.
Recent Sonos changes now allow devices to be accessed from the internet.. (I didnt ask for this feature and there is no way to opt out!).
Given the terribly poor software quality since Sonos took its stock public, and their panic at the market's reaction to this, placing Sonos devices in a much more restricted zone never made more sense. I'm quite certain Sonos is not thinking about security as much as they should, and these devices have microphones!
Also,giving guests access to Sonos from thier own device makes Sonos much more user friendly. In some corporate/retail situations, VLANs are required for PCI-DSS (credit card processing) or ISO27001 compliance, so maybe its not for you, but lots of people for years have been asking this question, and its never been more relevant since the recent (and very unpopular) updates. Lots of very good reasons to use VLANs with Sonos.
In the linked solution, catch all multicast rules are deliberately used for this exact exended purpose (all multicast is relayed between LAN, Guest and IOT.)
The only thing you should need to add is the additional firewall rules from LAN to IOT and IOT to LAN for all unicast traffic required by any device.
You can test this by temporarily adding a rule to allow any from lan->iot and any from iot->lan within the linked solution. If this works, please come back to the forum and let us know as this will be super useful for many.
Edit: If the above test works, you must lock down traffic correclty. I've translated these rules from a Google search. Give it a try and let me know. If you have success I'll make an new github solution for Chromcast based on the Sonos solution
config rule
option name 'Allow-LAN-to-Cast'
option src 'lan'
option dest 'iot'
option target 'ACCEPT'
list proto 'all'
list dest_ip 'google.cast.static.ip.'
config rule
option name 'Allow-Cast-TCP'
option src 'iot'
option dest 'lan'
option proto 'tcp'
option dest_port '8008 8009 8443'
option target 'ACCEPT'
config rule
option name 'Allow-Cast-UDP'
option src 'iot'
option dest 'lan'
option proto 'udp'
option dest_port '32768-61000'
option target 'ACCEPT'
Thank you for this thorough guide in an easy-to-read format. I'm attempting to follow it, but I am unsure how to solve Enabling Igmp-snooping and stp in my case. I do not have one bridge device each for each VLAN, rather only one bridge device and the VLANs defined on top of that through Bridge VLAN filtering in Luci. That meas I have one device for the bridge and three interface-definitions, having followed this video by onemarcfifty. I realize, that he mentions that I should "at least have one device that bridges all ports", meaning that I probably could (should?) break them out into different bridges.
I've tried enabling igmp_sniffing and stp on my one bridge, but I am not sure if that is correct and more importantly, the router did not seem to come back up after saving the setting and restart.
If you have any opinion or resource as to best practices here I would be very thankful. I am still pretty novice to OpenWRT and VLANs and haven't found anything myself.
As for chromecasts and VLANs, I have a working configuration, however specifically opening up port 5353 on IP 224.0.0.251. I will try with the catch-all rules you provided and report back.
Edit: You need 3 bridges , LAN. IOT and Guest. The vlan filtering is where to add vlans to these. You will use only the LAN bridge to add vlans in the vlan filtering section of Luci.
Its all there in the included config files (/etc/config/network) in the Github repo. Take a look. STP and and IGMP settings are all there too.
The config examples lay out the correct VLAN format for later OWRT versions using DSA. You can't use a regular interface for a vlan, you need at least 1 bridge device to create vlans with DSA. In this case you will need at least 3 bridge devices. Each of the bridge device at then attached to phyiscal ports/trunks and wifi SSID in the wifi config
config interface 'lan'
option device 'br-lan.100'
option proto 'static'
option ipaddr '192.168.100.1'
option netmask '255.255.255.0'
option ipv6 '0'
option delegate '0'
config interface 'guest'
option proto 'static'
option device 'br-lan.110'
option ipaddr '192.168.110.1'
option netmask '255.255.255.0'
option ipv6 '0'
option delegate '0'
config interface 'iot'
option proto 'static'
option device 'br-lan.120'
option ipaddr '172.17.120.1'
option netmask '255.255.255.0'
option ipv6 '0'
option delegate '0'
config device
option name 'br-lan'
option type 'bridge'
option ipv6 '0'
option bridge_empty '1'
option stp '1'
list ports 'eth0'
list ports 'eth1'
list ports 'eth2'
list ports 'eth3'
list ports 'eth4'
list ports 'eth5'
list ports 'eth6'
list ports 'eth7'
list ports 'eth8'
list ports 'eth9'
list ports 'eth10'
list ports 'eth11'
option igmp_snooping '1'
config device
option type 'bridge'
option name 'br-guest'
option stp '1'
option ipv6 '0'
option bridge_empty '1'
option igmp_snooping '1'
config device
option type 'bridge'
option name 'br-iot'
option stp '1'
option ipv6 '0'
option bridge_empty '1'
option igmp_snooping '1'
config bridge-vlan
option device 'br-lan'
option vlan '100'
list ports 'eth0'
list ports 'eth1'
list ports 'eth5:t'
list ports 'eth9:t'
config bridge-vlan
option device 'br-lan'
option vlan '110'
list ports 'eth2'
list ports 'eth5:t'
list ports 'eth9:t'
config bridge-vlan
option device 'br-lan'
option vlan '120'
list ports 'eth3'
list ports 'eth5:t'
list ports 'eth6'
list ports 'eth7'
list ports 'eth9:t'
list ports 'eth10'
list ports 'eth11'
I dont have any direct experience with udp-broadcast-relay-redux, but I would like to add a cauton for readers that this is an old and archived project and with this approach there are some potentially strong security issues if this is not done carefully.
Please see important notes on the OP's linked 2025 solution regarding securing multicast.
This old redux package relays UDP 5353 on 224.0.0.251. The notes cover in detail how this address space is shared by both SSDP & mDNS (SSDP is part of the broader uPnP suite ) so there is a risk of uncontrolled uPnP inadvertently punching holes everywhere if uPnP is enabled and multicast is not better controlled with strict firewall rules.
