Can't find SONOS when connected to VPN

[EelcoA]

I have openvpn configured to connect automatically. But then NOSON can not find my SONOS, while pinging the sonos gives no problem. After disabling VPN NOSON can find SONOS. And then after starting the VPN again NOSON keeps working fine, so it just has problems with the VPN while connecting at start-up.

[janbar]

Hi @EelcoA , the startup begins by discovering sonos devices. It needs to broadcast a magic upnp message on udp, then to wait response from your devices. The broadcast address is 239.255.255.250 on port 1900 (upnp specs). I use a VPN here to connect to my work area (using openvpn), but I haven't your issue. May be multicast is disabled when you enable your VPN connection or udp packets are routed somewhere. It seems to be very hard to debug your issue.

[janbar]

If you are able to debug yourself, the "discovering" is done by the function https://github.com/janbar/noson-app/blob/4741edbf1fdca9380ce6dd28f3a81cf56a3af5ff/backend/lib/noson/noson/src/sonossystem.cpp#L270

[EelcoA]

Hi @janbar , thanks for replying. I am not able to debug it myself. But I did create a workaround. A script that kills openvpn, starts Noson and restarts VPN, with pauses of several seconds between it:

echo "killed openvpn...." pkill openvpn echo "sleep 5" sleep 5 echo "start noson" nohup noson > /dev/null & echo "sleep 5" sleep 5 echo "start openvpn" nohup openvpn /etc/openvpn/myvpnconfiguration.conf > /dev/null &

[stigok]

I have the same issue with my OpenVPN connection. My OpenVPN client configuration adds two default routes (0.0.0.0/1 and 128.0.0.0/1) on connect. My routing table then looks like this:

0.0.0.0/1 via 192.168.142.9 dev tun0 
default via 192.168.0.1 dev wlp3s0 proto dhcp src 192.168.0.28 metric 150 
128.0.0.0/1 via 192.168.142.9 dev tun0

The multicast packet is emitted on the tun0 interface, hence no response from the Sonos devices. I am thinking that I can add an additional route upon connecting the VPN that adds a default route for multicast addresses, but will however introduce security concerns for the VPN connection.

I'll come back here if I find a solution.

[ancap76]

I'm late to the party, but I just resolved this issue by adding a route that sends SSDP packets through my WiFi adapter rather than the VPN tunnel.

Linux #ip route add 239.255.255.250/32 dev wlp59s0

Windows (taking a guess on this one) route ADD 239.255.255.250 MASK 255.255.255.255 192.168.0.1

[R8s6]

The same happens with wireguard (a modern VPN protocol recently adopted into Linux kernel).

The network is like this: Internet <---> home network router <---> laptop, SONOS speaker, and other LAN devices , where laptop is connected to a wireguard server on the internet but SONOS speaker is not.

The laptop can talk to other LAN devices fine, but noson cannot discover SONOS speaker (only during the startup phase; it can, however, control SONOS if disconnected from and then reconnected to the wireguard server).

In comparison, the cellphone can still connect to SONOS speaker when connected to the wireguard server.

Here's log:

Signal handler is enabled.
"using file ':/i18n/noson_en.qm ' for translations."
thumbnailer: register API [LASTFM]
thumbnailer: register API [DEEZER]
installing thumbnails cache in folder "/home/aaa/.local/share/janbar/io.github.janbar.noson/QML/OfflineStorage"
thumbnailer is initialized
qml: LANG=en_US
thumbnailer: configure API [DEEZER]
registerContent: 0x564583929bf0 ()
registerContent: 0x564583926ba0 (FV:2)
registerContent: 0x564583928c30 ()
registerContent: 0x564583922cd0 (SQ:)
registerContent: 0x564583927d00 ()
registerContent: 0x5645837d7f30 ()

Here noson reports "No Sonos zone found"

If "search for sonos zone" button is hit, it'll add a line:

thumbnailer: reset state