Sonos speakers and applications on different subnets (VLAN's)
-
@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
pimd
and 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
pimd
has 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/null
For Sonos:
./udpbroadcastrelay --id 2 --port 1900 --dev igb1 --dev igb1.20 --multicast 239.255.255.250 -f > /dev/null
For LIFX:
./udpbroadcastrelay --id 3 --port 56700 --dev igb1 --dev igb1.20 -f > /dev/null
In 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 updbroadcastrelay
So 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.
-
@baf
Can you provide an image of the firewall rules ???I am stuck at this part .... and i cant seem to get this to work
-
Can anyone take a look at how i configured things .
I cant get the speakers to work outside of the VLAN in the Sonos app.
i am attaching the pictures of how i configured things.
-
jimp,
I just wanted to thanks for your efforts with PIMD. I'm able to use the Sonos app on a secure network with the speakers on a VLAN, after several years of trying on Unifi and Untangle. I'm a recent convert to pfSense, but spent a few days trying to make this work. The key action for me was to reboot pfSense after I set up PIMD.
I had created extensive Sonos UDP and TCP pass rules following advice on multiple threads. I had enabled Avahi, all to no avail. When I rebooted, things worked. I've disabled Avahi and disabled the firewall UDP and TCP pass rules I have on the Sonos network. I seem to be relying only on PIMD.
My settings are all default, other than bind to none on the General tab and enabling desired interfaces on the Interfaces Tab. Multiple groups are listed on the Status tab.
I wish I had rebooted several days ago.
-
Hi @stan,
Thanks for reporting your experience with this.
I have to replicate what you have done:From PIMD:
General - Default bind: Bind to None
Interfaces: I have added the 2 interfaces that should talk to each other. In my case LAN, where I have my trusted devices that can access all the other networks, and IOT, where I keep untrusted ones and their access it limite to internet only. For each one I have only selected Interface Binding = Always bind.
Then you haven't added anything else in "BSR Candidates", "RP Candidates" or "RP Addresses".
I haven't created any firewall rule as you have suggested.Unfortunately this setup is not working for me.
I initially setup the Sonos devices by connecting to the same WiFi network of IOT but now when I open the Sonos App on my iOS device, I see all grayed out and after few seconds it tells me that there is a problem connecting to the devices.I suspect that you have a different configuration somewhere than mine. Any suggestions?
-
Blasterspike, the setup described above worked for awhile, then didn't. I've re-configured to rely only on the firewall rules. I'm not relying on PIMD anymore; in fact, I've removed it from my system. I still do have Avahi running, but that's just to enable guests to access the Sonos speakers with their own Apple Music and Spotify applications.
I've created two port aliases, Sonos_TCP_Ports and Sonos_UDP_Ports. The firewall rules permit traffic from the subnet with Sonos speakers to the subnets from which I want access the speakers using those ports. I also have a rule on each of the subnets from which I want to access to the speakers to the subnet with the speakers using those ports. These rules also "Allow IP options" (Advanced Options in the rule).
My port aliases are probably overkill, since I added whatever I found in various comments, but haven't gone to the trouble to try to whittle down the ports to see when it stops working.
TCP ports: 80, 443, 445, 3400:3401, 3445, 3500, 4070, 4444, 1400, 1443, 7000, 8080, 5000:5001
UDP ports: 136:139, 1900:1901, 2869, 10243, 10280:10284, 5353, 6969, 3722, 319:320, 32000:60000
If you do this and it works and if you successfully whittle down the ports, I'd be interested to know what your reduced ports are.