Sonos - broadcasting between different subnets

wait … if you see the multicast from OH, so the problem is OH is not receiving the answer back (or just ignoring).

If I well understood, the answer is an UDP unicast flow to the original UDP port OH was using as source of the multicast flow … it would be good if we can see this flow back … and if that flow hits the OH interface

i have mdns enabled via avahi package (obv. for the needed vlans).
as for upnp - that is an out-of-the-box functionality of pfsense.

basically, i never changed my settings since i shared my approach earlier in that topic.

what i can see after triggering sonos discovery out of OH3;

  • pfsense/pimd sees OHs’ broadcast on (this is an UDP broadcast on :1900)
  • pfsense/pimd forwards that broadcast to speaker2
  • pfsense/pimd sees a broadcast on between speaker1 and speaker2
  • pfsense/rule allowing a state from OH to (this is IGMP)
  • pfsense/rule allowing a state from OH to (this is PIM)
  • pfsense/rule allowing a state from speaker1 to (this is again IGMP)
  • pfsense/rule allowing a state from speaker2 to (this is again IGMP)

what i can see after controlling my speakers with S2;

  • pfsense/rule allowing states from S2 to speaker1/speaker2 (this is TCP on :1400 / :1403)
  • pfsense/rule allowing states from speaker1/speaker2 to S2 (this is TCP on :3500)
  • pfsense/rule allowing a state from speaker1 to (this is again IGMP)
  • pfsense/rule allowing a state from speaker2 to (this is again IGMP)
  • pfsense/pimd sees S2s’ broadcast on
  • pfsense/pimd forwards that broadcast to speaker2

so basically it seems to me that OH/sonos-binding can’t establish the connection to the speakers, but its broadcast reach the target.

edit #1:
running tcpdump -i [IF] udp and src [PFSENSE] and dst [OH] sees that the pfsense-gateway is replying back to OH:41944 where it sent the UDP:1900 broadcast for discovery. that would confirm your assumption “the problem is OH is not receiving the answer back (or just ignoring).”.

@jwiseman @Lolodomo an issue with JuPnP? as far as I understand, the Sonos Binding is fully on top on JuPnP framework.

Where I can find how JuPnP works?

It seems (but I need to double check with Wireshark) OH is sending the right discovery request to SSDP address, and it’s routed properly to the Sonos vlan … the answer (Unicast UDP) is routed back, but it seems ignored by the OH host.

that is not happening if the Sonos device is on the same vlan as OH host. It seems like the OH is expecting a local answer, and not an answer by another subnet.


JuPnP failing - causing devices to go offline · Issue #5892 · openhab/openhab-addons · GitHub

Best, Jay

I would point anyone still having JuPnP issues to Add option to disable threadpool - Add retryAfterSeconds - Disable UPnP actions for HTTPS by morph166955 · Pull Request #129 · jupnp/jupnp · GitHub

Specifically, grab the jar from Release 2.6.0-SNAPSHOT-threadpool-8392ab9 · morph166955/jupnp · GitHub

Install this though the karaf console. You will 1000% have to restart openhab for this to work properly once you install it. It also has a tendency to stall/fail if the system has been up for a while so it may take a few attempts.

Go into services/runtime.cfg and paste the following:


You’re going to want to paste that config in after you load the new jar, while the OH service is shutdown.

This in theory should help if not completely resolve the issue. This works on both OH2.5 and OH3.

Please let me know if it helps, or completely does not so we can track as part of the PR above.

EDIT: To be clear, this only resolves some of the issues specific to JuPnP. The issue of the device being on a seprate VLAN may or may not be resolved by this. That is due to the fact that you aren’t repeating UPnP messages across the VLANs as well as some funny business Sonos did.

fully agree on that.

well basically that is exactly what i’m doing with that multicast-relay. again, all of this already worked already. i’m also fully aware that the binding-desc states that this might be an issue, because it was coded for the setup that both OH and the sonos devices are within the same subnet. but (!) we are already at that point where OH reaches the speakers in another subnet, but can’t discover them, even though the speaker “talks back”. what @ariela did is just to add another interface and voila, it seems to work for OH. so actually (if you ask me) the issue should be somewhere between receiving the package and interpreting it.

Sorry, should have read the thread more before replying. There are a few things here that could be causing the issues. I’ve done mDNS/UPnP across subnets before, but it’s never been clean. @Lolodomo please keep me honest about the way the Sonos binding works with my thoughts here. The Sonos binding is getting it’s basic data from jupnp obviously. JuPnP establishes a registry internally of all devices that it sees. So the fact that you’re seeing them is a byproduct of that. You mention that you grabbed some pcap and that the OH host is ignoring the reply packet. Can you check the TTL on the return packet? I vaguely remember somewhere that the Sonos packets all had a TTL of 1 which is causing them to get dropped when it gets decremented.

troubleshooting in progress here.

I’ve created a new OH v3 vm, on a different subnet (UPnP enabled):

vlan 17 OH3 server
vlan 10 OH2 server + Sonos controllers + Sonos Move (wifi) + Denon AVR3311
vlan 3 Sonos Port (wired)

Denon AVR3311 is visible for OH3, so the UPnP routing is working properly
OH3 is not able to see any Sonos Device :frowning:

edit 2: moving Denon on vlan 3, it is recognised correctly … so UPnP is working fine, and I presume also JuPnP is OK. Still fighting with Sonos :frowning:


hi! took me some time, because i’ve set up opnsense in parallel to see if it’s a routing issue on the firewall itself. answer is plain simple; yes.

i just installed an opnsense plugin called “os-udpbroadcastrelay” (same as @pstoermer was mentioning here) with the most basic config (it literally tells you the sonos params in the help), that’s all… re-run oh’s discovery, all speakers instantly in my inbox.

Pay attention with a multicast-relay, my friend. I’ve tried this in my environment (all Ubiquiti), and there were some crazy behaviours …I preferred to add a new interface on OH :wink: much easier, and still acceptable from security point of view.


Sounds interesting! Could you please explain in more detail what you mean by adding a new interface? Which steps need to be performed?

Nothing complex … depending on your implementation. I’ve added a new interface in my openhabian vm hosted by Synology … a leg in the vlan where I have all my Sonos devices … and voilà, everything’s working

Not 100% sure you convinced me … I have this implementation:

  • vlan 3: sonos devices (and other media devices that use UPnP, like Denon …)
  • vlan 10: sonos controllers
  • vlan 17: OH3

Sonos controllers are working correctly, and they see all Sonos devices.
OH3 can discover automatically Denon, but not Sonos
OH3 is able to discover Sonos only adding a new interface on vlan 3 in my vm

hi buddy. well, i have a very similiar setup;

  • vlan1 - oh3
  • vlan2 - controller
  • vlan3 - sonos speakers

vlan1 <-> vlan3 worked until sonos s2
vlan2 <-> vlan3 always worked, even after sonos s2 (as you said: “sonos controllers are working correctly, and they see all sonos devices.”)

the settings in opnsenses’ “udp-broadcast relay” are quite simple (if anyone wants to give it a try);

  • relay port: 1900
  • relay interfaces: the ones you need to broadcast between (in my example from above vlan1, vlan2, vlan3)
  • broadcast address:

additionally, i added a very simple firewall rule on vlan3 that allows traffic between “sonos speakers” (= alias) to "sonos controllers (= alias).

after a few day of testing, i can’t find any anomalies in my unifi controller that are bound to upnp or multicasting.

if i was asked to sum that whole thread up for anyone joining in late;

  • it is not possible /wo additional “implementations” to get the sonos binding to work if oh3 and the sonos speakers are in different subnets
  • though, there are 3 different approaches that lead to working results;

A) @pstoermer approach by running a python-based multicast-relay in kubernetes is described here
B) @ariela approach by adding a new interface in openhabian is described here and here
C) my approach (non-kubernetes and non-openhabian), by using the “os-udpbroadcastrelay” plugin for opnsense is described right above

I’m quite interested on how you implemented opnsense in a unifi environment :slight_smile: I’m using USG, that is not a firewall indeed … and I would add an additional layer of security. Perhaps we can discuss this topic offline


Hi Christian,
I use pfsense instead of opnsense. Can you detail how you implemented the udp-broadcast relay as I do not see this plugin. is it a command line install in pfsense?

i started with an USG4pro, but was not happy at all and sold it after only a few weeks. my next step was installing pfsense on a ci323 (because of the needed 2 nics [wan/lan]) - with the goal to have dns/firewall/dhcp/… all at one place. what i kept were the unifi ap’s, because - hands-down- they’re awesome.

i then changed the ci323 to a protectli appliance (also with pfsense). at that time i was already thinking about switching to opnsense, but due to time issues, i decided to still go with pfsense (just imported the old config after applying the necessary changes [ci323 has two nics, protectli fw4b has 4]).

for failover, i decided to buy another fw4b few months ago, but this time i wanted to (finally) give opnsense a try, so i set it up in a seperate subnet so that two firewall appliances won’t interact with each other.

i’m really happy now with opnsense (went live last week) and i will stay with it (no plans to change back - also because of the late “news” of pfsense and their way back to closed source).

all in all i have my opnsense in place that is connected to my modem and my managed switch (to apply vlan tags). opnsense is solely responsible for firewalling/rules, providing dhcp and also serves as dns. of course there are some additional features like ntp and that broadcast-relay…

from time to time i fire up the unifi controller (hosted in a vm) if i need to change things - but this is very rare.

hi buddy. pfsense doesn’t have a pre-built package for that broadcast-relay. the only thing you can do is to follow peter’s approach.

the latest pfsense distros come with pre-installed python, but please keep in mind that there’s no symlink from python to the installed pkg. so if you want to call a python-script (and we’re talking here about a python-based relay), you would need to call it with e.g. python3.X <your_script>.py.

please also note that the relays’ description says “ requires the python ‘netifaces’ package.” so you will also need to install pip on your pfsense to get that needed ‘netifaces’ package installed on your machine.

again, i never installed that relay on pfsense, so unfortunately i can only try to point you into the right direction.

Hi @epicurean,
I would definitely give it a try with the approach @csi_oh mentioned. In my description I talk about Kubernetes a lot and that may sound a bit over the top. But the part that you may need is way simpler: Very roughly speaking you need to have a (virtual) machine that has two network interfaces, one for each network. In my case the network interfaces have the names enp1s0 and cni0. You find ‘your’ names by calling ip addr and then looking for familiar IP addresses. This command might help you on this, e.g. if one of the networks is starting with 192.168:

ip -4 -o addr | grep 192.168. | awk ‘{print $2}’

And then you just have to call

sudo ./ --interfaces enp1s0 cni0

(with the network interface names that apply in your case) in the directory where you put the file before.

I have to admit that my knowledge about networks is quite limited. So I cannot really tell you what that tool exactly does. But it fixed my problem. :wink:

Thank you Christian and Peter for responding. All this info appears to be way over the top for me so i will endeavour to read up to understand. Really makes me wonder if all this effort is worthwhile just to be able to control Sonos devices with OH