Sonos speakers and applications on different subnets (VLAN's)

chpalmer

Thanks for the work here everyone!

I have a couple of cases where I need to traverse multiple routers with multicast. There might be a way to use pfsense for this after all. Right now its Cisco.

Think simulcast audio. https://www.gatesair.com/products/transport/public-safety-govt-communications

There are at least a couple other systems in the radio world that utilize multicast across subnets to distribute ROIP.

Qinn

@chpalmer Nice that you appreciate this thread, I hope it helps many, but I don't understand what's your question. The main thing here is, that I have seen, using Wireshark that the default IGMP proxy pfSense uses, does not traverse Multicast 239.255.255.250 (SSPD) across subnets and PIMD does, so it is a more reliable when you want to "spread" local multicast over subnets/VLAN's, when it's multicast that comes from internet I think the IGMP proxy, that's by default present in pfSense it will suffice.

chpalmer

This post is deleted!

chpalmer

@Qinn said in Sonos speakers and applications on different subnets (VLAN's):

I don't understand what's your question.

No question. Just a statement. :)

Qinn

@chpalmer clear ;)

vacquah

Qinn

Happy to report I got it to work! Took me months to sit down and take a look at this. It turned out to be much easier and simpler to implement than I thought.

Some notes:

l have a netgate sg-3100 box. So the amd64 pkg threw an error. but it prompted me to use the armv6 package

pkg add http://pkg.freebsd.org/FreeBSD:11:armv6/quarterly/All/pimd-2.3.2.txz

I didnt 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.
To edit the conf file at /var/etc/pimd.conf, I used diagnostics ---> file edit. You can browse to it. very easy.
After starting pimd, it threw an error in the logs - permission denied. I figured it had something to do with the rules on my Iot vlan - where the sonos devices live. So i simply created the rule below, where home_devices is an alias of specific devices the sonos controller is running on - all assigned with static ips, of course. Dont know if I need ipv6 there or not but i added it in anyway. The, sonos_ports is a list of all the ports shown in the link you provided. I threw it all into one big bucket.

sonos rules.PNG

sonos ports.PNG

I also enabled "allow ip options" under advanced options in the rule above.

Thats it!

Some issues:

I rebooted my pfsense box after I was done. When i logged back in, the pimd package in /var/etc/ was gone! I tried to start it but couldnt find it. So i copied it over again, edited it and started it. But haven't rebooted my box again! Not sure if I did something wrong the first time.
I'd like to clean up that list of sonos ports. I think some of them are intended for outbound to sonos servers and some jsut for the internal lan. No need to open all those ports to my internal lan devices. So, id like to identify which ones are outbound and which ones are for the devices on the lan only.
A bit of a pain to have to redo this everytime there is a pfsense upgrade. I hope pimd makes it as an official package.
I have upnp enabled. Not sure if turning it off will impact any of this.

Anyway ... thought i should check in to report my progress after your excellent work to get things started!

Qinn

@vacquah Great, that you finally got it to work and thanks for reporting back and sharing the how you did it. Also, nice that you pointed out, one can also make use of the Command Prompt which is in the GUI of pfSense . I didn't know that, apart of the Amd64 version there is an Arm version, pointing it out will help many

As this thread is getting bigger, I would like to emphasis on something, I noticed that once the Sonos apps and speakers have found each other, there is no more need for running PIMP (maybe after a reboot, I have tested that) to be running. It seems the addresses are somehow stored and as these are closed source apps and devices, I have not much chance of finding out on the "how to". I just say this, not that I don't trust PIMD, but somehow introducing a not approved piece of software on a firewall/router, just doesn't feel right.

News:
https://forum.netgate.com/topic/139352/pimd-a-lightweight-standalone-pim-sm-ssm-v2-multicast-routing-daemon/2

chpalmer

This is a great little tool for testing of multicast streams.

https://support.singlewire.com/s/software-downloads/a17C0000008Dg7AIAS/ictestermulticastzip

Simply launch the program one on the transmit side and one on the receive side and set accordingly. If multicast is making it then you will see the packets on the screen.

pfsensitive

I have also tried to enable multicast with pimd, but when I try to run the command

pimd -c /var/etc/pimd.conf

using Diagnostics-> Command Prompt, but in return I get

pimd: 09:35:36.449 Another multicast routing application is already running.

I don't know which application it is referring to. I have disabled imgp proxy. Avahi is running for Bonjour/Airprint.

This is the output of command top:

PID USERNAME    THR PRI NICE   SIZE    RES STATE   C   TIME    WCPU COMMAND
56564 root          1  23    0   100M 45504K piperd  2   0:14   1.56% php-fpm
  342 root          1  52    0   125M 45056K accept  3   0:20   0.00% php-fpm
44824 root          1  52    0    98M 43360K accept  3   0:11   0.00% php-fpm
92301 root          1  20    0  6400K  2596K select  1   0:09   0.00% syslogd
13534 root          1  20    0  6600K  2384K bpf     2   0:08   0.00% filterlog
31176 root          5  52    0  6900K  2328K uwait   0   0:06   0.00% dpinger
  343 root          1  52    0 96212K 40816K accept  2   0:05   0.00% php-fpm
 7830 root          1  52    0   102M 46028K accept  3   0:04   0.00% php-fpm
10260 root          1  52    0 98196K 42616K accept  3   0:04   0.00% php-fpm
48403 root          1  20    0 23592K  8956K kqread  2   0:01   0.00% nginx
20083 root          1  52   20  6968K  2656K wait    2   0:01   0.00% sh
49387 nobody        1  20    0 11524K  5248K select  0   0:01   0.00% dnsmasq
48583 root          1  20    0 23592K  8540K kqread  1   0:00   0.00% nginx
49607 root          1  20    0 12396K 12500K select  1   0:00   0.00% ntpd
94937 squid         1  20    0 99928K 35228K kqread  0   0:00   0.00% squid
77963 root          1  20    0  6324K  2324K select  3   0:00   0.00% pimd
86583 dhcpd         1  20    0 12580K  8300K select  1   0:00   0.00% dhcpd
 1370 squid         1  20    0  9948K  5088K select  0   0:00   0.00% pinger

How can I identify the conflicting application?

pfsensitive

It seems to be the pimd itself… :-)
Ran

pimd -q

and then

pimd -c /var/etc/pimd.conf

again.

Now there was noe error.

But I can still not get multicast between sonos vlan and app vlan (iphone).
So I'll come back as soon as I have given up...

edz

Has anyone been able to discover new SONOS devices across VLANs?

I can now connect to my Sonos system from my wireless VLAN (sometimes the iOS app needs the wifi turned off and on to detect the Sonos speakers but the desktop app is very stable).

What I have been unable to do is add a Sonos component (even when my phone is on the same Sonos VLAN). I have been attempting to add a Sonos Bridge but the app cannot detect it. I have tried with Avahi, PIMD and IGMP. Next attempt is turning on UPnP

johnpoz

@edz said in Sonos speakers and applications on different subnets (VLAN's):

Next attempt is turning on UPnP

How do you think that would work??

(even when my phone is on the same Sonos VLAN).

if your on the same vlan as the device and it doesn't work - how do you think its going to work across vlans? Look to problem with your wireless..

WolfTech12

Sorry for reviving an old thread but my question still felt related to this topic.

@Qinn Thank you making this guide. I was able to get multicast working across vlans because of your guide and some others here.

So my question is has anyone narrowed down the exact ports/rules to have Sonos & multicast work across vlans while denying other traffic from their IOT vlan to 'production' vlan?

I tried a rule set that @vacquah mentioned but as soon as I enabled my Deny All rule at the bottom of the rule stack, everything stops working. Only difference is that I have the allow rule working for the entire net vs a single IP/device.

vacquah

@WolfTech12

this is what my iot lan rules look like .... I am sure it can be improved, but this works for me.

pfsense rules.png

WolfTech12

@vacquah

Thanks for your help. I liked how you set up your 'out to wan' rule so I attempted to duplicate that and a few other rules. I got this to work maybe once or twice this morning but after I came home from work it just decided to fail on me again. I left pimd running too so I'm not sure what's up.

The weird part is, if I hook my phone (android or iPhone) to the IoT net then immediately switch to the LAN net, the communication isn't broken and I can control Sonos as long as the app isn't terminated. But if I terminate the app, then switch the networks, it acts like it cannot find the Sonos.

My LAN side has the special packets allowed to any. The only other thing I can think of is that when installing pimd, it gives me this warning that there is a version mismatch between it and the kernel running on the router. Perhaps I'm missing something?

Qinn

Just a few thoughts...
@WolfTech12 First, thanks for the feedback and good to hear this thread helped you!

I have a subnet (VLAN) just for my Sonos devices. This way, the port access I grant these Sonos devices on my LAN is only for them. When you choose to have a IoT subnet filled with many devices, please note that when using the rule-setup (thanks @vacquah for sharing) it best it has an alias for the Sonos devices like "sonos_devices" and an alias for the applications like "home_devices", but you did not and thus you will grant all IoT devices access to the Sonos_ports on all your devices in your LAN.

Second, I would never use an inverted rule (so using the !) to combine things, so to allow access to the internet and rejecting/blocking private subnets in one rule. I always use a direct reject, block or pass.

Here on most subnets I use:
a pass rule from net to address to access port 53, then
a reject net to access the firewall, then
a reject to access RFC1918 and finally
a pass (IPv4) to access all

stephenw10

If you're running 2.4.5 or 2.5 snapshots (or are able to) you might want to test the new pimd package to make sure it can be configured for this role.

Steve

stephenw10

I'll just say, since I just spent a while scratching my head, that you probably want to leave the Default Bind value at 'Bind to None' and then enable the interfaces you want set as 'Always Bind'.

That results in a conf file that looks like:
/var/etc/pimd/pimd.conf

###################################################################
# This file was created by an automatic configuration generator.  #
# The contents of this file will be overwritten without warning!  #
###################################################################
phyint igb2 enable
phyint igb0 enable

Steve

Qinn

@netgate and @jimp Great that you have added PIMD, Kudos and I have adapted my how to and removed the warning that it wasn't an official package as it is now, and available for users on current 2.5.0 and 2.4.5 snapshots, so anyone download it using the package manager in pfSense and set it up.

Qinn

@stephenw10 Sorry I can't test it, as I have no 2.4.5 or 2.5 operating at the moment. only 2.4.4 . Btw "Bind to none" is different from the default config file, as that one enables all the interfaces by default, so you had to disable the ones that should not be used. This approach (Bind to none by default) seems more logical