Sonos speakers and applications on different subnets (VLAN's)
-
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
-
That seems very unlikely. Are you sure you're not lookung at source ports from the LAN? Reply packets going back to them?
Steve
-
The package worked out for me also. In my case it facilitates the multicasting of my Onkyo Receiver over different VLANS, so I can use the Onkyo Remote app.
I have a "router-on-stick" set-up with a layer-3 switch. I wonder if and in which case it would be better to utilize the switch for multicasting. -
Does this work with the new Sonos S2 system?
I'm trying these settings without much success. Can anyone confirm that the new SONOS S2 software still works with these settings/ports/etc?
[Edit: Renamed 2.0 to S2]
-
OK. Wow!
Something I've wanted to be able to do for, what seems like, 5 years. Control Sonos across VLANs! Success!
But holy heck, do I need a LOT of ports open. I'd been looking at the ports that were required (Thanks @vacquah & @denix) and added them to to port alias lists. I made a UDP and TCP alias list and created two firewall rules, with allow options enabled. No dice.
I had to enable all of these ports to get it to work:
TCP: 80, 443,445,3400,3401,3445,3500,4070,4444,1400,1443,7000,8080,5000:5001,32000:49999
UDP: 136:139,1900,1901,2869,10243,10280:10284,5353,6969,3722,319:320You'll note these ports are familiar, but I discovered that reading https://felix-kling.de/blog/2019/sonos-dedicated-vlan.html said that you needed port 1400 & 1443, and it partially worked but I couldn't group speakers.
I then found this article when someone was trying to get their Unifi setup working, and discovered the additional ports to add (I've bolded them above).
Taken from the above link:
Sonos Control (Ports): 1400 and 4444
Sonos TCP (Ports): 445, 3401, 3445, 3500, 4070, 4444, 1400, 1443, 7000, 8080, 5000, 5001, 32000-49999
Sonos UDP (Ports): 136-139, 1900, 1901, 2869, 10243, 10280-10284, 5353, 6969, 3722, 319, 320Suddenly everything seems to work. At this point, I'm hoping to trim this down with this many ports open, is it really worth it to even try and firewall them?
However, I agree with @vacquah's comment:
I'd like to clean up that list of sonos ports. I think some of them are intended for outbound to sonos servers and some jsut for the internal lan. No need to open all those ports to my internal lan devices. So, id like to identify which ones are outbound and which ones are for the devices on the lan only.
PIMD is used across both of these VLANs. I forsee a lot of trial and error to whittle this list down.
-
This post is deleted! -
This post is deleted! -
I also finally looked into doing this after years of seeing people struggle with making it work. A friend did it and got most of the functionality by using Avahi alone, so that gave me the push I needed.
I have 9 Sonos devices, 4 of which are seen as 1 by the app (soundbar with sub and rears). I am running S2. I have Android, iOS and a Harmony that control the speakers. I use Spotify Connect. I have the Sonos on their own separate VLAN and my controllers on a trusted LAN.
With Avahi and some Firewall rules, I got my Android and iOS apps to control the devices. I ran into issues moving the Speakers to the SSID of the new isolated VLAN for them, but that's a different story. (Sonos speakers REALLY like to hang on to their DHCP leases unless you power cycle them).
The Sonos Controllers and Spotify Connect work great. I used a basic port list from Sonos originally and then went through the firewall logs to add any missing ones. The first I found were 1400 and 1443 that were not mentioned elsewhere and made a huge difference once allowed.
The one thing I did notice was the use of high UDP ports. The speakers kept trying to reach the iOS and Harmony controllers using random high UDP ports. I found that the devices on the trusted LAN were sending UPnP requests with the same high UDP ports that the speakers were responding to. So, for example, the Harmony IP was requesting port 58748 and then the speakers were trying to reach it on that same port. iOS app behavior was similar, but different high UDP port. I was seeing these in the Firewall logs as part of the default deny on the Sonos VLAN. I didn't want to open my rules to allow the large UDP range that would allow this to work.
I then realized that my soundbar was still hardwired, something I did to move the speakers over to the new SSID. With the soundbar hardwired, the SonosNET wireless network had become active, and the traffic was behaving like above on the iOS controller. Once I removed the ethernet cable from the soundbar, the iOS app stopped trying to connect using the random high ports and now uses 1400 and 1443 directly to the Speaker IPs it knows. So, something to keep in mind for those needing the high ports @BCinBC
The Harmony hub is still trying to do this UPnP method, and I haven't tried enabling UPnP in such a way that would only allow it between the VLANs (is that even possible). Would be nice to enable the high UDP port based on incoming packets and then remove after a certain amount of time.
The one issue I still have, and something that is probably not worth the hassle, is setting up a controller app for the first time from the trusted VLAN. This is now just going to be a side project since I can easily join the Sonos SSID and make it work.
To see if I could fix this, I installed PIMD and I can see my Trusted LAN devices in the table, and some speakers. I added all the static Sonos DHCP reservations as RP Addresses, but didn't add anything to BSR or RP Candidates. The functionality of my apps seems to be the same, so I am not sure what PIMD is doing for me here. I see Multicast traffic traversing the VLANs, join messages and all. So it's helping the Speakers and controllers communicate, but not helping with initial app setup.
Has anyone been able to get a new controller app (Android in my case) to connect to an existing Sonos system that is in a separate VLAN? Or does everyone just usually connect to that VLAN with the device running the controller, set it up, and then move back to the trusted VLAN?
-
@motoridersd Avahi won't suffice, you need and IGMP proxy and the default IGMP proxy that's in pfSense won't work. So to be short you need PIMD please take a look here where I explain how it Sonos app and device that are on different VLANs can work.
https://forum.netgate.com/topic/139218/sonos-speakers-and-applications-on-different-subnets-vlan-s?_=1597667427234
When I created the above post PIMD could only be installed from the CLI (command line interface). Nowadays the devs from pfSense have created a GUI and you can install it using the package manager in the pfSense menu, Hope this helps!
Greetz Qinn
-
Thanks @Qinn. Like you mentioned, the apps remember the IPs of the speakers once they have been setup. Avahi helps get Sonos Connect and Airplay to traverse the VLANs.
Even after installing PIMD, I cannot get my Android app to find the speakers if I clear its config. My Harmony Hub is also unable to find them. I do have more restrictive firewall rules in place, but I've tried to manually resolv any blocks that show up in the logs. I haven't tried opening the rules completely, I should do that to see if it works.
My solution so far is to just connect to the same WiFi network as the Sonos, discover them, and then go back to the main VLAN where the apps work fine thanks to remembering the IPs.
Another issue I am running into is that the Harmony Hub does not always use ports 1400 and 1443 to talk to the speakers like the iOS and Android apps seem to do. The Harmony tries to use SSDP (UDP 1900 to multicast/broadcast) to define the UDP port to be used to communicate with the speakers, and then the speakers respond with that high UDP port. Since the port is randomized, I had to open a large range (40000-60000) to the Harmony Hub IP from the Sonos VLAN. This resolved the Harmony connectivity issues, but pokes a considerable hole in the Firewall.
-
@motoridersd As I said you don't need Avahi that's for Bonjour or mDNS, but you need an IGMP proxy like PIMD and I can confirm, as many others have tried my approach and got it working.
Maybe you can try 2 things, first let IP packets through from both sides, so from the VLAN where the Sonos applications are as well as where the Sonos Devices are. So to "Allow packets with IP options to pass. Otherwise they are blocked by default ".
Second do it manually, so not using the GUI. So take a look at what I wrote under Installation in my post at he link https://forum.netgate.com/topic/139218/sonos-speakers-and-applications-on-different-subnets-vlan-s?_=1597667427234
Btw my advice is to start with all firewall rules on the 2 VLANs disabled and only 1 allow all rule with "Allow packets with IP options to pass" and then gradually enable your rules on by one and see what happens, well of course when it safe to do so, as I don't know nothing about the what and how on your VLAN's. On the Harmony hub I can not comment.
-
I opened up my rules to allow anything, and logged the traffic. I discovered that if I reset my Android app and try to join an existing system across VLANs, the traffic that is being logged is UDP traffic to a random UDP high port. If I create a rule to allow this kind of traffic (using ports 40000 through 60000) I can get my Android app to work every time after clearing its data.
The iPad app is also using these random high ports when it launches again.
So this seems to be the trick, at least with S2, to get the controllers to play nice with the speakers. I don't like having 20000 UDP ports open, but I don't think there is a way to dynamically open these while watching SSDP.
The controller will send an SSDP multicast message (239.255.255.250 port 1900) and will include the port it wants to use (it will be the source port of the UDP packet). The speakers will then try to talk to the Controller using that high UDP port. Without a blanket rule to open them all, the communication will fail if your inter-vlan rules are too restrictive.
-
In the the firewall rules did you, as I suggested, enable this?
-
@Qinn can you share your screenshots with the gui on how you got this to work. well appreciated
-
@2exlcusive Sorry I can not, as I still work from the CLI
-
Just to share my experience on this: I've been trying to run
pimdand make Sonos work across my vlans for weeks, without much success. I followed the tips here, opened all firewall rules, installed pimd manually vs. pfSense package, went back to pfSense pimd package, configured RP priorities, and... still nothing. Clients simply couldn't join the existing Sonos system, unless they had already connected before and had the Sonos IP cached locally.Finally I got tired and I decided to try running an external multicast relay between vlans (source code here) and, to my surprise, it worked on the first try! Flawlessly. Zero configuration, no package installations, no fudging with RP priorities or any of that nonsense.
For the time being I'm running it on a server with physical interfaces to each vlan, but I don't see why a Raspberry Pi with virtual interfaces to all vlans wouldn't work equally well.
If you're frustrated that nothing else works, and don't mind running your own server, give multicast-relay a try.
-
There's a similar package you can try that runs on pfSense directly:
https://forum.netgate.com/topic/155698/how-can-i-get-this-udp-relay-package-for-casting-across-vlansThough pimd should work fine for Sonos. It clearly is working for others here.
Steve
-
@guiambros Could you reveal your config on multicast-relay?
-
@Qinn That's the beauty: no config whatsoever. I just have a Linux server with physical interfaces to both VLAN I want to combine, and just run
sudo python multicast-relay.py --interfaces <list each interface here>and that's it. It watches for Sonos discovery packets in one interface and forwards to the other, and vice-versa.Having said that, I haven't properly assessed all the risks yet. I don't like the idea of something forwarding all packets; it kinda defeats the purpose of having VLANs to isolate traffic in the first place (but
pimdhas similar behavior and would have to be locked down as well, so not a huge difference).Also it's Python and running as root, and while the code is small and straightforward to read, there's always a risk of some unforeseen vulnerabilities.
But I must say I'm glad to at least have Sonos working for the time being. I'm just still having trouble with Spotify Connect, so further investigation is needed (but that's a whole another topic).
-
@guiambros I got Spotify Connect to work using Avahi, for the most part. I still have one host that is somehow getting NATted out the WAN interface even though it shouldn't. Firewall rules on the WAN are preventing the traffic from leaking out. It's most likely an Avahi bug.
