Sonos speakers and applications on different subnets (VLAN's)
-
I have been looking for a solution to have Sonos speakers and applications work across VLAN's using pfSense and, until now, haven't found a working solution.
I hope this thread helps you ~please keep in mind, this is a bit out of my wheelhouse~, if it does, + my reputation maybe drop a line here with feedback. Please bear in mind, I tried to keep it simple (KISS principle), so that even the "not so tech savy" might stay on board.ThreeOnly one"very"important note :
1. You will have to be able to use the CLI (command line interface) for instance use Putty. (~Edit~) As time passes it seems that I forgot about the "edit" possibilities in the GUI of pfSense, as @Vacquah pointed out (see below) and I quote; "I didn't have to use Putty at all. I logged into the pfsense GUI and executed all the commands via diagnostics --> command prompt. This includes copying the pimd conf file over to /var/etc/ and starting it after editing"and het did edit the config file ; "To edit the conf file at /var/etc/pimd.conf, I used diagnostics ---> file edit. You can browse to it. very easy."
2. (~Edit~) Great, that PIMD is now available for users on current 2.5.0 and 2.4.5 snapshots, so using the GUI it will be much easier to setup PIMD.
The use of the multicast routing daemon "pimd" is a package that's not in the pfSense manager, so this could be a risk and IMHO never use something in a firewall environment that's not vigorously tested by the developers of pfSense and certainly not in a corporate environment, so use this "at your own risk” ~~
3. It looks like Sonos will save/store the IP's of their devices, so it's best to quit thedaemon, once you can access the speakers (You'll have to test it).Before I explain the solution that I have found to work, first a bit of background.
Background
Sonos speakers and applications use multicast to find each other and unicast to execute commands. They broadcast there existence using 255.255.255.255 (unicast) and 239.255.255.250 (multicast). Normally these broadcasts/discovery stay on the same subnet and therefore, when you want to control the speakers using an application from a different subnet, they won't find each other. If they did found each other the communication goes via unicast.So what you want is to traverse Multicast 239.255.255.250 (SSPD) across subnets. Only the native igmpproxy (0.2.1) that comes with pfSense won't work (well, this accounts for version 0.2.1, maybe future versions will).
With igmpproxy I got the following error message:"The IGMP message was local multicast. Ignoring."
I assume (as running igmpproxy in debug mode didn't reveal what this was) that it doesn't let the discovery (239.255.255.250 SSDP) traverse to the other subnet and hence application and speakers can't locate each other.
So after reading this thread https://forum.netgate.com/topic/138242/dlna-across-vlan-subnets-with-igmp-proxy-not-working ,I thought about trying to use "pimd".
PIMD Protocol Independent Multicast
PIM allows existing networks to route IP multicast, regardless of what unicast routing protocol is in use. Pimd is a lightweight standalone PIM-SM/SSM v2 multicast routing daemon.See:
https://freebsd.pkgs.org/11/freebsd-ports-quarterly-amd64/pimd-2.3.2.txz.html
https://github.com/troglobit/pimd
http://troglobit.com/projects/pimd/Installation
Install it from the Package Manager in the GUI as it is now available for users on current 2.5.0 and 2.4.5 snapshots and using the GUI it will be much easier to configurate PIMD.-.-.-.-.-.-.--.All below is not needed anymore, install it using the Package Manager and setup using the GUI--.-.-.-.-.-.-.
pkg add http://pkg.freebsd.org/FreeBSD:11:amd64/quarterly/All/pimd-2.3.2.txz
~~and thanks to @vacquah (read his post from 30 Juli) there is also a ARM version
pkg add http://pkg.freebsd.org/FreeBSD:11:armv6/quarterly/All/pimd-2.3.2.txz
if for some reason you want to remove it, use:
pkg remove pimd
After installation it is best to logout of pfSense and login again, so you can use pimd from anywhere (path)
I copied the default pimd.conf file to /var/etc/ (Keep in mind that with an update of pfSense it will be gone!!!)
cp /usr/local/etc/pimd.conf /var/etc/pimd.conf
and then edit it.
vi /var/etc/pimd.conf
If you start pimd, by default, it will work on all interfaces and I don't think you want that, so first edit the config file before starting it.
Pimd uses a config file called pimd.conf and the only thing I changed is that I added the interfaces I don't want to use. By default PIM is activated on all interfaces. Use
phyint disable
for every device than you don't use.(If you don't know how, take a look at the igmpproxy.conf file (well if you, as I had configured it using the GUI from pfSense and tried using it ;) ) and copy them from the igmpproxy.conf, just remember to remove the "d" as pimd uses disable instead of disabled.)
Example
-.-.-.-.-.-.-.-.-.-.-.below part of pimd.conf-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.# By default PIM is activated on all interfaces. Use `phyint disable` # on interfaces where PIM should not run. You can also use the `-N, # --disable-vifs` command line option along with `enable` to get the # inverse behavior. # phyint pppoe0 disable phyint igb1.1001 disable phyint igb1.1002 disable phyint igb1.1003 disable phyint igb1.1004 disable phyint igb0 disable phyint igb1.1006 disable phyint igb1.1007 disable phyint igb1.1008 disable phyint igb1.1009 disable # The routing protocol admin distance (or metric preference per the RFC) # is used in PIM Assert elections to elect the forwarder of multicast. # Currently pimd cannot obtain distance and metric from the underlying # routing protocols, so a default distance may need to be configured per # interface. If left out, the default-route-distance is used for the # phyint. In PIM assert elections the router advertising the lowest # preference (distance) will be selected as forwarder (upstream router) # for that LAN. An admin distance of 101 should be sufficiently high so # that asserts from Cisco or GateD routers are prefered over poor-little # pimd. #
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
So in my case (see above), pimd is not disabled on igb1.1005 and igb1.1010 and these are the VLAN's I want to use. 1005 holds the Sonos speakers and 1010 the Sonos applications.
Start pimd with -c is for the configuration file.
pimd -c /var/etc/pimd.conf
You can see it running in the pfSense GUI goto status->system logs or type
top
If all goes well, it can take up to a 20-30 seconds before your can access the speakers.
Note: I noticed that once the Sonos application(s) have found the speakers the IP's are somehow "saved" or "stored" (btw You'll have to test this) and you can stop pimd, which seems best, because as I mentioned earlier it is better/safer to not use anything that has not been vigorously tested by the pfSense developers, as pimd is not an official package of pfSense (as far as I know)!
So quit pimd with
pimd -q
-.-.-.-.-.-.--.All above is not needed anymore, install it using the Package Manager and setup using the GUI--.-.-.-.-.-.-.
pfSense firewall rules configuration
Below are the the rules that worked during the test. Currently, I am working on them to narrow them down, why else use a VLAN for Sonos and if you want I can post them ASAP.Ports can be found here https://support.sonos.com/s/article/688?language=en_US&utm_medium=firewall&utm_source=cr-care&utm_content=english-cr-care-firewall
Note 1: you don't have to enable the Allow IP options in the Advanced Options of the rules, as is sometimes mentioned using igmp proxy.
Note 2: below is reported that on Android devices "Allow IP options" in the Advanced Options of the firewall rules is needed to enable to make it work, so if you don't have success, please try to enable it.I hope this helps, success.
Cheers Qinn
-
Hey Qinn,
I am trying to accomplish the same thing as detailed here
https://forums.lawrencesystems.com/t/inter-vlan-routing-multicast-help-pfsense-igmp-proxy-sonos/540/7
Did you get this working successfully ? -
@thewitten Yes, it does work. IGMPproxy and Avahi did not, as they don't seem to traverse the 239.255.255.250 (SSDP) across the VLAN's. So follow my "guide" above to get it working, from the tumbs up it seems that others have tried it successfully.
Now (time is a challenge at current) I am fine-tuning the firewall rules for the ports needed, as the current rules suggested in the guide above, are not much of security.
Cheers Qinn
-
@qinn said in Sonos speakers and applications on different subnets (VLAN's):
I am fine-tuning the firewall rules for the ports needed, as the current rules suggested in the guide above, are not much of security.
Hi Qinn
Thanks for the detailed writeup and pointing me to this. So pimd replaces the need to have Avahi and igmpproxy? How stable is pimd daemon? Waiting to see what final rules you come up with for your vlans then I'd take a stab as well.
-
@vacquah said in Sonos speakers and applications on different subnets (VLAN's):
@qinn said in Sonos speakers and applications on different subnets (VLAN's):
I am fine-tuning the firewall rules for the ports needed, as the current rules suggested in the guide above, are not much of security.
Hi Qinn
Thanks for the detailed writeup and pointing me to this. So pimd replaces the need to have Avahi and igmpproxy? How stable is pimd daemon? Waiting to see what final rules you come up with for your vlans then I'd take a stab as well.
Well, I have not replaced them. In my setup IGMPproxy is not running, but Avahi is. Avahi is used here to let iOS devices, that are in several VLAN's, to access the one VLAN that contains all printers. So Avahi is used to traverse Apples "Bonjour" service over these VLAN's to make printing possible to iPad's and iPhones that are on different VLAN's than were the bonjour printers are.
The beauty with the PIM deamon/iOS is that once the Sonos applications (iPad and iPhones) have located the Sonos speakers they "remember" there IP's, so somehow.
IP's addresses seem to be saved or stored by the Sonos applications (I can't check it, as the Sonos applications are closed source). But it's been 2 weeks since I have been running the PIM daemon (once and quit it) and I can still access the Sonos speakers from a different VLAN.So practically I have started the PIM daemon only once, then waited for the applications (that are in a different VLAN then the Sonos speakers) to get access to the speakers (all Sonos speakers are in one VLAN) and then quit the PIM daemon (as described in my guide above).
Only running PIMD once and then quiting it minimizes the theoretical risk of running an package that has not been tested by the pfSense developers.
Cheers Qinn
-
On the subject of security, my preliminary investigation suggests the following:
To let the Sonos speakers access the Sonos applications (iPad and iPhones), they need to be able to access the VLAN that holds the Sonos applications on UDP port 1901 and TCP ports 3400 and 3401.
To let the Sonos applications access the Sonos speakers they need to be able to access the VLAN that holds the Sonos speakers on TCP/UDP ports 1400 and 1443
It's is of course best practice to create these rules only for the ip's of Sonos speakers and the Sonos devices that hold the Sonos applications.
Sorry, time is a challenge at the moment, but in time I will place a detailed rule set.
Cheers Qinn
-
Btw to anyone, if you are happy with my guide and it helped you, maybe also vote on the thread below and add a comment, maybe the pfSense developers might consider to add the PIMD package to pfSense....
https://forum.netgate.com/topic/139352/pimd-a-lightweight-standalone-pim-sm-ssm-v2-multicast-routing-daemon
-
@qinn said in Sonos speakers and applications on different subnets (VLAN's):
Btw to anyone, if you are happy with my guide and it helped you, maybe also vote on the thread below and add a comment, maybe the pfSense developers might consider to add the PIMD package to pfSense....
https://forum.netgate.com/topic/139352/pimd-a-lightweight-standalone-pim-sm-ssm-v2-multicast-routing-daemon@Qinn See comment by @jimp in this thread:
https://forum.netgate.com/topic/99211/multicast-with-pfsense
-
@vacquah said in Sonos speakers and applications on different subnets (VLAN's):
@qinn said in Sonos speakers and applications on different subnets (VLAN's):
Btw to anyone, if you are happy with my guide and it helped you, maybe also vote on the thread below and add a comment, maybe the pfSense developers might consider to add the PIMD package to pfSense....
https://forum.netgate.com/topic/139352/pimd-a-lightweight-standalone-pim-sm-ssm-v2-multicast-routing-daemon@Qinn See comment by @jimp in this thread:
https://forum.netgate.com/topic/99211/multicast-with-pfsense
Thanks for pointing that one out to me, I was aware, but I thought it was useless to reply on a thread that old and at that time there were (as memory serves) more issues with IGMP proxy https://redmine.pfsense.org/issues/6099
btw did you got it working on your Sonos setup?Cheers Qinn
-
Hi Qinn I'll try to using your guide with pim to configure a similar problem in my network with google devices and Logitech Media server, I hope that this works.
Thanks.
Bull -
@bull said in Sonos speakers and applications on different subnets (VLAN's):
Hi Qinn I'll try to using your guide with pim to configure a similar problem in my network with google devices and Logitech Media server, I hope that this works.
Thanks.
Bulldid it work?
-
@qinn No, at the moment I don't have any positive results, it's quite frustrating, I don't know if I have a problem with netgear GS110TP switches or with pfsense I have it configured in a vmware environment with vlan(4096) and this may be blocking multicast to the router in vmware. I don't know how to continue I'm absolutely blocked, I've been trying and testing for a couple of weeks and starting over.
I need a rest, think so.
-
@bull said in Sonos speakers and applications on different subnets (VLAN's):
@qinn No, at the moment I don't have any positive results, it's quite frustrating, I don't know if I have a problem with netgear GS110TP switches or with pfsense I have it configured in a vmware environment with vlan(4096) and this may be blocking multicast to the router in vmware. I don't know how to continue I'm absolutely blocked, I've been trying and testing for a couple of weeks and starting over.
I need a rest, think so.
Did you turn the port to "promiscuous mode" in VMware for pfSense? That bit me in the butt once, a lesson I will not forget.
-
@tim-mcmanus In my setup(s) I do not use VMware at the moment, so I cannot advise. In theory the switch should not play a part, when it is in the private (RFC1918) subnet(s) and pfSense is controlling these subnets. So IGMP snooping should not be needed, the IGMP proxy or PIMD should do that part.
Have you checked what multicast is send (wireshark)? That's how I analyzed that 239.255.255.0 was used by Sonos and that native IGMP proxy used by pfSense did not traversed it over the subnets. -
@tim-mcmanus yes, promiscuous mode is enable on vmware NIC, anyway I haven't problems with unicast, I can ping and have conectivity across vlans inside and outside of the vmware. So I don't understand were the multicast cannot be routed
-
@qinn thank you, I'll try to disable IGMP on these switches later on, I let you know if it's work.
-
@bull said in Sonos speakers and applications on different subnets (VLAN's):
Hi Qinn I'll try to using your guide with pim to configure a similar problem in my network with google devices and Logitech Media server, I hope that this works.
Thanks.
BullBtw could you give a description of your setup?
-
@qinn said in Sonos speakers and applications on different subnets (VLAN's):
Btw could you give a description of your setup?
I have a ISP router on bridge mode conecting directly to a vmware nic (MODEM LAN 192.168.0.1/24) this interface works as PPPOE and route to modem network. (EM1)
the other nic i have created to vnic both in vlan 4095, the first one EM0 is de MGMT Lan (192.168.1.1/24) and the other vnic EM2 is configured as vlan 4095 and I've been created 5 port in the following tagged Vlan (10,20,30,40 and 50) from 192.168.10 to 50.1 subnet.
this nic is connected to a Netgear GPT110PT in port 6 vlan 10,20,30,40,50 as tagged an 1 untagged, I have a LAGG vlan 20 too connected to a NAS. from this switch is connected another one in port 1 vlan 10,20,30,40,50 as tagged an 1 untagged to port 8.
In port 5 from this second switch, I have a Ubiquiti AP with some wifi ssid configured with vlans 30,40,50, this port also configured with vlans as 10,20,30,40,50 as tagged an 1 untagged
both swicthes have IGMP Snooping enabled, configured IGMP vlan configuration for vlan 1,30,50 (testing at the moment) with querier enable and queriers enable and configured with vlan 1,30 and 50 pointing to each router ip subnet address 1,1 for vlan 1 30.1 for vlan 30...
May be this is a little confuse without a diagram but I don't have any software to have a grafical view of my network.
Many thanks
Bull -
@bull said in Sonos speakers and applications on different subnets (VLAN's):
I don't have any software to have a grafical view of my network.
There is plenty of free software or even just websites that would allow you to draw your network.
Here are 2 you can do it in pure ascii
https://textik.com/
http://asciiflow.com/Here is decent one
https://www.gliffy.com/
another
https://creately.com/lp/network-diagram-software-onlineActual download software
https://www.yworks.com/products/yed
http://dia-installer.de/Lets not forget the office type apps that are free, openoffice, LibreOffice that have drawing - even google draw ;)
Or you take out a crayon and and a napkin and then snap a photo of it with your phone!
-
@johnpoz said in Sonos speakers and applications on different subnets (VLAN's):
Or you take out a crayon and and a napkin and then snap a photo of it with your phone!
Thanks for the suggestions, I tried to do the best I know.
W
-
Disable IGMP Snooping on physical Switches didn't change anything.
Is possible that the problem is that I'm using default vlan 1 as default router ip network and this vlan don't work as spected with multicasting?
I think so from vmware point of view the configuration of the vnic on vlan 4095 is correct.
many thanks
Bull -
4095 on a vswitch will pass all tags to the VMs connected to the switch.
To be honest not a fan of dicking with multicast like to feed it into other Layer 2 networks. If the companies want to be so short sighted to think that their users don't run multiple segments and a way for access through a firewall and different segments then either don't use them.. I mean how hard would it be to let the app put in the IP, and clearly lists what ports need to be allowed, etc.
Or if you really want to use them, then just put all the devices on that L2... I do this with printer - its on the one wireless network.. So if you want to print you just need to make sure your on that SSID.. Not really a big deal... For example when want to control my roku devices with my phone or tables I join the roku vlan.
-
@johnpoz I'm agree with you but looking for the future where more and more IOT devices could be connected in a home lan without any "security" control, would be necesary that the developers that works in security bring to those people that want more security in their home a tool that would be it posible. The company or solution that bring that, win the battle.
I know that is not normal that the mayority of the people had segmented the lan network in their home to have a better view/control of their devices, but how many people had an antivirus installed in their system some years ago?
I'm not want to desviate from the thread, unfortunatly this morning the multicast was working with google devices, I don't know how, I leave home and shutdown the laptop and now I cannot see the chromecast, so... I don't know where my problem is.
-
@Qinn ,only to compare with your confg. this is normal situation with "no traffic" states in the upd/multicast ?
LAN pim 192.168.1.1 -> 224.0.0.13 NO_TRAFFIC:SINGLE 148 / 0 7 KiB / 0 B LAN udp 192.168.1.240:3073 -> 255.255.255.255:6524 NO_TRAFFIC:SINGLE 451 / 0 22 KiB / 0 B LAN udp 192.168.1.240:3074 -> 255.255.255.255:35344 NO_TRAFFIC:SINGLE 451 / 0 22 KiB / 0 B LAN udp 192.168.1.100:56669 -> 192.168.1.255:32414 NO_TRAFFIC:SINGLE 315 / 0 15 KiB / 0 B LAN udp 192.168.1.100:55444 -> 192.168.1.255:32412 NO_TRAFFIC:SINGLE 315 / 0 15 KiB / 0 B LAN udp 192.168.1.104:9956 -> 192.168.1.255:9956 NO_TRAFFIC:SINGLE 79 / 0 30 KiB / 0 B ------------------------------------------------------------------- IOT udp 192.168.50.220:9956 -> 224.0.0.113:9956 NO_TRAFFIC:SINGLE 300 / 0 32 KiB / 0 B IOT udp 192.168.50.21:5353 -> 224.0.0.251:5353 NO_TRAFFIC:SINGLE 327 / 0 86 KiB / 0 B IOT udp 192.168.50.22:5353 -> 224.0.0.251:5353 NO_TRAFFIC:SINGLE 293 / 0 79 KiB / 0 B
Thx
Bull -
Thank you Qinn for posting this! PIMD worked for me after hours and hours of work trying to get my HEOS (Denon's version of "Sonos") working across VLANs.
Is there anything that I need to do to ensure that PIMD loads with the correct settings everytime my pfSense restarts or is updated?
-
@nick13 PIM isn't needed (or desired) for HEOS. All that is needed for HEOS is Avahi with reflection enabled. Following discovery, which is mdns based, HEOS is point to point rather than multicast.
-
@dennypage I've had Avahi installed with reflection enabled and have been unable to get it to work until I also turn on PIMD. When I kill PIMD the HEOS app quits recognizing my receivers on the other vlan.
Do you have any thoughts why that might be?
As a side note, I figured out the answer to my question that I posted by adding the PIMD start command to the config.xml file.
-
Check these things:
You have firewall interfaces in both the client subnet (where your iPhone is) and the server subnet (where the HEOS device is).
You have Avahi (2.0.0_2) with the allowed interfaces set to include both the client subnet and the server subnet.
You have "Enable" and "Enable reflection" checked in the Avahi configuration.
You do not have "Disable IPv4" checked in the Avahi configuration.
You do not have anything defined in the "Advanced settings" section of the Avahi configuration.
You have added rules to allow ptp packets from the clients to the HEOS device you are trying to control.
You have restarted or disconnected/reconnected both HEOS clients and servers after changing the any of the above.
-
@nick13 said in Sonos speakers and applications on different subnets (VLAN's):
Thank you Qinn for posting this! PIMD worked for me after hours and hours of work trying to get my HEOS (Denon's version of "Sonos") working across VLANs.
Is there anything that I need to do to ensure that PIMD loads with the correct settings everytime my pfSense restarts or is updated?
Nice that it helped you, the config file that PIMD is using will probably be removed once you update pfSense.
-
2 questions...
I have PFsense running in an esxi environment and I don't have my network adapter in promiscuous mode. I have the pcie ethernet adapter as a directpath i/o dedicated device. Essentially vmware doesnt even see the device anymore and it as if it's native to the pfsense host machine. This should be good from my understanding?
question 2: Has anyone tried this with a network cablecard tuner? I'm trying to get my hdhomerun to work with igmpproxy and pfsense doesnt seem to be sending any of the multicast traffic.
-
First of all, huge thanks to Qinn and others for figuring this out and providing instructions!
Second, I've read and followed all the instructions here and in other threads w/o any success. So, after days of trials and errors I'd like to ask for some help.
My configuration is slightly different - I need to traverse multicast for Sonos between a real no-VLAN subnet and a dedicated VLAN subnet within. I.e. there's a regular LAN where no-VLAN devices live (it's actually a Default VLAN 1 on the switch, but untagged), bound to "igb1" interface. That's where controller resides in the form of an Android app. And there's a dedicated tagged VLAN 10 for Sonos devices, bound to "igb1.10" interface. LAN on igb1 is 192.168.0.0/24 and VLAN10 on igb1.10 is 192.168.10.0/24. pfSense is 192.168.0.1 and 192.168.10.1 on each interface. Both subnets have DHCP server, both are fully open in Firewall - I can ping and send unicast traffic between those 2 subnets fine.
Now, when I configure PIMD on igb1 and igb1.10, it reports that subnet for the second one is 192.168.10, while subnet for the first one is 192.168. Which leads me to believe that PIMD somehow considers VLAN10 to be "shadowed" inside LAN, not a separate subnet and refuses to retransmit multicast between them.
I tried different combinations of "altnet" configuration specified w/o much success. After a while I see some other Android devices joining multicast groups reported by PIMD, but Sonos still doesn't work - an Android controller app on LAN can't find any Sonos device on VLAN10.
I'd like to avoid the need to tag everything on LAN to make it a dedicated VLAN subnet. Essentially that would mean VLAN 1 as a real subnet, start tagging everything, create "igb1.1" interface for it and close LAN "igb1" down. Supposedly, that would work, as reported by others - VLAN1 <-> VLAN10, igb1.1 <-> igb1.10. Unfortunately, that means extra work, lots of gear configuration and some downtime to my network.
So, I would appreciate any suggestions and ideas for how to make it work with the setup I have right now - LAN <-> VLAN10, igb1 <-> igb1.10. Thanks in advance and please let me know what you think!
-
@denix Could you post the messages you receive from PIMD and could you post the config file of PIMD
A VLAN that is not tagged is not a VLAN ;) , but tagging or not should not really matter as tagging happens when it leaves the subnet and traverses the switch.
-
@Qinn sorry if my explanation wasn't very clear. Yes, I was trying to say that LAN carries both VLAN-tagged traffic, as well as untagged.
Originally I had all Sonos speakers in a separate VLAN10 tagged subnet, while other devices including Android controller app in untagged LAN.
Tired of trying to make it work, I ended up placing WiFi devices into own VLAN40 tagged subnet. Now testing PIMD with VLAN10 <-> VLAN40 and still no luck.
VLAN10 = 192.168.10.0/24 (Sonos speakers)
VLAN40 = 192.168.40.0/24 (Android control app)pfSense has IP of x.x.x.1 on each interface. Both subnets are fully open to each other for unidirectional traffic.
Here's my config (tried many different variants of enabling/disabling different options):
phyint igb0 disable phyint igb1 disable phyint igb2 disable phyint igb3 disable phyint igb1.10 enable phyint igb1.20 disable phyint igb1.30 disable phyint igb1.40 enable bsr-candidate priority 5 rp-candidate time 30 priority 20 group-prefix 224.0.0.0 masklen 4 spt-threshold packets 0 interval 100
Starting pimd -d:
debug level 0xffffffff (dvmrp_detail,dvmrp_prunes,dvmrp_routes,dvmrp_neighbors,dvmrp_timers,igmp_proto,igmp_timers,igmp_members,trace,timeout,packets,interfaces,kernel,cache,rsrr,pim_detail,pim_hello,pim_register,pim_join_prune,pim_bootstrap,pim_asserts,pim_cand_rp,pim_routes,pim_timers,pim_rpf) 22:58:33.455 pimd version 2.3.2 starting ... 22:58:33.455 Got 262144 byte send buffer size in 0 iterations 22:58:33.455 Got 262144 byte recv buffer size in 0 iterations 22:58:33.455 Got 262144 byte send buffer size in 0 iterations 22:58:33.455 Got 262144 byte recv buffer size in 0 iterations 22:58:33.455 Getting vifs from kernel 22:58:33.455 Installing igb0 (x.x.x.x on subnet x.x.x/24) as vif #0 - rate 0 22:58:33.455 Installing igb1 (192.168.0.1 on subnet 192.168) as vif #1 - rate 0 22:58:33.455 Installing igb2 (192.168.13.1 on subnet 192.168.13) as vif #2 - rate 0 22:58:33.455 Installing igb3 (192.168.255.1 on subnet 192.168.255) as vif #3 - rate 0 22:58:33.455 Installing igb1.10 (192.168.10.1 on subnet 192.168.10) as vif #4 - rate 0 22:58:33.455 Installing igb1.20 (192.168.20.1 on subnet 192.168.20) as vif #5 - rate 0 22:58:33.455 Installing igb1.30 (192.168.30.1 on subnet 192.168.30) as vif #6 - rate 0 22:58:33.455 Installing igb1.40 (192.168.40.1 on subnet 192.168.40) as vif #7 - rate 0 22:58:33.455 Getting vifs from /var/etc/pimd.conf 22:58:33.455 Local Cand-BSR address 192.168.40.1, priority 5 22:58:33.455 Local Cand-RP address 192.168.40.1, priority 20, interval 30 sec 22:58:33.455 spt-threshold packets 0 interval 100 22:58:33.455 Local static RP: 169.254.0.1, group 232.0.0.0/8 22:58:33.455 IGMP query interval : 12 sec 22:58:33.455 IGMP querier timeout : 41 sec 22:58:33.455 Interface igb0 is DISABLED; vif #0 out of service 22:58:33.455 Interface igb1 is DISABLED; vif #1 out of service 22:58:33.455 Interface igb2 is DISABLED; vif #2 out of service 22:58:33.455 Interface igb3 is DISABLED; vif #3 out of service 22:58:33.455 Interface igb1.10 comes up; vif #4 now in service 22:58:33.456 query_groups(): Sending IGMP v3 query on igb1.10 22:58:33.456 Send IGMP Membership Query from 192.168.10.1 to 224.0.0.1 22:58:33.456 SENT 36 bytes IGMP Membership Query from 192.168.10.1 to 224.0.0.1 22:58:33.456 SENT 46 bytes PIM v2 Hello from 192.168.10.1 to 224.0.0.13 22:58:33.456 Interface igb1.20 is DISABLED; vif #5 out of service 22:58:33.456 Interface igb1.30 is DISABLED; vif #6 out of service 22:58:33.456 Interface igb1.40 comes up; vif #7 now in service 22:58:33.456 query_groups(): Sending IGMP v3 query on igb1.40 22:58:33.456 Send IGMP Membership Query from 192.168.40.1 to 224.0.0.1 22:58:33.456 SENT 36 bytes IGMP Membership Query from 192.168.40.1 to 224.0.0.1 22:58:33.456 SENT 46 bytes PIM v2 Hello from 192.168.40.1 to 224.0.0.13 22:58:33.456 Interface register_vif0 comes up; vif #8 now in service Virtual Interface Table ====================================================== Vif Local Address Subnet Thresh Flags Neighbors --- --------------- ------------------ ------ --------- ----------------- 0 x.x.x.x x.x.x/24 1 DISABLED 1 192.168.0.1 192.168 1 DISABLED 2 192.168.13.1 192.168.13 1 DISABLED 3 192.168.255.1 192.168.255 1 DISABLED 4 192.168.10.1 192.168.10 1 DR NO-NBR 5 192.168.20.1 192.168.20 1 DISABLED 6 192.168.30.1 192.168.30 1 DISABLED 7 192.168.40.1 192.168.40 1 DR NO-NBR 8 192.168.10.1 register_vif0 1
And here's a sample output from running pimd with -d option when there's a traffic:
Candidate Rendezvous-Point Set =============================================== RP address Incoming Group Prefix Priority Holdtime --------------- -------- ------------------ -------- --------------------- 192.168.40.1 8 224/4 20 50 169.254.0.1 0 232/8 1 65535 ------------------------------------------------------------------------------ Current BSR address: 192.168.40.1 22:37:31.848 Cache miss, src 192.168.40.10, dst 239.255.255.250, iif 7 22:37:31.848 create group entry, group 239.255.255.250 22:37:31.848 create source entry, source 192.168.40.10 22:37:31.848 move_kernel_cache: SG 22:37:32.326 Cache miss, src 192.168.10.16, dst 239.255.255.250, iif 4 22:37:32.326 create source entry, source 192.168.10.16 22:37:32.326 move_kernel_cache: SG 22:37:32.340 Cache miss, src 192.168.10.15, dst 239.255.255.250, iif 4 22:37:32.340 create source entry, source 192.168.10.15 22:37:32.340 move_kernel_cache: SG 22:37:32.660 Cache miss, src 192.168.10.14, dst 239.255.255.250, iif 4 22:37:32.660 create source entry, source 192.168.10.14 22:37:32.660 move_kernel_cache: SG 22:37:32.916 Cache miss, src 192.168.10.13, dst 239.255.255.250, iif 4 22:37:32.916 create source entry, source 192.168.10.13 22:37:32.916 move_kernel_cache: SG 22:37:33.005 Cache miss, src 192.168.10.21, dst 239.255.255.250, iif 4 22:37:33.005 create source entry, source 192.168.10.21 22:37:33.005 move_kernel_cache: SG 22:37:33.185 Cache miss, src 192.168.10.17, dst 239.255.255.250, iif 4 22:37:33.185 create source entry, source 192.168.10.17 22:37:33.185 move_kernel_cache: SG 22:37:34.274 Cache miss, src 192.168.40.10, dst 239.255.255.250, iif 7 Virtual Interface Table ====================================================== Vif Local Address Subnet Thresh Flags Neighbors --- --------------- ------------------ ------ --------- ----------------- 0 x.x.x.x x.x.x/24 1 DISABLED 1 192.168.0.1 192.168 1 DISABLED 2 192.168.13.1 192.168.13 1 DISABLED 3 192.168.255.1 192.168.255 1 DISABLED 4 192.168.10.1 192.168.10 1 DR NO-NBR 5 192.168.20.1 192.168.20 1 DISABLED 6 192.168.30.1 192.168.30 1 DISABLED 7 192.168.40.1 192.168.40 1 DR NO-NBR 8 192.168.10.1 register_vif0 1 Vif SSM Group Sources Multicast Routing Table ====================================================== --------------------------------- (*,*,G) ------------------------------------ Number of Groups: 0 Number of Cache MIRRORs: 0 ------------------------------------------------------------------------------
The log above clearly shows some traffic where 192.168.10.13-17 are Sonos speakers and 192.168.40.10 is my Android phone with Sonos control app trying to find them. I still get "We can't connect to Sonos". And somehow Multicast Routing Table is empty anyway.
Any ideas? Thanks!
-
@denix I will try to look into it this weekend, btw the tagging should not matter, tagging is only there in the trunk and when it leaves the subnet, so LAN or VLAN should not matter.
I don't know why you used "enable" in the config file, as by default all interfaces are enabled and as you can see in my config I disabled all but the subnet that holds the Sonos speakers and the other subnet that holds the Sonos applications. -
@Qinn how do you have your Sonos speakers connected to the network? Do you use Bridge or Boost? Do you connect them Wirelessly or with Ethernet cable?
-
@denix said in Sonos speakers and applications on different subnets (VLAN's):
@Qinn how do you have your Sonos speakers connected to the network? Do you use Bridge or Boost? Do you connect them Wirelessly or with Ethernet cable?
Neither all Sonos devices connect to a AP, so by WiFi and there is no bridge or boost from Sonos. In total there are 3 Sonos Play:1, 1 Play:3 and a Sonos Connect:AMP. On this AP there are 5 SSIDs's each with it's own VLAN ID (so isolation) IP's are (as it is a AP) assigned by the DHCP server from pfSense.
-
@Qinn did you have to re-pair Sonos and the controller once you got your network and pfSense setup?
Nothing seems to work on my end. Unfortunately I don't have WiFi that can do VLAN, so isolation is done on a switch. WiFi connects to one of the ports that gets tagged, so everything wireless goes to that VLAN. I had most of my Sonos speakers wired, so once I isolated their ports to another VLAN, they dutifully got new IPs from pfSense's DHCP server for that segment. Running PIMD between those VLAN segments and the controller doesn't see the speakers.
I even ended up resetting the controller, and one of the spare Sonos:1 speakers. I paired them up, but the speaker got onto the the WiFi SSID and the same VLAN as the controller. That works, but the speaker now sits on the WiFi VLAN and refuses to connect with a cable to go into own dedicated VLAN... Tried pairing a Bridge, but since it's wired, it can never get detected by the controller, since they are in separate VLANs. PIMD doesn't seem to help a bit.
Can't get it to work, no matter what I try. Any help would be greatly appreciated! Thanks.
-
@denix Could you draw the setup of your network?
-
@denix Did you enable the "Allow packets with IP options to pass. Otherwise they are blocked by default. This is usually only seen with multicast traffic" rule in the advanced options in your Firewall rules?
-
@Rai80 bingo!
That was it. Once I enabled that option in Firewall Rules for each VLAN segment configured in PIMD, I started seeing a lot more traffic in PIMD debug.
One more thing - all the above works with existing setup. Creating new Sonos network or adding new speakers doesn't work, as I read somewhere that pressing Play/Pause and Volume+ buttons doesn't get propagated between segments over multicast.
Since I already reset the controller, I needed one more step: I brought up a temporary WiFi SSID on the same VLAN as Sonos speakers, connect my Android phone to that WiFi and setup the Controller. After that, moving it back to the main WiFi SSID works and it still sees and controls speakers on a separate VLAN with PIMD running.
Now I'm happy. Thanks everyone for all the help!
PS. Would be nice to figure out how to setup new Sonos speakers w/o using the temporary SSID...