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.

    Three "very" important notes :

    1. You will have to be able to use the CLI (command line interface) for instance use Putty.
    2. 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 the daemon, 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

    pkg add http://pkg.freebsd.org/FreeBSD:11:amd64/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 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
    

    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: you don't have to enable the Allow IP options in the Advanced Options of the rules, as is sometimes mentioned using igmp proxy.

    0_1546438883716_Rule-Sonos-applications.png

    0_1546438886123_Rule-Sonos-speakers.png

    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