Unable to AirPlay to Era 100/300 in separate VLANs

After some Wireshark packet capture and syslog monitoring, I worked out the differences between the way in which Sonos have implemented their Airplay integration compared with other manufacturers that were working on my network.

• My Sonos speakers are on an isolated SSID and VLAN along with my other IoT kit.
• My i-devices used to control Sonos and other Airplay devices on are another SSID and VLAN.
• I have allow all type rules between the i-devices VLAN and the IoT VLAN that allows all traffic AND associated replies from the IoT VLAN.
• Airplay and use of the Sonos iOS app from one VLAN to the other has been working fine until a Sonos update around Christmas time.  Airplay stopped working on Sonos.
• I have other Airplay devices that carried on working from one VLAN to another so the problem was specific to Sonos.

Airplay from an i-device to an Airplay target seems to want to establish some timing calibration, usually on UDP port 319.  My other (functioning) Airplay devices (Cambridge Audio and Eversolo) were happy to let the i-device initiating the stream start the timing configuration if they could not start the conversation on UDP port 319 which would be blocked by my FW rules from the IoT → secured network.

The Sonos speakers would just drop the stream after a second or so.  Sonos seem to have made the ability to start the stream contingent on the Sonos speakers being able to initiate the timing conversation.

I set up a FW rule allowing UDP port 319 from my Sonos speakers to my secure VLAN and Airplay has been fine since.

Hope this helps someone with similar issues.  Not sure why Sonos have coded their Airplay integration in this way.

Hi ​@Arcticpollen 

To be very clear, I do not know for sure, but my assumption would be that we insist (if indeed we do - I’m going solely by what you have said here) on being in charge of the AirPlay timing to facilitate the grouping-in of other Sonos players. Just a guess on my part, but it seems likely.

I hope this helps.

Hi ​@Corry P - I did packet captures and syslog monitoring for Airplay streams to both Sonos speakers and other Airplay targets.

The non Sonos targets were able to stream without being able to establish the timing conversation directly themselves and were happy to rely on subsequent UDP timing data from the client device which was allowed directly by my FW rules from secure VLAN → IoT VLAN.

My Sonos 5s and Symfonisk lamp refused to follow the same chain of traffic and would stop playing the stream after a second or so without the FW rule allowing the 319-UDP traffic stream explicitly. I could see the UDP 319 traffic being blocked and the stream would stop immediately afterwards.

Apple’s Airplay standards are pretty opaque but it’s odd that other major manufacturers supporting Airplay have more relaxed standards than Sonos on the intitial timing data conversation.

The Sonos 5s are in a stereo pair but the Symfonisk is not.  I could see various UDP traffic in the range of ports 319-321 in the subsequent conversations between the i-devices and the Sonos speakers.  Once initiated by the i-device, the return traffic was allowed by my inter VLAN FW rules.

It’s all past my pay-grade, ​@Arcticpollen, but we do recommend only Airplay-ing to one Sonos target and grouping within the Sonos app, rather than selecting multiple targets on the host device - I presume this is why.

No need to defend your findings - I was not disagreeing with them, only making sure that I did not accidentally confirm them (I really don’t know if you’re right or not, but it sounds plausible enough).

As mentioned, I don’t know the technicalities of it all, but I would assume the AirPlay method of syncing and the Sonos method are perhaps different in some way, and that if we were to use the AirPlay method, grouping to other Sonos targets would not be practical. Considering we promote the use of an AirPlay-capable speaker to get AirPlay content playing on non-AirPlay-compatible speakers, it seems prudent for us to keep things as they are. Again, all supposition on my part.

This blog suggests PTP (UDP ports 319/230) are required for AirPlay from Apple devices to Apple devices, ie even if there are no Sonos devices, so not specific to Sonos. Possibly specific to AirPlay 2 that Sonos uses?

https://blogs.thismonkey.com/?p=30

​@craigski - Thanks for the link, very interesting. My Eversolo streamer is only Airplay 1 compatable but the CA CXNv2 supports Airplay 2 and both are on the same IoT VLAN alongside the Sonos speakers.

I could use Airplay to either of these without the UDP 319 rule on the FW without the stream stopping after a second or two.  When streaming to either of those 2 devices, I could see my phone or iPad taking over the management of the precision time-keeping protocol conversations in the packet traces.

My Sonos Airplay capable speakers refused to maintain the stream if they could not initiate the precision time-keeping protocol conversation.

Have just tried to get as much information into these comments in case it helps someone else in the future.  Airplay to my Sonos speakers has always worked fine across the VLANs since I put my UniFi home network in around 10 years ago but stopped around Christmas time.

Yes, interesting (to some). Every day is school day. 😀

My point was PTP UDP 319/320 is required for Apple only devices, according to that blog, ie not specific to Sonos.

However, Apple do not list PTP in their AirPlay network requirements:

https://support.apple.com/en-gb/103229

If anyone is thinking about separate VLANs for Sonos (or AirPlay/Matter/etc) devices and controllers, and needs convincing why you shouldn’t do it, read the blog below.

Its not specific to Sonos, but explains in detail why it is not a good idea. If you are short of time, just read the mDNS section:

https://www.derekseaman.com/2023/10/part-3-smart-home-matter-and-thread-deep-dive.html

In addition, if you do any network segmentation, always, always, place all your Matter devices, smart home hubs and Home Assistant in the SAME VLAN. DO NOT segment your IoT devices in a different VLAN from the control plane. 

Thanks for the link to that series or articles. The author’s main concerns seemed to be around Home Assistant, particularly when using mDNS over IPv6.

My home network is Unifi based and their IPv6 implementation is still very much a work in progress.  I don’t have IPv6 enabled anywhere, mainly due to my current ISP not offering it yet.  I did have a play with it out of curiosity when I was with ZEN Internet but couldn’t see very much benefit from doing so against the effort to maintain the VLAN segregation I’ve currently got over IPv4.

Even if you LAN is not configured for global IPv6, your AirPlay devices will have IPv6 Link-Local address, I recall AirPlay2 uses these addresses. 

Agree, its HA centric, but look in the mDNS section, it does also mention IPv4.

Do NOT enable any mDNS reflectors/forwarders/Bonjour Gateway on ANY network devices. This includes any Unifi, Firewalla, or other gear that gives you that “feature”. Attempting IPv6 mDNS forwarding across VLANs will almost certainly cause problems. mDNS reflector implementations are xxxx for IPv4, and don’t even think about doing it with IPv6. TURN THAT XXXX OFF. For Firewalla, tap on the gear in the upper right corner of the home page -> Advanced -> Configurations -> mDNS Reflector. Turn if OFF for ALL networks.