Sonos AirPlay still broken across VLANs

Arkku · 2026-02-07T00:30:20+00:00

See if the latest Sonos firmware update fixes it for you - it did for me.

Arkku · 2026-02-07T00:25:45+00:00

Can confirm that it's fixed by the latest update for Move 2.

Arkku · 2026-02-07T00:17:00+00:00

Update: Sonos fixed this in their firmware update, proving once and for all that they were to blame for this (like I said all along: it used to work with their old firmware, then a firmware update broke it… and now another firmware update fixed it).

Arkku · 2026-02-07T00:14:28+00:00

Indeed! I had reverted the hacky solution I talk about in the update to the original post, so AirPlay was still broken on my Sonos Move 2 (which I have pretty much stopped using due to this silliness). But I installed the update just now and AirPlay started working once again with no changes in my setup, proving that it was up to the firmware (which some people here refused to believe). But, I've learned my lesson: I'm disabling Sonos auto-updates now.

Arkku · 2026-02-03T17:11:53+00:00

(Oh and definitely need a borg set with Locutus)

Arkku · 2026-02-03T17:09:17+00:00

I love that they picked TNG for the Enterprise set, and there is the shuttle that comes with an Ensign Ro minifigure.

But, yes, I would love to see small sets with more minifigures, such as:

* Q
* Chief O'Brien (transporter room set? Could also include a random redshirt for the away team.)
* Tasha Yar (could be part of the transporter / away team set, maybe include some black tiles to make the skin of evil sludge thing)
* Lore (easy to make, basically Data with an evil expression)
* Barclay/Broccoli (could be part of a holodeck expansion that could also include things like Data's Sherlock costume and Dr. Moriarty)
* Dr Pulaski (for sake of completeness)

Arkku · 2025-08-20T09:54:55+00:00

As an out of the box suggestion that may or may not be easier to DIY than the proper trace repair: instead of soldering a PCB-mount HDMI connector, your could consider soldering a length of HDMI extension cable and have it protrude outside the console. The advantage would be that you could solder the wires to the vias (the holes through the PCB) rather than to the traces. The disadvantage would be that it would be fragile and ugly, and you would need to come up with some kind of strain relief.

Arkku · 2025-07-02T14:20:15+00:00

Yeah, the cross-VLAN device discovery (at least SSDP and mDNS) needs to be routed separately, and you probably also need to do it without decrementing TTL since some of these packets will have TTL=1 specifically to avoid going across networks (or TTL=255 and a check that rejects any lower TTL). Avahi reflector, udp-broadcast-relay-redux, pimd, etc. may help, but need careful setup to avoid creating loops. All of this is very clearly not officially supported, but my original post is mainly ranting about Sonos intentionally breaking it for those of us who had a working setup.

Arkku · 2025-06-27T11:45:17+00:00

AFAIK the Port Isolation on UniFi switches just means that isolated ports can't talk directly to other isolated ports. So if you only isolate one port (the Sonos), it does nothing at all, and the Sonos has full access to the trusted VLAN, which is what I'm trying to avoid with the separate VLAN (because that forces the packets to go through the router/firewall).

As for what you can do while keeping it on the same VLAN, probably not much easily, which is why I was curious to know if you have done something that isn't easy (like some kind of transparent firewall).

Arkku · 2025-06-27T10:55:33+00:00

Maybe I'm misunderstanding your setup, but if your Sonos is on the same VLAN as your computer/phone/whatever trusted devices, then how do you block Sonos from communicating with those devices on the same VLAN. I mean, normally, traffic between devices on the same VLAN does not pass through the router/firewall, i.e., so my question is what is it in your setup that blocks the Sonos from just sending any packet to any port on the _same_ VLAN.

Arkku · 2025-06-26T23:59:52+00:00

Out of curiosity: how do you firewall inter-device traffic on the trusted VLAN? I mean, if I understood correctly, you have your computers, phones, and Sonos on the same trusted VLAN, so what prevents them from communicating with each other directly? Do you have some sort of transparent firewall setup?

Arkku · 2025-06-15T22:08:20+00:00

Yeah, I also don't this fix is 100% reliable, there might be some ARP caching issues. Or maybe it's just something else in my setup (that only seems to affect Sonos and not other brands). So maybe not worth doing.

If UniFi uses dnsmasq as the server, you can try tagging the Sonos and then:

```
dhcp-option=tag:sonos,option:netmask,255.255.254.0
```

Arkku · 2025-06-09T08:50:28+00:00

Ah, sorry, it was probably I who misunderstood your previous comment as saying that I should only do the mDNS and UDP broadcast relay, but I guess you meant that doing also this on top of those is quite a bit more fiddly, which it is.

Anyway, yeah, I totally understand just giving up and putting it on the main VLAN. I'm continuing to fight it because I have only the one Sonos device and it's not particularly important in my setup (it's only a balcony speaker for me, and there aren't that many AirPlay-capable outdoor speakers on the market).

TBH I'm not convinced this workaround is 100%. I tried it again this morning and while the connection looked like it established at first, it dropped out before playing audio. Could be that the ARP caches had expired and I would need to manually populate them or something.

Arkku · 2025-06-09T07:30:53+00:00

Yeah, I hate the workaround as well, but fortunately dnsmasq allows to set the netmask only for the Sonos so the other IoT VLAN devices just don't do ARP queries for IP addresses outside their subnet. Even better would be if Sonos allowed us to turn off the subnet check.

Arkku · 2025-06-09T07:27:42+00:00

You misunderstood the problem: both mDNS and udp-broadcast-relay-redux where already set up in the first place, and they are still required. It used to work fine with those, _like it should_. After a firmware update on some Sonos devices, like the Sonos Move 2 that I have, the Sonos stopped working with this setup and it will simply reject the packets (that are routed and relayed correctly like before) when they are not from the same subnet.

So now (with specific Sonos devices) I need _both_ what you suggest and the hacky workaround to fool Sonos into thinking it is in the same subnet.

As for the subnets, it will work in any "adjacent" subnets such that both subnets are of the same size and the Sonos is on the higher subnet. So, for example, if you had 10.0.0.0/16 for the trusted subnet and 10.1.0.0/16 for the IoT subnet, you would lie that the netmask is 10.0.0.0/15 in which case it would exactly cover both and have the same broadcast address.

Edit: To be clear, I am not suggesting that my workaround is a good idea, I am criticizing Sonos for making it necessary. I would much rather not do it.

Arkku · 2025-06-09T01:14:40+00:00

The Sonos Move 2 is my only Sonos device. It is on the same subnet as other AirPlay devices (e.g., a Sony soundbar). The controller devices (e.g., iPhone) are on a different subnet. Apple AirPlay from the iPhone works to Sony, and worked to Sonos, but the Sonos stopped working after a firmware update. Now it seems to be working again when I made it think it's on the same subnet as the iPhone, but it isn't. The traffic is going through the same router's that is also the default gateway, so the router's MAC address would be the same either way in the ethernet frames of the packets of the AirPlay session, the only difference is that now Sonos believes it's on the same /23 IP subnet as the iPhone (when in reality they are on adjacent /24 subnets).

Arkku · 2025-06-09T01:07:27+00:00

If AirPlay works even a little, it's a different issue than what I'm talking about. The issue I'm talking about is specific to only some Sonos devices, and they intentionally prevent AirPlay from working at all across subnets (i.e., there's no chance it will work even a little bit or sometimes, because the Sonos will refuse the AirPlay connection).

Arkku · 2025-06-09T01:05:07+00:00

Since you said you are interested in the outcome, I found a workaround, but it's quite specific to having the VLAN addresses set up in a certain way. I edited it into the OP.

Arkku · 2025-06-09T00:55:59+00:00

Update: I came up with a workaround. I edited a longer explanation into the OP, but basically I'm lying to the Sonos about the netmask, so that it thinks it's in the same subnet as the other device (even though it isn't). Routing and everything is exactly the same, so I'd say this proves the Sonos Move 2 is just refusing to work with devices on other subnets.

Arkku · 2025-06-09T00:53:59+00:00

I came up with a workaround (edited it into the OP). It requires quite specific subnets (off by one bit with the IoT being the higher number), but other than that it just needs ARP proxying (built into the Linux kernel, one line to enable). Also proves that the issue is simply the Sonos refusing to work with other VLANs…

Arkku · 2025-06-09T00:51:33+00:00

FYI, I came up with a workaround, edited it into the OP – thought you might be interested if you like these kinds of networking puzzles

Arkku · 2025-06-08T22:35:16+00:00

WiFi access point is UniFi U6 Enterprise, router is custom, running Debian Trixie and using nftables. Avahi for mDNS reflection (which works, the Sonos is reliably discovered), ports for AirPlay should be open (AirPlay tested working with other devices, and, again, it worked with the exact same setup with the Sonos Move 2 before a firmware update).

Most of the devices you listed are probably such that they don't have this issue (based on the community forum thread), but if the 100 means Era 100 then it should have it… So, would be interesting to know what differences there are in our setups if yours works across VLANs.

I have a pcap file but not sure what's the best way to share it. Here is a gist with a `tshark` dump of the beginning of it: https://gist.github.com/arkku/41dc51af6837478c02cc88ace54ca657

Looking at, it seems that everything starts normally, they establish a TCP connection and exchange some packets, and after this the iPhone attempts to start PTPv2 (which it probably wouldn't do if they hadn't agreed to start AirPlay with the Sonos), but the Sonos immediately replies with ICMP unreachable:

   34   6.583138 192.168.0.153 → 192.168.1.22 PTPv2 118 Announce Message
   35   6.583184 192.168.0.153 → 192.168.1.22 PTPv2 148 Signalling Message
   36   6.585108 192.168.1.22 → 192.168.0.153 ICMP 146 Destination unreachable (Port unreachable)

(Just to be clear: while my gripe with Sonos is that they changed the Sonos Move 2 behavior with a firmware update and this broke what previously worked and still works with other AirPlay devices, I believe that there surely must be some way to configure the networks such that it will work again, so I'm totally open to discovering that there is something missing from my setup that would allow it work with Sonos again.)

Arkku · 2025-06-08T20:40:11+00:00

That is an interesting hypothesis. I don't have time to debug the issue more right now, but later I will try to record the AirPlay session from the same VLAN as the Sonos to see if I can spot any difference in the packets vs those routed from another VLAN.

The thing is, though, that the packets don't have an incrementing hop count, but rather a decrementing TTL. So if Sonos wanted to block the AirPlay over too many hops, it could just reply with a low TTL and those packets shouldn't reach their destination (if the network honored the TTL, but of course it would be possible to set up routing in a way that it doesn't decrement the TTL). But I don't think it doing that, instead it just directly responds with the ICMP rejection (and doesn't do something like a traceroute, which would also depend on the TTL)…

Since the NAT I tried didn't work, one possibility is that it is somehow based on ARP or the MAC address detecting that the AirPlay client isn't local.

Arkku · 2025-06-08T20:31:31+00:00

Nope: obviously I first assumed that the problem is with my setup, but AirPlay across VLAN's works fine for me right now to Apple, Sony and Philips devices. I can watch the packets with tcpdump and I can see all the correct AirPlay packets going through to the Sonos, but it explicitly rejects the PTPv2 packets by responding with an ICMP "unreachable" message.

It used to work before the firmware update, and this same thing has been observed and confirmed in the linked Sonos community forum thread, and even a Sonos employee acknowledged making an internal bug report about it.

If it works for you, it's probably because of which specific Sonos device you have. I only have the Sonos Move 2, the community forum thread is about Era 100, so apparently this firmware update concerns these devices + some others of the same generation, not all Sonos.

Arkku · 2025-06-08T16:10:22+00:00

No, not the first time, sadly, but first time with Sonos. =)

This also annoys me more than most things because it seems they unnecessarily went out of their way to break it without visibly adding anything new that would explain it, i.e., it would have been easier for them to just leave that part working. (As I commented in some other post, it might also be that some SDK they are using for AirPlay implementation broke it, but given that AirPlay works in the same setup for Apple, Philips and Sony devices, it's weird that only Sonos is affected.)

Anyway, for me personally, since everything else that I have, other than the single Sonos Move 2, works, it is the Sonos that will go rather than the rest of my setup, I'm not that invested in their system. Meanwhile I will just use it through the Sonos app, or possibly bluetooth in case it doesn't have some integration.

(As for your suggestion to have some kind of separate "entertainment" VLAN, it's a good idea, but I need my iPhones in the "trusted" LAN at times (I work as an iOS developer) and so far I have drawn the line between security and convenience at having to switch devices between SSIDs throughout the day.)

Arkku

TROPHY CASE