After struggling to get Roon working reliably across VPNs and VLANs, I built a dedicated solution. Existing tools like udp-proxy-2020 helped with basic scenarios, but fell short with WireGuard roadwarrior clients, site-to-site tunnels, multiple VLANs, or combinations of these.
Roon uses UDP broadcast/multicast for discovery, which doesn’t cross network boundaries. But there’s a deeper issue: Roon endpoints register using their source IP. If that IP gets rewritten by a relay or NAT, the server can’t connect back to the client. This is why your phone might find the Roon server but never appear as an audio output.
What RoonRelay does
Forwards Roon discovery packets across VPNs, VLANs, and remote sites
Preserves original source IP using raw sockets
Supports site-to-site deployments with a tunnel between relay instances
Lightweight C# (.NET 8) service, runs on Linux as a systemd service.
Please read before asking questions - most setups are covered:
This is a solid solution. Preserving the original source IP via raw sockets is the correct way to solve the “split-brain” behavior where Roon can discover the Core but cannot stream audio.
There are, however, a few architectural constraints worth documenting to avoid user confusion:
uRPF (Reverse Path Forwarding): Because the relay injects packets with a preserved (spoofed) source IP, routers with Strict uRPF enabled (common on enterprise and UniFi gear) will drop this traffic. Users may need to disable strict uRPF or switch to loose mode on relay/VPN interfaces.
Alpine vs. Debian: Be cautious when using Alpine Linux (musl libc) for Docker images. Raw socket handling in .NET (IP_HDRINCL) has historically shown checksum inconsistencies on musl. Debian/Ubuntu-based images are a safer default.
Windows compatibility: Although this is a .NET project, modern Windows networking stacks prevent UDP source-IP spoofing via raw sockets. It is best to explicitly document this as a Linux-only solution.
MTU overhead: Encapsulating traffic inside WireGuard reduces MTU. Discovery packets are small, but fragmentation issues could arise with larger responses or metadata.
Overall, great work addressing the root cause rather than just proxying multicast traffic.
Thank you very much for your support and for the excellent points you raised. I will add a FAQ section to the README to include what you highlighted regarding uRPF and Windows incompatibilities. As for the Docker setup, I hope that some kind soul will be able to test it and provide a working docker-compose file so it can be added to the documentation. I cannot provide since I use normal LXC containers in my setup.