Recently I purchased a Sonos speaker, added it to a dedicated Wi-Fi network and tried to make the official Android app work when my phone is connected to another network. This article was used as a starting point: https://felix-kling.de/blog/2019/sonos-dedicated-vlan.html
Despite all my attempts the app couldn’t find the speaker, so I started digging around and found this bug:
It seems that there was a bug in the Linux kernel that broke igmpproxy. It was fixed in version 4.15, but Turris OS 4.0.5 uses version 4.14.162.
I would like to know if our version of the kernel is affected by this issue, because the symptoms look similar. If it’s not, I’ll post more details about my network and firewall configuration and hope someone will help me to figure this out I would really like to keep all those “smart” devices isolated from my home network as much as possible.
Managed to make it work, although I’m not exactly sure how
The kernel bug I mentioned was fixed in 4.4.114, so we should already have this fix in Turris OS.
I also found out that igmpproxy ignored SSDP discovery packets sent to 239.255.255.250, and decided to try another proxy instead. The only one I found was mcproxy, and here is the config that I used (/etc/config/mcproxy):
# Use your own MCProxy config file
config mcproxy 'mcproxy_file'
option disabled '1'
option respawn '1'
option file '/etc/mcproxy.conf'
# Use OpenWrt UCI config
config mcproxy 'mcproxy'
option disabled '0'
option respawn '1'
option protocol 'IGMPv3'
###########################################
# Simple configuration examples
# I thought this block would be enough, but it didn't work...
config instance
option disabled '0'
option name 'proxy1'
list upstream 'br-private'
list downstream 'wlan1-1'
# ... so I added this one just in case :)
config instance
option disabled '0'
option name 'proxy2'
list downstream 'br-private'
list upstream 'wlan1-1'
br-private is my “trusted” network, which doesn’t have any restrictions for outgoing connections, and wlan1-1 is the isolated Wi-Fi network for IoT devices (including Sonos).
Then with the help of tcpdump I found out that Sonos tried to connect to ports 1400, 3500 and 59651 on my phone. After adding a couple of traffic rules the app was able to connect to the speaker.
As far as I understand Sonos remembers the IP address after successful connection, because it continued to work even after I stopped mcproxy.
I also disabled the rule for port 59651, because I’m not sure what it’s used for and everything seems to work without it.
As another potential solution that I’ve had running with OpenWRT for many years, the “smcroute” package also works and gives slightly more control over which groups to forward. My configuration in /etc/smcroute.conf is:
phyint br-lan enable mrdisc
phyint br-knx enable mrdisc
phyint br-wlanguest enable mrdisc
mgroup from br-lan group 239.255.255.250
mgroup from br-knx group 239.255.255.250
mgroup from br-wlanguest group 239.255.255.250
mroute from br-lan group 239.255.255.250 to br-knx br-wlanguest
mroute from br-knx group 239.255.255.250 to br-lan br-wlanguest
mroute from br-wlanguest group 239.255.255.250 to br-lan br-knx
to bridge SSDP discovery between three subnets (bridge interfaces on top of VLANs, in this case).
Note: For Mikrotik RouterOS, I had to manually force this port to be marked as a multicast-router on the bridge, otherwise it would not get the IGMP packets with IGMP snooping enabled. I am not sure why, but with “igmp-snooping=yes multicast-router=temporary-query multicast-querier=yes” for the bridge, it works only with “multicast-router=permanent” forced for the relevant tagged-only (trunk) port connected to the Turris. For some reason the IGMP join sent by smcroute on the VLAN(s) doesn’t seem to be recognized by RouterOS to mark the bridge port as a multicast router port.
I would really like to keep all those “smart” devices isolated from my home network as much as possible.