Having read through a number of different setups for getting Sonos working on a separate VLAN, I thought I’d post my setup. I find that a lot of these setups are very specific to the hardware involved, so the more examples, the better.
I have two Sonos networks in two different locations, connected at all times via site-to-site VPN. My problem was that when I moved from location A to location B, my Sonos controllers (phone and laptop) would tend to stick to the last working location, and not roam to the “home” location.
The only simple workaround I found was to temporarily disable the VPN connection, and restart the controller so it would find the local Sonos network and “forget” the remote Sonos network.
Frankly, Sonos should give you control over which network you’re looking at - as Ring and Nest do (which I also have in both locations). Absent that, though...
In basic terms, my setup includes Ubiquii Unifi switches and APs in both locations (highly recommended, but not necessary to this solution). I also use WatchGuard firewalls in both locations (Ubiquiti USG doesn’t support dynamic IPSec).
I decided to segregate the two Sonos networks on separate VLANs in both locations, and not expose those VLANs to the VPN. Within each location, each Sonos network is “trusted”, so all traffic can pass to/from the local LAN, and the Sonos VLAN has Internet access (I mostly stream SiriusXM). As it happens, I used the same IP range for each Sonos network, but any IP range will do.
Critical to making this work was to allow the Sonos devices to be discovered from each LAN. In order to do that, I enabled WatchGuard’s built-in multicast route support, which was necessary, but not sufficient. The LAN interface and the Sonos VLAN interface were both added as multicast interfaces, and I selected “RP Candidate” for each LAN interface. I don’t know if this is necessary, but in the vague description of what “RP Candidate” does, it seemed reasonable.
Once I did that, I could see both the Sonos devices and the controller(s) show up in the multicast routes monitoring UI on the WatchGuard, but the controller wouldn’t yet pick-up the speakers on the VLAN.
Looking at both the WatchGuard logs and using tcpdump on a controller machine (macOS), I could see that Sonos would send an SSDP broadcast (UDP port 1900 to 255.255.255.255), followed by a multicast packet, also to UDP port 1900. Both were rejected by the WatchGuard by default. Ignoring the broadcast packet, as it can’t be routed anyway (bridged, yes, but I’m avoiding bridging due to the VPN), I focused on the multicast SSDP packet.
When you enable multicast routing, the WatchGuard establishes two default rules allowing PIM and IGMP traffic, but neither of those rules cover SSDP.
I defined an “SSDP” rule, covering UDP ports 1900-1905 (I did see occasional port 1901 traffic). For source and destination, I used the WatchGuard denial messages in the logs as my guide, as well as the default PIM/IGMP rules, and put:
Source: Any Trusted, Any Multicast
Destination: Any Trusted, Any Multicast, Firebox (the WG), and 239.255.255.255/24.
It’s quite possible that the sources/destinations could be simplified, but immediately when I enabled this rule, the controllers on the LAN detected the Sonos speakers on the VLAN. And, because the Sonos VLAN isn’t on the VPN, no more problems with controllers roaming between locations.
A perhaps simpler solution would be to keep Sonos on both LANs, and use firewall rules to block them from the VPN, but that would require static addressing of the Sonos speakers, and I prefer a more “out of the box” setup, as it makes adding speakers easier.
At one point or another I also did play with routing mDNS traffic, but I found this to be more trouble than it was worth, and I wanted a solution that didn’t require any additional hardware/software. This is what worked for me. I may still play with mDNS, as I do need to roam Time Machine across my VPN, and Apple (also) does a poor job of supporting roaming. But in my case, mDNS isn’t needed for Sonos to work.
Hope this helps...