Sonos speakers and applications on different subnets (VLAN's)
-
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
-
@mikedob I've activated RSTP on all switches and per port there's an option to toggle on STP. I know you shouldn't use two spanning tree protocols. (But there's no other option, I could disable the STP per port)
Indeed there's somewhere a bridge, because some Sonos don't have a direct ethernet cable connection.
There's not much I can check on the AP Port. I've created a dedicated VLAN for the sonos and made an respective WLAN. The uplink port to the AP is tagging the sonos traffic. -
I installed this package a while back, and recently re-installed it since I added a Sonos speaker to my network.
However, no mater what interfaces I select, my status page always shows this:
Virtual Interface Table ====================================================== Vif Local Address Subnet Thresh Flags Neighbors --- --------------- ------------------ ------ --------- ----------------- 0 10.57.0.1 10.57/24 1 DR NO-NBR 1 172.113.115.113 172.113.96/19 1 DISABLED 2 10.57.10.1 10.57.10/24 1 DISABLED 3 10.57.20.1 10.57.20/24 1 DR NO-NBR 4 10.57.30.1 10.57.30/24 1 DR NO-NBR 5 10.57.40.1 10.57.40/24 1 DR NO-NBR 6 10.57.0.1 register_vif0 1If I choose bind to all, and don't add any interfaces, I only see the interfaces above. I have about 3X that number of interfaces now. It should be showing
10.57.25/24,10.57.35/24,10.57.45/24,10.57.50/24,10.57.55/24, and so on. But not matter what, the status page always shows the same interfaces.It's as if it's cached in a settings file, and no matter the changes I make, no new interfaces show up, and no interfaces get removed.
If I set the default bind to none, and then add some of my newer interfaces from the last time I installed pimd, the service won't start, and I get these errors in the logs:
Oct 13 22:21:35 pimd 5196 Cannot forward: no enabled vifs Oct 13 22:21:35 pimd 5196 /var/etc/pimd/pimd.conf:7 - Invalid phyint address 'igb2.25' Oct 13 22:21:35 pimd 5196 /var/etc/pimd/pimd.conf:6 - Invalid phyint address 'igb2.35' Oct 13 22:21:35 pimd 5196 pimd version 2.3.2 starting ...What am I doing wrong? Is it possible, via CLI, I can uninstall the package and it's settings so I can re-install a fresh copy with fresh settings? When I re-install via the GUI, I get the same issues above.
I'm on pfSense 22.05, and pimd 0.0.3_5.
-
@offstageroller said in Sonos speakers and applications on different subnets (VLAN's):
I installed this package a while back, and recently re-installed it since I added a Sonos speaker to my network.
However, no mater what interfaces I select, my status page always shows this:
Virtual Interface Table ====================================================== Vif Local Address Subnet Thresh Flags Neighbors --- --------------- ------------------ ------ --------- ----------------- 0 10.57.0.1 10.57/24 1 DR NO-NBR 1 172.113.115.113 172.113.96/19 1 DISABLED 2 10.57.10.1 10.57.10/24 1 DISABLED 3 10.57.20.1 10.57.20/24 1 DR NO-NBR 4 10.57.30.1 10.57.30/24 1 DR NO-NBR 5 10.57.40.1 10.57.40/24 1 DR NO-NBR 6 10.57.0.1 register_vif0 1If I choose bind to all, and don't add any interfaces, I only see the interfaces above. I have about 3X that number of interfaces now. It should be showing
10.57.25/24,10.57.35/24,10.57.45/24,10.57.50/24,10.57.55/24, and so on. But not matter what, the status page always shows the same interfaces.It's as if it's cached in a settings file, and no matter the changes I make, no new interfaces show up, and no interfaces get removed.
If I set the default bind to none, and then add some of my newer interfaces from the last time I installed pimd, the service won't start, and I get these errors in the logs:
Oct 13 22:21:35 pimd 5196 Cannot forward: no enabled vifs Oct 13 22:21:35 pimd 5196 /var/etc/pimd/pimd.conf:7 - Invalid phyint address 'igb2.25' Oct 13 22:21:35 pimd 5196 /var/etc/pimd/pimd.conf:6 - Invalid phyint address 'igb2.35' Oct 13 22:21:35 pimd 5196 pimd version 2.3.2 starting ...What am I doing wrong? Is it possible, via CLI, I can uninstall the package and it's settings so I can re-install a fresh copy with fresh settings? When I re-install via the GUI, I get the same issues above.
I'm on pfSense 22.05, and pimd 0.0.3_5.
In case this helps anyone that runs into something similar, I was able to resolve this by enabling pimd (not sure if this was required), and then I went into every interface and saved (making no changes), and afterwards I applied my changes.
Doing that forced the pimd interfaces to be updated with all of my interfaces, and allowed the service to start correctly.
I can now connect to my Sonos speaker on another VLAN! :)
-
I have added an IPv6 rule for mdnd on 53, and having much better experience with discovery now, especially from spotify apps, i have been resisting building out ipv6 rules...will probably eventually cave, are people running ipv6 out there?
-
@offstageroller said in Sonos speakers and applications on different subnets (VLAN's):
@offstageroller said in Sonos speakers and applications on different subnets (VLAN's):
I installed this package a while back, and recently re-installed it since I added a Sonos speaker to my network.
However, no mater what interfaces I select, my status page always shows this:
Virtual Interface Table ====================================================== Vif Local Address Subnet Thresh Flags Neighbors --- --------------- ------------------ ------ --------- ----------------- 0 10.57.0.1 10.57/24 1 DR NO-NBR 1 172.113.115.113 172.113.96/19 1 DISABLED 2 10.57.10.1 10.57.10/24 1 DISABLED 3 10.57.20.1 10.57.20/24 1 DR NO-NBR 4 10.57.30.1 10.57.30/24 1 DR NO-NBR 5 10.57.40.1 10.57.40/24 1 DR NO-NBR 6 10.57.0.1 register_vif0 1If I choose bind to all, and don't add any interfaces, I only see the interfaces above. I have about 3X that number of interfaces now. It should be showing
10.57.25/24,10.57.35/24,10.57.45/24,10.57.50/24,10.57.55/24, and so on. But not matter what, the status page always shows the same interfaces.It's as if it's cached in a settings file, and no matter the changes I make, no new interfaces show up, and no interfaces get removed.
If I set the default bind to none, and then add some of my newer interfaces from the last time I installed pimd, the service won't start, and I get these errors in the logs:
Oct 13 22:21:35 pimd 5196 Cannot forward: no enabled vifs Oct 13 22:21:35 pimd 5196 /var/etc/pimd/pimd.conf:7 - Invalid phyint address 'igb2.25' Oct 13 22:21:35 pimd 5196 /var/etc/pimd/pimd.conf:6 - Invalid phyint address 'igb2.35' Oct 13 22:21:35 pimd 5196 pimd version 2.3.2 starting ...What am I doing wrong? Is it possible, via CLI, I can uninstall the package and it's settings so I can re-install a fresh copy with fresh settings? When I re-install via the GUI, I get the same issues above.
I'm on pfSense 22.05, and pimd 0.0.3_5.
In case this helps anyone that runs into something similar, I was able to resolve this by enabling pimd (not sure if this was required), and then I went into every interface and saved (making no changes), and afterwards I applied my changes.
Doing that forced the pimd interfaces to be updated with all of my interfaces, and allowed the service to start correctly.
I can now connect to my Sonos speaker on another VLAN! :)
Well, I’m stuck again. I have most of my interfaces showing up in pimd, but not all of them. Following the instructions above doesn’t add these last few interfaces (vlans). Rebooting doesn’t help either.
Any ideas on what I can try?
-
@offstageroller out of curiosity I tried adding more vlans to my setup. I had 2 interfaces that were already setup just not enabled in pimd. My setup is set to default bind to none. Had to change them to always bind to enable them. To take this one step farther added 3 more vlans to system. Was unable to get them to work until I changed the cidr from 32 to 24. You may want to check that.
My system now has 9 vlans working with pimdI haven't tested avahi on more than 4 vlans in awhile. Remember that it didn't work when previously testing. Hope this helps
-
@mikedob said in Sonos speakers and applications on different subnets (VLAN's):
@offstageroller out of curiosity I tried adding more vlans to my setup. I had 2 interfaces that were already setup just not enabled in pimd. My setup is set to default bind to none. Had to change them to always bind to enable them. To take this one step farther added 3 more vlans to system. Was unable to get them to work until I changed the cidr from 32 to 24. You may want to check that.
My system now has 9 vlans working with pimdI haven't tested avahi on more than 4 vlans in awhile. Remember that it didn't work when previously testing. Hope this helps
@mikedob I appreciate the reply and trying to help me out.
I tried changing from default bind from none to always, but that didn't get the interfaces showing up for me. All of my CIDR's are
/24already.Avahi is working perfectly though. I see all of the interfaces in there and they all work correctly on each VLAN.
In my setup, I'm missing the following VLANs:
- 10.57.65/24
- 10.57.75/24
Virtual Interface Table ====================================================== Vif Local Address Subnet Thresh Flags Neighbors --- --------------- ------------------ ------ --------- ----------------- 0 10.57.0.1 10.57/24 1 DR NO-NBR 1 172.113.108.191 172.113.96/19 1 DISABLED 2 10.57.10.1 10.57.10/24 1 DISABLED 3 10.57.20.1 10.57.20/24 1 DR NO-NBR 4 10.57.30.1 10.57.30/24 1 DR NO-NBR 5 10.57.40.1 10.57.40/24 1 DR NO-NBR 6 10.57.50.1 10.57.50/24 1 DR NO-NBR 7 10.57.60.1 10.57.60/24 1 DR NO-NBR 8 10.57.70.1 10.57.70/24 1 DISABLED 9 10.57.80.1 10.57.80/24 1 DISABLED 10 10.57.90.1 10.57.90/24 1 DR NO-NBR 11 10.57.95.1 10.57.95/24 1 DR NO-NBR 12 10.57.35.1 10.57.35/24 1 DISABLED 13 10.57.45.1 10.57.45/24 1 DISABLED 14 10.57.0.1 register_vif0 1Any thoughts on what else I can do to get those to show up?
-
@offstageroller at a loss. Maybe one of the admins from netgate could assist. You may want to put a new post about not all interfaces showing up in pimd. That is where I see your issue and it's not fully related to sonos working across multiple vlans
-
Hi there
I am trying to get this working, without luck so far. I have set the firewall rules like described and also the pimd setup.
As soon as I enable pimd, my devices drop from the wifi.
Any ideas?
-
@qinn
This is exactly what I needed to fix my issues, thank you so much! Was struggling to get multicast working across VLANS and this helped me immensly. -
@dracoclaw Nice, it helped and thanks for reporting back!
-
After months of starts-and-stops and a ridiculous amount of hours trying every single solution posted in these mega-threads, I finally got my Sonos working across VLANs. Here's my step-by-step.
Requirements:
- Enable Avahi, default configuration
- Enable PIMD, Bind to None, Select the interfaces to enable, add all Sonos IPs to RP Addresses
Firewall rules:
-
On your Sonos VLAN, create a pass rule allowing Sonos players to connect to the secure VLAN, on specific ports. Suggest to create an alias for all the Sonos IPs, if you have 2+. For the ports, I used every port mentioned above, but this is overkill and potentially insecure, so proceed with caution (FWIW I used 319, 320, 3400, 3401, 3500, 4070, 7000, 30000-65535. Create an alias for the ports you want to use)
-
If needed, ensure your secure VLAN can initiate connections to Sonos / IoT VLAN. In my case this was already by default, but you may need to add a specific rule.
Now, here's the key thing: if your pfSense configuration defaults to block all traffic not explicitly allowed (which is a common approach), you need to add rules allowing IGMP and multicast traffic!
That seems obvious in hindsight, but I was thinking that PIMD / Avahi would automagically convert all multicast / IGMP traffic to unicast, but that's now how they work.
Here's one easy way of doing it:
-
In Interfaces / Assignments / Interface Groups create a group called "ALL_VLANs", and add all your VLANs
-
In Firewall / Rules / ALL_VLANs, add three rules:
2.1. Allow IGMP from * to *
2.2. Allow IP from * to 224.0.0.0/8
2.3. Allow IP from * to 239.0.0.0/8
Once I added the rules, it started working like a charm, with the added bonus that it worked not only with the Sonos app, but also Spotify! And the Spotify app now finds Sonos and also any Google Home speakers on the same VLAN, and for both Android and iOS users.
Would love to hear if anyone knows exactly which ports have to be open from Sonos to controller, so I can fine tune the configuration.
Thanks @qinn and many others who contributed above; much appreciated.
-
Eureka! Thanks, guiambros, for all the work.
Here's an interesting observation. I have three networks of interest, my main net (Data), a Sonos net (Sonos) and a guest net (Guest). All three have a final rule permitting anything not blocked previously. The Sonos and Guest networks have a semi-final rule blocking anything (not permitted previously) directed to a private network (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16).
I had previously created rules on the guest network permitting IGMP, 224.0.0.0/8 and 239.0.0.0/8 (in all cases with "Allow IP options" under Advance Options). I hadn't added those rules to the Sonos or Data networks. My experience was mediocre. Sometimes it wouldn't work, and if I closed the Sonos app and reopened it, it would take many (more than ten) seconds to find the Sonos system, if it did at all.
With your post, I added those extra rules to the Sonos network but not to the Data network. Now, the Sonos app comes up within a couple of seconds on both the Data and Guest networks. (As a test, I disabled those rules on the Guest network and the Sonos app didn't come up at all.)
So my takeaway is that these rules need to be on all the networks of interest, as you suggested. (However, I don't have them on my Data network and the Sonos app works fine from there. I don't understand the difference between my Guest and Data networks.) -
@guiambros said in Sonos speakers and applications on different subnets (VLAN's):
Would love to hear if anyone knows exactly which ports have to be open from Sonos to controller, so I can fine tune the configuration.
Ports required are as described by Sonos here:
https://support.sonos.com/en-us/article/configure-your-firewall-to-work-with-sonosWorks well for me with controller and Sonos devices on separate subnets.
-
@nelox - for me it doesn't work at all, but maybe because I have a locked down vlan set up with default drop.
Specifically, my controllers on vlan A are whitelisted and can see and connect to anything on vlan B (where the Sonos players are). So technically there's no need to open ports from controller to Sonos Players. My issue is the other way around.
When you open the app and it goes through the multicast discovery, the Sonos player try to respond back via UDP to the controller. But unless I explicitly allow this UDP traffic from Player to Controller, it won't work, and I can see it in my logs. And given UDP is stateless, pfSense can't use the connection state, so unless I have an explicit rule, it won't work.
I tested this extensively, and in my case Sonos players usually use UDP source port in the 35000-42000 range, so that's what I used to allow traffic in pfSense.
Caveat that I'm not using UPnP, so maybe that explains the difference.
-
C CharlesT referenced this topic on
