Sonos speakers and applications on different subnets (VLAN's)
-
I can only speak for myself and I don't like IoT's that are closed source, be it cam's, Sonos, smart power plugs etc. I have no idea what so ever what they (can) do and how well there operating system is maintained. As an example I have video door cam that has a telnet service running, no idea why this should be and why telnet is chosen and not SSH.
It's like your home, some use a burglar alarm system others only have lock, so each to his own ;)
-
I totaly agree. To be honest, I wish I could trust some companies to do their homework. I can't and don't want to control everything by myself.
-
That's why I like and use pfSense, I want to control the rulez, so what do you (dis)allow to go where. That's why by default every subnet (apart from the LAN) created can go nowhere.
Although a cheap router/fw (albeit from you supermarket) has good ingress block, you have almost no control over the traffic. In pfSense I decide what goes where.
-
@wellcomefit
For what it's worth, I've given up. I've solved the problem three times. Each time it worked for a few months, then stopped working with that solution. I didn't want to devote more time and effort.
I have a Sonos subnet. I've moved my smartphones to that and created rules for their access to other nets where needed. Not much is needed. Access to a NAS from smartphones for storage of pictures and access from the Sonos speakers to the NAS (limited to TCP port 445) for the music library. I use a firewall on the NAS and ACL on the NAS to control what the smartphones can get to.
It's also easy to switch the smartphones to my main data network when I want to get to other things. But I haven't had that need. This is a home environment, not a business environment, so your situation may be more complicated. -
Thank you Stan for the feedback.
I decided for myself that, it's not worth the effort right now. UDP_Relay sounds really promising and if this ever comes officially to Pfsense. I'm willing to give it a try :) Until then, I'll go with your solution and just create a separate VLAN for it and not connect the client and sonos network. -
just chiming in to thank @Qinn here for pushing this all forward, across a few different threads qinn was involved in, I was able to get this up and running in a few hours. I needed pimd, avahi, (both just from the package manager) and four firewall rules (in attached pics), setting an RP address in pimd was also required.
LAN interface Rules
NOTRUST interface rules (where sonos lives)
I might end up moving my sonos system to a sort of intermediary network, originally I put it on the same net as the rest of my iot stuff, but having to grant more trust to the sonos system than the rest of my iot systems.
maybe this helps someone, but really just meaning to say thanks for the forums here! pfsense is pretty cool
-
@packetperson99 Thanks ;) maybe also share your GUI PIMD settings?
-
192.168.40.109 is a sonos speaker -
@packetperson99; @qinn; @wellcomefit
Oh heck, I couldn't help myself. I've tried the solution above and it works. When I first open the Sonos app, it takes about 9 seconds to find the Sonos system. I'm not sure of whether I can stand the repeated anxiety of wondering whether it's going to connect during those nine seconds, so not sure whether I'm going to stick with this solution or go back to having things on the same network.
I do have a question, though. Of the four firewall rules, two are repeats of the other two, just in the different interface. I'm not sure what is accomplished by having a version of the LAN to NOTRUST rule on the NOTRUST interface, and by having a copy of the NOTRUST to LAN rule on the LAN interface. I set it up with all four rules. Then I disabled those two rules and it still works.
I'm not an expert. I'd be interested to understand what the rules do on a different interface. -
This post is deleted! -
Just to chime in, I don't have anything under RP Addresses and my 5 Ikea SYMFONISK speakers have been working reliably for over a couple of months on my IOT vlan. I guess if I ever have trouble in the future, I will try adding it.
-
@Stan i think youre right, i tested this pretty extensively as I moved my sonos systems to an intermediary network, I organized the rules by egress on the interface, also discovered i needed another rule for the 239.255.255.250:1900 traffic, so i ended up with two rules on the controller interface and three rules on the player interface
-
Since this solution worked, it prompted me to again find a solution for AirPlay to Sonos for the Apple Music app. That is now working for me as well.
A part of the AirPlay solution is to add (UDP) ports 319 and 320. With those ports, the Sonos app started up very quickly after it had been closed. This resolved my anxiety issue (see above). I'd recommend adding those ports just for the Sonos app.
The additional ports I'm using for Airplay are 7000 and 32000:65535. The high range is needed on the No_Trust to LAN rule for AirPlay to work. I added 319, 320, and 7000 to both rules and am not sure if they're needed in both directions.
If anyone fine tunes these additional ports (limiting them to one or the other direction), please post that here. -
@packetperson99 @Qinn thank you for creating this thread with how to make the Sonos speakers (ikea symfonisk in my case) work in diff vlans.
I've followed along, I have pfsense 2.5.0 with PIMD and Avahi from package manager, created the rules for the ports on both vlans.
What I was missing was allowing these ephemeral ports (30000:65535) open from sonos device into the secure vlan and the PIMD RP addresses. After that, everything started to work.
Finally after 3 days of reading many posts and trying different things, this is the one worked, and I consider the most up to date thread.
-
This post is deleted! -
I'm an AV tech with a decent networking experience. I've recently been trying to get pfsense working in a test setup for demand of the customers wanting separate networks for IoT devices, kids...., also starting to see a demand for this in some commercial applications as well.
pimd and Avahi have been helping so far.
Avahi - is good for mdns where the packets have a ttl=1 and need to be reflected/ rebroadcast to other vlans
pimd - is needed for PIM-spare mode "multicast routing" . PIM-SM is an advance of igmp proxy and also uses igmp on the back end which is why you need it disabled for pimd to work. Like igmp proxy you need to define the upstream and downstream links, which are the BSR and RP candidates and the allowed interfaces.
This guide has helped redirect my searches and advances in what I needed in network knowledge. Some helpful information to help resolve this was from youtube videos on ip multicasting for those getting a cisco network cert. They don't list ssdp specialty, but broke down how multicast works.
My test system is a Netgate 6100 with WAN port connected to ISP. WAN4(SFP+) reassigned to my lan downlink to my ubiquiti USW-PRO-24-POE switch and multiple vlans. For pimd I set it to bind to none and then added the interfaces i wanted. With the end game of trying to keep pfsense as secure as possible. I believe this removes all interfaces from being a candidate, because I couldn't get it to work with default until I added the BSR and RP candidates to be the WAN4 interface. For those in previous posts trying to add sonos devices as RP addresses need to try and reconfigure their settings.
This link also was of great help
https://forum.netgate.com/topic/156086/pimd-doesn-t-appear-to-work -
@mikedob
Thanks for you recent post. While I could still use the Sonos app from a different network, my experience had reverted to waiting 9 or so seconds for the app to find the Sonos system. Maybe I was relying on lingering states before.
I went to the link at the bottom of your post, which suggested adding a rule with allow packets with IP options checked. So on the network with the Sonos system (and only on that network) I added a rule to allow the IGMP protocol from any to any with allow packets with IP options checked.
The result is that when I restart the Sonos app after having stopped it from running even in the background, the Sonos system appears within a second or two. When I have not stopped the app, the system is there when I open it and when I switch among the networks I've set to use the Sonos app.
So it is a much better experience now. -
@stan said in Sonos speakers and applications on different subnets (VLAN's):
A part of the AirPlay solution is to add (UDP) ports 319 and 320. With those ports, the Sonos app started up very quickly after it had been closed. This resolved my anxiety issue (see above). I'd recommend adding those ports just for the Sonos app.
For future reference all you actually need to AirPlay across VLANs to a Sonos speaker is ports 319 and 320 UDP allowed from the Sonos VLAN to the player VLAN.
You then install the Avahi package, which will mirror bonjour/mDNS requests across the VLANs so discovery works.
The only real time you end up in a port opening/firewall rule rats nest is when you are getting Sonos Controller to work.
-
Earlier I've posted that I won't separate in a different VLAN. In hindsight this was a big mistake!
I'm using UniFi for my network and somehow a port connected to a Sonos speaker was identified as a downlink to my core switch.
That ruined my whole weekend. It caused a huge amount of packet loss and a downtime longer that I'm willing to admit.
TL:TR: don't make my mistake, separate your sonos system.
-
@somerino you need to make sure all your sonos devices are on the same network and spanning tree is on or rapid spanning tree. Sounds like you have sonos net enabled on some of the speakers on different network segments and its using the wireless radios to bridge them. STP and RSTP should stop this. Also verify in the sonos ap they are connecting to the correct network if wireless. Also check your port config for your access points on might not be correct
Symptoms you are describing are of an improperly configured network
