PfSense & Sonos - Multicast Packets Being Blocked
-
I'm running pfSense with a Cisco SG300 switch in L2 mode. Everything works fine (multicast, dhcp, etc.). There is one use case where pfSense seems to be blocking multicast packets.
When setting up sonos in "standard" mode (that is, it uses your wifi network instead of its proprietary wireless mesh network), certain sonos components, the sub in this case, connect through another sonos device. It works like this:
sub > playbar > dhcp request to pfsense (sub is using the playbar mac, and the playbar is also using its own mac trying to get an IP).
The sub ends up getting a link-local ip from itself because pfsense is not giving it an IP. When I try using an apple aiport express that hands out DHCP, it works fine.
When I check the firewall logs I see multicast packets being blocked. When I allow them in the firewall rules I still can't get pfsense to give the sonos sub an IP.
Does anyone know how to get this to work? Have been literally trying for months, off and on, to no avail.
Please also see the attached email from sonos support.
Thanks in advance to anyone that can help!
– email from support
Hi,
If you were to setup the Airport Express on its own running DHCP and providing the wireless it will work. The Sonos system uses multicast address of 239.255.255.250 and we suggest the following ports be open.
TCP/IP:
80 (Internet Radio, updates and registration)
443 (Rhapsody, Napster, and SiriusXM)
445 (CIFS)
3400 (incoming UPnP events - Sonos Controller App for Mac or PC)
3401 (Sonos Controller App for iOS)
3445 (OS X File Sharing)
3500 (Sonos Controller App for Android)
4070 (Spotify incoming events)
4444 (Sonos update process)UDP:
136-139 (NetBIOS)
1900 (UPnP events and device detection)
1901 (UPnP responses)
2869, 10243, 10280-10284 (Windows Media Player NSS)
6969 (Initial configuration)Cheers,
Curtis
Sonos Customer Care
-
multicast has ZERO to do with dhcp.. Zero!!
If your not getting a IP for dhcp.. I would check the dhcp log, if need be sniff. Are you seeing a discover packet? Again dhcp does not work on multicast.. If your device is not getting a IP address via dhcp, it has nothing to do with blocks you might be seeing in firewall log for multicast packets.
-
It's like 3 people in the entire world understand networking.
-
hehehe - I know right… So its not just me that most of these people shouldn't be within 100 feet of a firewall let alone login access..
-
Then why does everything work just fine when using an Apple Airport router? pfSense must be blocking something.
-
Don't have enough information to tell you.. But what I can tell you for 100% for sure is dhcp is not multicast. It uses ports 67 and 68, there is broadcast traffic and even unicast but not multicast..
If I had to guess it has to do with mac being used
"sub is using the playbar mac, and the playbar is also using its own mac trying to get an IP"You have this thread as well
https://forum.pfsense.org/index.php?topic=120986.0Where you actually bring up useful info.. And given some good advice.. So your using a cisco AP?? Here is very useful info - does the discover packet even get to pfsense?? Or does it not get past your AP??? This is simple enough to do by sniff on the interface that is on the network your AP is connected too.. Sniff for 67, do you see discover packets from your sub? Post that pcap file so we can look, etc.
-
Multicast DNS maybe, try installing the AVAHI package, see if that fixes the issue.
The Apple device would run bonjour AKA mDNS.
239.255.255.250 is SSDP :-
-
Ok… did a little more digging. AVAHI doesn't seem to work.
As for the DHCP logs, they show the following:
Time Process PID Message
Nov 24 15:05:35 dhcpd DHCPOFFER on 192.168.0.247 to b8:e9:37:67:2e:8e (SonosZP) via 192.168.0.3
Nov 24 15:05:35 dhcpd DHCPDISCOVER from b8:e9:37:67:2e:8e (SonosZP) via 192.168.0.3
Nov 24 15:05:34 dhcpd DHCPOFFER on 192.168.0.247 to b8:e9:37:67:2e:8e (SonosZP) via 192.168.0.3
Nov 24 15:05:33 dhcpd DHCPDISCOVER from b8:e9:37:67:2e:8e (SonosZP) via 192.168.0.3
Nov 24 15:04:29 dhcpd DHCPOFFER on 192.168.0.247 to b8:e9:37:67:2e:8e (SonosZP) via 192.168.0.3
Nov 24 15:04:29 dhcpd DHCPDISCOVER from b8:e9:37:67:2e:8e (SonosZP) via 192.168.0.3
Nov 24 15:04:26 dhcpd 3 bad udp checksums in 5 packets
Nov 24 15:04:26 dhcpd DHCPOFFER on 192.168.0.247 to b8:e9:37:67:2e:8e (SonosZP) via 192.168.0.3
Nov 24 15:04:26 dhcpd DHCPDISCOVER from b8:e9:37:67:2e:8e (SonosZP) via 192.168.0.3
Nov 24 15:04:25 dhcpd DHCPOFFER on 192.168.0.247 to b8:e9:37:67:2e:8e (SonosZP) via 192.168.0.3
Nov 24 15:04:24 dhcpd DHCPDISCOVER from b8:e9:37:67:2e:8e (SonosZP) via 192.168.0.3Looks like the sonos item in question (the sonos sub) is getting an offer for DHCP through my Cisco wireless controller (192.168.0.3). For whatever reason it isn't taking it.
Does "3 bad udp checksums in 5 packets" mean anything to anyone?
-
… and some more info from Cisco TAC support (again, not sure if pfSense or my Cisco WLC is the issue).
_As per our discussion today the speakers were connecting to the wireless network and were in connected state but were not able to communicate through the Sonos Sub,
We also found that the Multicast ID of the speakers were getting generated but the Sonos sub information was missing ( multicast entry ) under MGID._
-
What hardware & version of pfSense are you running ?
-
What hardware & version of pfSense are you running ?
Super Micro C2758
2.3.2-RELEASE-p1 (amd64)
-
It'd help to produce a network diagram. (And I hope you did NOT wire some of the infamous Sonos stuff.)
-
It'd help to produce a network diagram. (And I hope you did NOT wire some of the infamous Sonos stuff.)
Sonos Sub - (proprietary wireless link) - Sonos Playbar (playbar acts as proxy for Sub when getting ip) – Cisco 3702 AP -- Cisco 5508 WLC (local mode) -- Cisco SG300 Switch (layer2 mode) -- pfSense.
-
Try enabling Passive Client on the Cisco WLC for the Wireless Network you are using. I think with this disabled (default) the WLC intercepts ARP requests and responses and might be causing this problem. I've had to enable it to allow VMware Fusion VMs to work correctly sometimes. You may have a similar issue here.
Some more details: https://rscciew.wordpress.com/2014/10/31/passive-client-feature/
Greg
-
Try enabling Passive Client on the Cisco WLC for the Wireless Network you are using. I think with this disabled (default) the WLC intercepts ARP requests and responses and might be causing this problem. I've had to enable it to allow VMware Fusion VMs to work correctly sometimes. You may have a similar issue here.
Some more details: https://rscciew.wordpress.com/2014/10/31/passive-client-feature/
Greg
Good suggestions. Tried that to no avail some time ago.
I'm not sure it's a WLC issue. Even if I put the WLC and access points in flex connect mode (where everything gets switched outside of the WLC), it still doesn't work - hence I'm thinking it's something to do with pfSense.
-
I'd love to know how this works out. We're thinking of using a mesh sonos speaker system to replace our ancient sound system.
-
I'd love to know how this works out. We're thinking of using a mesh sonos speaker system to replace our ancient sound system.
Just wanted to mention that if you use Sonos' mesh network (aka "SonosNet", or "Boost mode" in Sonos' documentation), it's a fully bridged network, using spanning tree to determine the best path for a device to take across the mesh network to the [nearest, if you have multiple] wired connection. This is different from the OP's setup, where a regular WiFi network is being used.
I've always run my Sonos system in "SonosNet" mode, and have never had any problems. My home network consists of a couple of Linksys/Belkin gigabit smart switches (I don't have STP enabled on them, but do have them set to flood BPDUs so Sonos' STP traffic is able to be passed through) as well as my pfSense box. I have two of my seven Sonos devices wired to my network.
-
I'd love to know how this works out. We're thinking of using a mesh sonos speaker system to replace our ancient sound system.
Just wanted to mention that if you use Sonos' mesh network (aka "SonosNet", or "Boost mode" in Sonos' documentation), it's a fully bridged network, using spanning tree to determine the best path for a device to take across the mesh network to the [nearest, if you have multiple] wired connection. This is different from the OP's setup, where a regular WiFi network is being used.
I've always run my Sonos system in "SonosNet" mode, and have never had any problems. My home network consists of a couple of Linksys/Belkin gigabit smart switches (I don't have STP enabled on them, but do have them set to flood BPDUs so Sonos' STP traffic is able to be passed through) as well as my pfSense box. I have two of my seven Sonos devices wired to my network.
Sounds awesome. If they could only act as access points too!
-
I'd love to know how this works out. We're thinking of using a mesh sonos speaker system to replace our ancient sound system.
Just wanted to mention that if you use Sonos' mesh network (aka "SonosNet", or "Boost mode" in Sonos' documentation), it's a fully bridged network, using spanning tree to determine the best path for a device to take across the mesh network to the [nearest, if you have multiple] wired connection. This is different from the OP's setup, where a regular WiFi network is being used.
I've always run my Sonos system in "SonosNet" mode, and have never had any problems. My home network consists of a couple of Linksys/Belkin gigabit smart switches (I don't have STP enabled on them, but do have them set to flood BPDUs so Sonos' STP traffic is able to be passed through) as well as my pfSense box. I have two of my seven Sonos devices wired to my network.
Too add to this … my sonos system works fine when using SonosNet - except for one speaker that is quiet far from the mesh, which cuts out (hence trying to get it onto my Cisco network).
... but I agree, if you have good enough coverage with Sonos speakers the mesh network works pretty well.
-
I'd love to know how this works out. We're thinking of using a mesh sonos speaker system to replace our ancient sound system.
Just wanted to mention that if you use Sonos' mesh network (aka "SonosNet", or "Boost mode" in Sonos' documentation), it's a fully bridged network, using spanning tree to determine the best path for a device to take across the mesh network to the [nearest, if you have multiple] wired connection. This is different from the OP's setup, where a regular WiFi network is being used.
I've always run my Sonos system in "SonosNet" mode, and have never had any problems. My home network consists of a couple of Linksys/Belkin gigabit smart switches (I don't have STP enabled on them, but do have them set to flood BPDUs so Sonos' STP traffic is able to be passed through) as well as my pfSense box. I have two of my seven Sonos devices wired to my network.
Sounds awesome. If they could only act as access points too!
You actually can. The playbar for example has two ethernet ports that, when in SonosNet mode, can be used to connect to your main network.
-
I'd suggest to be extremely careful with SonosNet and wiring things, so that you do not crash your entire network by producing loops. Certainly would NOT recommend to disable (R)STP on the switches.
-
That sounds pretty awesome, I will definitely look in to it more.
I probably should start using STP as well.
-
Sounds awesome. If they could only act as access points too!
If you use Android-based devices, you can install the Sonos app on them and there's an advanced setting to allow Android devices to connect to the SonosNet mesh network as well. They'll only be devices on the network though, not full mesh nodes like the Sonos devices are. Don't expect super performance out of it though… streaming video while connected probably won't go too well.
-
Sounds awesome. If they could only act as access points too!
If you use Android-based devices, you can install the Sonos app on them and there's an advanced setting to allow Android devices to connect to the SonosNet mesh network as well. They'll only be devices on the network though, not full mesh nodes like the Sonos devices are. Don't expect super performance out of it though… streaming video while connected probably won't go too well.
Right, it would be for business stuff.
