Sonos speakers and applications on different subnets (VLAN's)

[wanabe]

@johnpoz said in Sonos speakers and applications on different subnets (VLAN's):

Sonos is meant to be on the same network your phone and tablet you use to control them join.

yes, i know that's is how it is designed, but, you know how we are, always looking for a work-around

[edz]

@johnpoz I do agree with what you're saying!

I joined my Sonos VLAN (created a temporary SSID on with the same VLAN tag) and discovered the Sonos bridge. This was a one off activity and I can now discover the Sons speakers without the need to be on the same Sonos network, although there is a quirk with their iOS app which requires the wifi to be toggled off and on for it it work. The macOS has no issues discovering the Sonos system after the initial discovery.

[JeGr]

@johnpoz said in Sonos speakers and applications on different subnets (VLAN's):

Your dropping 1k$ on a couple of speakers, how about get a real freaking switch is all I am saying ;)

Actually - nope ;) Thanks to the IKEA coop, you can pick up Symfonisk Speakers (with about the same tech as a Sonos One) for as less as 99$/179$ (if you take the shelf or lamp speaker).
Also I'm running very capable switches, but do I want to set up the networks on my switch (with bad filtering if at all) or do I want them on my actual firewall that can do filtering oh so much better? Sure thing :)

But as this whole pimd setup isn't working (was only a test anyway) for me at least, I'm happily stay as it is with all the "cast"ing hardware like Chromecasts and Sonos in the streaming VLAN and just control them via my WiFi Setup (Radius-based VLANs and an additional classic WPA2 one for the streaming thingies as some of them don't speak "enterprise" WiFi). Works well enough. But with pimd working there had been a chance for wife's and kid's phones to just stay in their WiFi VLAN but able to stream/control the cast boxes from there without having to add them to the casting VLAN. Makes outbound NAT and filter rules easier if you can set up the whole VLAN instead of having to group IPs together, do Alias groups yada yada yada. Also as ISPs IPv6 is pretty fucked up, I'm using a big /48 tunnel from he.net but the Casting VLAN has IPv6 disabled or no streaming TV for us (Prime and Netflix are complaining about being in US rather then EU blahblah Geofencing). That's why I put those phones and other trusted WiFi stuff in it's own VLAN with IPv6 enabled.
Yeah you could set that up, too, but it's a mess and having it separated and clean is really fun. But so be it, switching WiFi to control it is :)

True... I would have sonos myself - but would not be able to get it past the budget committee (wife) hehehe

Just have a look at those :)
https://www.ikea.com/us/en/news/symfonisk-wifi-speakers-pubaafe6500

I bought the small soundbar from Sonos as the new TV came and it wasn't that much more or less expensive than other solutions but as we also listen to radio, streaming, audible etc. it was quite appealing to buy the Beam at that time. Added two rear speakers with the IKEA ones (the shelf speakers) and they are great. Maybe lacking as a single/pair but as surround addition they are quite nice. Just added a lamp speaker in the daughters room as she needed a lamp anyway and loves listening to music and audiobooks while doing other stuff so the system pretty much grew by itself

[johnpoz]

@JeGr said in Sonos speakers and applications on different subnets (VLAN's):

but do I want to set up the networks on my switch

This is completely not understanding how multicast works...

[Qinn]

Sonos utilizes the Simple Service Discovery Protocol (SSDP) to discover devices on the network. SSDP uses the site-local multicast address 239.255.255.250 and UDP/1900 for IPv4.

The Sonos controller software discovers the Sonos players by joining the multicast group 239.255.255.250, thus the network needs to support and forward multicast.

[JeGr]

@johnpoz said in Sonos speakers and applications on different subnets (VLAN's):

@JeGr said in Sonos speakers and applications on different subnets (VLAN's):

but do I want to set up the networks on my switch

This is completely not understanding how multicast works...

Nah I get you. Just wanted to point out the reasoning why to seperate in the first place and why most people (in home environment) try minimizing the main point to configure things to only one instead of multiple (switches, etc.). But yeah, you could use the switches to forward multicasts, only it's often a WiFi (only) setup so potentially no switch involved :)

[jimp]

@edz said in Sonos speakers and applications on different subnets (VLAN's):

@jimp said in Sonos speakers and applications on different subnets (VLAN's):

Captive Portal would be my top suspect, followed by floating rules.

Hmm, I don't have Captive Portal enabled on pfSense, I'll check floating rules but I am seeing IGMP traffic coming in on my Sonos VLAN. I am receiving this error on 2 VLANs, one with hard wired Sonos speakers and the other on my WLAN VLAN. I'll check if Unifi is blocking any multicast traffic on WLAN, but I'm sure I turned this off previously as it caught me out when I setup Avahi.

The error you showed would be outgoing traffic blocked, not incoming. So you may see it enter that interface, but something is preventing pimd from transmitting. And the error suggests it's firewall-related, which means things like Captive Portal or floating rules. All traffic is allowed outbound by default so it must be something that's been configured on there.

[chpalmer]

@edz

Firewall rules you have made to pass multicast are UDP.. right?

[edz]

@jimp said in Sonos speakers and applications on different subnets (VLAN's):

The error you showed would be outgoing traffic blocked, not incoming. So you may see it enter that interface, but something is preventing pimd from transmitting. And the error suggests it's firewall-related, which means things like Captive Portal or floating rules. All traffic is allowed outbound by default so it must be something that's been configured on there.

@chpalmer yes I am certain UDP was allowed on all interfaces.
Anyway...I took the brute force method - started from a fresh install and went back to 2.4.4. Followed the screenshots above and IT WORKED! Now running 2.4.5 RC and things are working great, thank you all :)

[wanabe]

As I had promised in an earlier post, I would like to share my experience using pimd pkg v0.0.2 configured with the same values as the manual installation. After spending hours selectively deleting and playing with these settings, I have come to a few modest conclusions. It should go without saying that your experience might not be the same due to your setup. My setup is relatively simple, I have my wired desktop clients, WiFi AP clients and Sonos devices each on separate interfaces and subnets. These are physical interfaces and not VLANs.

The "Tree Switch Threshold" settings which had been previously configured as "Threhold Type>Packets" and "SPT Interval>100" do not seem to be necessary. I went back to the default settings without any impact.

The BSR (Boot Strap Router) Candidates and RP (Rendezvous Point) Candidates settings, however, appear to both be critical. As a matter of fact, the Rendezvous Point address is actually listed in the status report under "RP Address" . A Rendezvous Point address does not appear to be selected without also setting the BSR Candidates values.

I did play around with changing the interface on these two settings. The description on both state "When set to "default", the feature is enabled without a specific interface, which will default to the highest available IP address." In my case, the highest interface address is the interface dedicated to my Sonos devices. I tried changing it to my LAN interface but it did not seem to make any difference. It still seemed to work. Although, it doesn't seem to impact my set-up I would be very interested in learning under what conditions one would chose one interface vs another. It might make a difference for someone else.

A question for @jimp . Should there be default settings for BSR Candidates and RP Candidates? There appears to be for the manual installation.

As all of this is completely new to me, I have made an attempt to educate myself as to exactly what these settings mean. Unfortunately, this stuff is way over may head and gets complicated quick . To quote @johnpoz "...routing multicast is pretty high level networking shit... " I would certainly agree. Maybe one of the fine members of this forum would be willing to offer us newbies a primer on this topic?

For those Sonos owners who are using Spotify, you no doubt have come to enjoy the ability to route your listening to a variety of devices including Sonos. Spotify calls this Spotify Connect. As a matter a fact, I generally access my Sonos devices when I am listening to Spotify via the Spotify app and not the Sonos controller app. What I have discovered is that (with my set up), Avahi is necessary for this to work across subnets. It does not work with pimd alone. Whether pimd is even needed I am a bit uncertain. I have not done extensive testing, but I have turned off pimd and Spotify Connect still discovers my Sonos system. My Sonos controller stops working but the Spotify App still works. I have tested this using the Spotify iOS app and both Linux and macOS desktop apps.

[jimp]

@wanabe said in Sonos speakers and applications on different subnets (VLAN's):

A question for @jimp . Should there be default settings for BSR Candidates and RP Candidates? There appears to be for the manual installation.

It's something we can consider. I didn't put anything in by default because originally the suggested configs earlier in this thread for pimd only mentioned enabling/disabling interfaces and nothing about BSR/RP/etc.

If I did make a change like that it would only affect brand new installs and not upgrades.

[xeroiv]

Thanks for all the good information here in this thread. Because of it I have a mostly working setup, however I don't know of anyone here can help me with the last pieces of my setup because I am using HEOS rather than SONOS. The Denon AVR app works across vlans but the HEOS app has a curious behavior. Each time I launch the app the first input that I provide the app gets executed but the UI doesn't update and it doesn't respond to further commands. I'd appreciate a little help on how to narrow down what configuration issue I may be having.

[sinbox_pfs]

Hi @xeroiv , Sorry, I don't have a Heos Speaker to test this out for you, but suspect HEOS may have different ports that it is using?

Are you able to share your firewall rules on how you got the Denon AVR app to work across VLAN's?

@All - Thanks for sharing all your inputs thus far. However, I have only had limited success following inputs from this thread :

• Ability to manage my Sonos using the the Sonos Controller app on my LAN
• Unable to Airplay to Sonos devices from outside of the VLAN
• Lock screen controls on iOS don't work, but I suspect this is a Sonos App limitation, rather than anything to do with the firewall rules.

[spaceboy]

Hi all,

checking back in after 6 months or so. i see a lot of progress has been made and that now pimd is an official package. previously i couldnt get this to work but that would have been at least partly to my incomplete understanding of firewall rule requirements. currently i have enabled pimd on pfsense 2.4.5 and disabled WAN and OpenVPN interfaces. Leaving it binding to LAN, IOTVLAN and Guest Wifi. Currently i have firewall rules allowing everything (inluding ip options) from LAN to IOTVLAN (where the SONOS speakers reside) and Guestwifi and IOTVLAN. I plan to tighten these once PIMD is confirmed as working.

I also configured BSR and RP candidates as suggested on this page, priority 5 and 20 respectively.

But still no connection between a controller on LAN and the speakers on VLAN. Any suggestions on anything i can look at?

Really appreciate the work done so far and hopefully i can get the final bit over the line now!

Cheers!

[spaceboy]

just a note to confirm that shortly after posting the above i got it working. PIMD settings, Bind to All, disable on WAN and OpenVPN, nothing else. Set Sonos speakers to a fixed ip on the SONOS VLAN and i'm required to disable and re-enable wifi after opening the SONOS app. Other than that all good. Next step to tighten up the firewall rules. Thanks for implementing PIMD!

[baf]

This was a slight pain to get going, so I figured I'd post my whole experience, since some folks seem to be hit or miss with it. I set up PIMD with Tree Switch Threshold type of packets, value of 0, interval of 100, I added a default BSR candidate with priority 5, and a default RP candidate with priority of 20. I'm not sure if these settings were necessary or not, as they didn't fix my issue.

The most important part for me was tuning in my firewall rules.

From the VLAN my Sonos devices are in (IoT vlan, so it's pretty locked down from local devices):

• I was already allowing UDP from IoT network to 224.0.0.251:5353 (for MDNS), with advanced: allow ip options
• Allow UDP from IoT network to 239.255.255.250:1900 (for SSDP), with advanced: allow ip options
• Allow TCP from Sonos (I created an alias to list out the devices) to my LAN VLAN on ports 3401 (iOS) and 3500 (Android). This was the important piece in getting the app to actually work.
• I also have another copy of the 3401/3500 rule allowing traffic to my guest VLAN as well.

My LAN VLAN is wide open, so no further configuration necessary there.

My guest VLAN is also locked down and disallowed from local services. The applicable firewall rules I have there are:

• Allow MDNS and SSDP (same as above)
• I had already configured port forwarding as necessary to allow AirPlay to my AirPlay devices (and included the Sonos devices in that list). I'm allowing TCP 80, 443, 554, 3689, 5000, 5297:5298, 7000:7100, and 49152:65535 as well as UDP 319:320, 554, 5298, 5350:5351, 7000:7100, and 49152:65535. I may try to tighten these up at some point.
• Additionally, to get airplay to work for guest devices to Sonos, I had to punch a hole allowing TCP 32000:49152 from the guest network towards the Sonos devices. For whatever reason, they start using random ports from 32000 for AirPlay versus my Apple devices that start at 49152.

I seem to have full access from the iOS Sonos app on my primary LAN and guest VLANs, as well as being able to AirPlay to the speaker as well.

Hopefully this helps someone. I saw a lot of discussion about PIMD settings, not sure how important those were as nothing worked until I started digging more and found out I need to allow Sonos to communicate back to the device running the app (https://felix-kling.de/blog/2019/sonos-dedicated-vlan.html).

[Netgator]

Hi guys,

first off - I successfully run a setup where..

• the (Android) controller is in a "Trusted"-VLAN
• the SONOS speakers are in a "IoT"-VLAN

..by just adding a single, simple firewall-rule that allows "IoT" to communicate with "Trusted" over TCP/3500. "Trusted" can be considered as a standard "LAN" (so no specific rules).

No Avahi, no IGMP proxy, no pimd are utilized.

What I want to achieve:
I have a running openHAB installation in "LAN" and want to include my Sonos speakers with a specific binding, that uses device discovery via uPnP.

What doesn't work:
As everything is working with the Android controller, but not with openHAB I now installed Avahi and pimd (as I learned that pimd doesn't replace Avahi) and configured everything as described in this thread. In pimd's status tab I can see various entries in the Multicast Routing Table, also in regards to my Sonos speakers - but only if I put an RP Address as mentioned earlier here.

pfSense - 2.5.0-DEVELOPMENT
Avahi - 2.1_1
pimd - 0.0.2

My questions:

1. Do I really need to put two RP Addresses for each Sonos speaker (one for Unicast and one for Multicast)?
2. As openHAB still doesn't find the speakers, is there any other way to "forward" that uPnP discovery from "LAN" to "IoT"?

Many thanks!

[DominikHoffmann]

@Qinn said in Sonos speakers and applications on different subnets (VLAN's):

I have been looking for a solution to have Sonos speakers and applications work across VLAN's using pfSense…

I tried it, and it doesn’t work for me. I am wondering, whether you see anything wrong with this picture:

[atrv7]

Why is it that I can only get this working when I open up ports 10284 all the way until 59999 from my Sonos VLAN to regular LAN?

I have all the regular Sonos ports open as well but without that massive range above, I cannot access my Sonos devices...

The only reason I thought to open those is because I noticed activity on those ports when using packet capture in my pfsense router and trying to connect to my Sonos devices.

What are these ports being used for and why do they seem to change each time I open the Sonos app on OSX and try to connect?!

Thanks in advance for your help and for all the great info in this thread.

-Andrew

[stephenw10]

That seems very unlikely. Are you sure you're not lookung at source ports from the LAN? Reply packets going back to them?

Steve