I have a server running on a Windows 10 machine going to all devices perfectly on a VLAN I have dedicated to media devices. I have 2 devices on my Default VLAN that are recognized by Roon, but nothing happens when I try send audio to those devices (AirPlay to a HomePod and to a Macbook). Has anyone gotten AirPlay to work across VLANs? I am on a Unifi setup, but the Firewall settings I have in place don’t seem to help.
Does Ubiquiti have an “enable mDNS” setting to cross VLANs? Apple uses mDNS for discovery and I believe other uses have had success when they have confirmed mDNS on their network.
Not via Airplay whilst Roon will discover them it won’t play to them. Other apps will work just fine over vlan though. Not bothered to investigate as I don’t use it for Roon at all. Chromecasts on the other hand work perfectly fine via Roon on a different vlan.
Search for udp-proxy-2020. @Aaron_Turner has done the most work on this. @gTunes is trying to get this to work too. I don’t think it’s simple.
Unfortunately, Roon with vlans is never simple. My topology is too different for the things I do to be applicable here.
Indeed it does. It’s the setting called “Multicast DNS” and it allows an administrator to configure which vlans participate. It’s usually necessary to enable it to make device discovery work across vlans and may be enough to get AirPlay to work if the right firewall rules are in place (specifically, allowing TCP and UDP traffic between the Roon server (on one vlan) and AirPlay devices (on another).
I don’t think this applies because @Alan_Tuszynski is hosting his Roon server on Windows.
Udp-proxy-2000 is a Linux thing. For it to work, it has to be deployed on some Linux thing that is multi-homed to the Roon vlan and the vlan that the endpoints are on. It essentially sees the outbound UDP packets generated by Roon and broadcast them out onto the other vlan. It can only do this if the device its running on has a network connection to the Roon network and a network connection to the music vlan.
In my case, this is a Synology NAS on which I run Roon in a Docker container. My NAS has multiple network connections and fairly complex macvlan (in Docker) config to make it all work. I don’t think it applies to @Alan_Tuszynski.
Because @Alan_Tuszynski is just trying to get AirPlay to work, it’s possible that enabling mDNS and punching the appropriate holes in the UniFi firewall (these are LAN IN rules that would need to be created), that might be enough to get it working.
1 Like
I run a Unifi based home network with the default VLAN and 2 additional VLANs. All my audio devices and the Roon Rock are on an IoT VLAN with some firewall rules to allow the Sonos app on i-devices (all on default VLAN) to communicate with the Sonos bridge and speakers themselves. I aslo needed to enable multicast DNS on the default and IoT VLANs for this and other stuff like Sky Q to work. I don’t recall having to do anything specific when I put the Roon Rock in a while back. Roon app on i-devices seems quite happy across the VLANs.
Actually, for AirPlay, i did need a FW rule from IoT to private default VLAN allowing responses from a group of IoT hosts defined as AirPlay targets.
My FW rules were set up on my original USG well before I got the UDM Pro. I haven’t had the inclination to re-jig the existing rule sets into traffic rules as suggested by UI in the screenshot.
Generally, IoT devices cannot access the private VLAN but the rule below allows them to respond to i-devices etc for AirPlay requests. IIRC, I gave up trying to identify all the port ranges to make the rule a bit tighter from a security point of view but it only allows replies to established and related traffic.
So I kinda cheated and just moved my HomePod to the same VLAN as all the other devices using Roon and made rules for it to communicate with my other VLANs. That is my simpler workaround, but this is very interesting with your FW rule…so your Port/IP Group consists of the common AirPlay ports? I tried something similar where AirPlay ports are 5353, 49152-65535, but I had that group set as the destination and my Roon network as the source. Didn’t work, but I may have fumbled that. I will have to try a rule like this out whenever I get another device to test out on another VLAN. Thanks!
I gave up trying to identify all the port ranges needed for this so just defined a group of host IP addresses on the IoT VLAN for the Sonos/Roon/CA CXNv2 etc devices. The rule is configured so that responses are only allowed to requests that have originated from the private VLAN. The important bit with my rule is disabling the match state criteria for new and invalid traffic but allowing established and related.
There’s a general FW rule further down the list that blocks IoT to private that hasn’t been matched by an allow rule further up the list.
What’s odd is that Airplay from iOS device or macOS has no problems playing to any Airplay client across my VLAN as long as mdns is active. But via Roons Airplay just doesn’t work at all. It sees device but it refuses to play to it. So why would Roon need ports opened and forwarded that regular Airplay doesn’t?
So udp-proxy-2020 doesn’t run on Windows. That said, it was designed to run on routers/firewalls which are generally running Linux or FreeBSD, so it can work there. Since the OP is using UniFi hardware, one of the Linux binaries should do the trick. Probably worth checking out the startup scripts for a hint: udp-proxy-2020/startup-scripts at main · synfinatic/udp-proxy-2020 · GitHub
I don’t think the OP needs anything extra installed on his Unifi gateway unless it’s an older USG/USG Pro.
When I replaced my USG with a UDM Pro, the mDNS for Sonos no longer worked across VLANs and I had to use one of Boostchicken’s Unifi extras - older versions of the Unifi UDMP software were almost entirely container based so it was pretty easy to add your own functionality by adding services running in PODMAN containers and have them automaically re-installed after a firmware update.
When the UDMP finally got a shiny new OS a while ago, it was no longer containerised so I think you have to add PODMAN or similar back onto it now to do the same thing.
The native mDNS in the latest OS versions actually works for me as I want so I’ve not looked at the extras that you can still add via containers for some time now.
FWIW, Roon clients (excluding ARC) uses UDP broadcast for discovery, not multicast. Airplay uses multicast though.
Are you sure? My Roon client apps are on one VLAN and ROCK is on another. I’d not expect a UDP broadcast to make the hop although I can’t recall now if I manually added the IP of the Rock into the Roon clients when I first used them.
Yes, I’m sure.
Note: I’m not saying multicast forwarding tools won’t work for Roon discovery. I don’t know if random implementations really care at the end of the day (depends on how it was written). If the device receives the packet, it can forward it regardless of being unicast, multicast or broadcast. And if your switches are dumb enough they’ll just flood multicast packets everywhere without requiring IGMP.
Oddly I find the only Roon RAAT clients that can be seen from a different vlan are computers running Roon remote. Roon bridge clients don’t show up at all. Both my work Mac and our home laptop live on the general vlan they both have Roon installed and both work to control and as zones. I find this at odds with how Roon bridge and Roon Ready zones work as they just don’t show up at all. Airplay clients are all visable and can be enabled but Roon won’t actually engage play. Chromecasts are seen and work flawlessly.