Sonos speakers and applications on different subnets (VLAN's)
-
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.
-
This post is deleted! -
This post is deleted! -
@stephenw10 said in Sonos speakers and applications on different subnets (VLAN's):
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
Just wanted to chime in quick and mention that this has been working very well for me now for the past several weeks. Runs natively on pfSense (once you compile the code) and also has support for Sonos. I don't have any Sonos speakers to test with, but if pimd is not working this is an alternative worth trying out.
-
-
@sinbox_pfs said in Sonos speakers and applications on different subnets (VLAN's):
@tman222 Hi @tman222 - Could you pls post some step by step instructions for your method? Also, can you post your compiled binary for the package somewhere and share the link? I'm having issue running FreeBSD in a VM on macOS due to a OS compatibility issue...
Hi @sinbox_pfs and others - please see this thread for the compiled binary and instructions:
https://forum.netgate.com/topic/155698/how-can-i-get-this-udp-relay-package-for-casting-across-vlans/37
Hope this helps.
-
@tman222 thank you.
I ended up spinning a VM on a old Windows laptop and was able to get the binary working. It works like a charm! Great thing is that it doesn’t need any other packages like Avahi or PIMD ( I never had any 100% success with previously) nor does it require fiddling around with firewall rules. For the first time in 2 years, I have my Sonos working as I intend in my pfSense + Unifi ecosystem.
So far, I have the following tested and working correctly:
- Controlling and playing to Sonos speakers across VLANs via the Sonos App v2
- Airplay 2 (incl multi-room) works perfectly across VLANS.
- LIFX app to manage bulbs across VLAN’s works great
- Side effect - HomeKit also works across VLANs although I have only tested with anything else other than the LIFX bulbs. Now that I have my IoT network in working order, I feel like investing in more devices.
I just need to figure out a reliable way to keep the package running if/when pfSense reboots (eg via shellcmd).
@tman222 Do you use Cloudflare DNS? Not sure I understand what the hard coded 1.1.1.1 source address in the package does? So far I’m not seeing any conflicts with their DNS, but will keep an eye out if anything breaks.
-
What are the prospects for turning the udp-relay into a pfSense package? I've wrestled with this for a few years, and had hoped PIMD would solve things (but no luck). I'm not quite savvy enough to run a non-package daemon on my router for anything beyond an experiment - just too many points of failure to factor in.
I'm glad to see so much success with this one.
-
@indigomirage Based on the info I saw on the other thread, it looks like a request to include this as a package has been submitted, however, I'm unsure how long the process will take.
Like you I had tried unsuccessfully with PIMD and Avahi without complete success for the past 2 years. The process is easier than you think - esp if you follow the step by step instructions that @tman222 has posted above:
https://forum.netgate.com/topic/155698/how-can-i-get-this-udp-relay-package-for-casting-across-vlans/37
Basically, it involves copying the linked binary file (if you trust) or compile one on a FreeBSD VM on to pfSense's root folder. From there, all you need is the interface names from pfSense & you need to run the following commands from the terminal or Diagnostic>Command Prompt from the GUI (3 times, with a unique id each time). I have skipped a few important steps like taking a backup before you proceed & using ShellCMD to automate the execution of these when pfSense reboots.
For Enabling mDNS:
./udpbroadcastrelay --id 1 --port 5353 --dev igb1 --dev igb1.20 --multicast 224.0.0.251 -s 1.1.1.1 -f > /dev/nullFor Sonos:
./udpbroadcastrelay --id 2 --port 1900 --dev igb1 --dev igb1.20 --multicast 239.255.255.250 -f > /dev/nullFor LIFX:
./udpbroadcastrelay --id 3 --port 56700 --dev igb1 --dev igb1.20 -f > /dev/nullIn my case, dev igb1 was my LAN and all my IoT/Sonos devices are in the dev igb1.20 VLAN
-
@sinbox_pfs May I add that in some cases (like when you move the udpbroadcastrelay file to a Windows PC) you need to make the the file executable again, so if the file is grey and not red (pfSense uses the color red for executables) than
chmod 755 updbroadcastrelaySo I compiled and tested
udpbroadcastrelay...and can confirm that it works rather nice, if some of you are not getting PIMD working, then give it a try. Good luck.
