Yes, I’m using opnsense’s UDP Broadcast Relay to handle the UPnP/SSDP and mDNS broadcasts. I also use it for Chromecasts. It has worked perfectly with Sonos speakers and Chromecasts for over a year like that. Only just recently having these frequent periodic drop outs. The Chromecasts are not affected and continue to operate without dropouts. They are on the same VLAN as the Sonos speakers.
For example:
I’m surprised that no cloud is involved – that’s very nice! Still, makes me wonder why the outages are so regular… hmm…
One very specific thing that I had to do in my setup was to allow UDP unicast responses from the Sonos speakers back to HA anywhere in the ephemeral Linux range (32768-61000). I’m not certain that’s still the case with the new SSDP implementation, though.
So last night, I tried to see if I could fix the terrible connection between HA and Sonos. I ran around my house and unplugged all the speakers. I plugged only one in and saw it pop up on the Sonos app. I then checked HA and all three speaker’s statuses were messed up. The one that was now plugged in was offline and another one that wasn’t plugged in had content on it. I plugged the rest of them in. Nothing changed on HA.
Then I removed the integration with auto discovery and tried reinstalling the integration with auto discovery and it said it couldn’t detect my speakers (I was also doing HA restarts to ensure things were wiped out properly). I finally gave up, removed the auto discovery integration all together, and hardcoded the hosts: list in the config file.
Now all speakers are solid again, go figure. I’m wondering if something is wrong with the discovery on this integration because I have two chromecasts and a dozen and a half ESPHome devices and they all work great…
Make sure you’re on the latest release. The discovery mechanisms have changed/improved significantly over the past couple releases (including point releases).
If you’ve upgraded to the Sonos 13.3 firmware, it changed the speakers’ discovery behaviors a bit. These should be handled better in the upcoming 2021.10 release.
Coincidentally I recently moved to an opnsense setup myself and went through the process of isolating my Sonos equipment in a locked down VLAN subnet. I ended up using the UDP broadcast relay for SSDP and mDNS like you mentioned above, enabled an IGMP relay between my main LAN and the isolated VLAN, and made sure that discovery reponses are making their way back from the speakers to the LAN devices. Works great with both the Sonos app and multiple instances of HA. Sonos app loads faster, too.
For the firewall rules, the UDP ports back to the less-restricted LAN are probably the most important set:
Is there a “positive confirmation” way to determine this? I mean, what method do you use to prove that the responses are making it back? I’ve just been trying to enable any packets that I see getting dropped by opnsense – I don’t see any getting dropped now but I’m assuming that they’re all making it through.
What does that look like?
Thanks for your help with this… it’s nice to know someone with a configuration like mine has it working so well. Must be something on my end to fix, I just need to learn how to see it.
Just running homeassistant.components.sonos in debug will show you discovery successes. You’ll see messages like “New <SSDP/zeroconf> discovery” with details on the found speaker(s). You may also find additional clues on what’s failing on you.
Alternatively you can run homeassistant.components.ssdp and homeassistant.components.zeroconf in debug to see the raw discovery messages before they’re passed onto the sonos integration.
Finally, you could always run tcpdump on the opnsense box itself. For example, something like this to verify SSDP responses:
$ tcpdump -enXi <lan_interface_name> 'udp and ((src <ip_of_ha> and dst port 1900) or (dst <ip_of_ha> and src <ip_of_speaker> and portrange 32768-60999))'
This will listen for SSDP multicast/broadcast messages and their responses. You should see multicast (239.255.255.250:1900) and broadcast (255.255.255.255:1900) discovery packets sent out with “ssdp:discover” in the payload and then many responses back from the speaker. If you’re not seeing responses back, check your firewall rules again.
Thank you very much @jjlawren, I really want to do this and I’m sorry but you’re going to have to dumb it down a little… Is there some page that describes how to “run homeassistant.components.sonos in debug”? I’m not sure what that means.
Wow, thanks for all this direction/detail. So, when I use the tcpdump command it shows me several ssdp:discover packets are sent. Looks like I get two discover packets every minute or so but the speaker doesn’t respond until 2-6 pairs of them have been sent (about every 2-6 minutes). When the speaker responds I get 22 packets back, is that normal? I’m guessing I should be seeing as many responses as I see discover requests, right?
I checked my rules and I have nearly identical line to the one you shared, here’s mine:
Not necessarily. Are you on the 13.3 Sonos firmware (latest)? Sonos made a couple changes to discovery in that release which caused problems for some people. There are a couple fixes slated for 2021.10 which will be released later this week. You could also test the current beta to get those fixes a bit earlier.
I can’t tell which hosts/ports you’re allowing from the screenshot, but try to match what I shared above.
That looks correct. However, I have an additional relay for mDNS:
enabled: checked
Relay Port: 5353
Relay Interfaces: HA_interface and Sonos_interface
Broadcast Address: 224.0.0.251
Source Address: 1.1.1.1
instance ID: 3
Use TTL for ID: unchecked
Description: mDNS
I just checked and I am on 13.3. I’ll give it a try when 2021.10 comes out.
This is what I’ve currently got configured, it’s broader than your list:
I probably don’t need all of those… I’d cut it back if I could get it to work, lol.
Yeah, I have the same mDNS settings too; it works great with ESPHome.
@jjlawren I’m now on 2021.10.5 and I tried turning removing the manual-forcing of the Sonos devices in my configuration, removed the integration, and restart HA. When I try to re-install the integration I get this:
Sorry, I missed your response last week. I imagine there must be something else in the isolated subnet setup which is causing this, but it’s hard to guess exactly what that could be.
You could validate it’s related to this by moving a speaker to the same subnet as your HA box to see if it’s reliably discovered and its availability remains stable.
