Roon on multiple subnets

tl;dr: Roon does work across subnets, but it’s deliberately crippled to not allow it.

I always assumed Roon wouldn’t work across subnets since that generally appears to be the case, but apparently it does. At my house with two local subnets I can hit the Roon Core from either subnet.

With that being the case I decided to check if I could install the Core in my server subnet, which is also an additional subnet, though connected by an IPsec tunnel since it sits in a datacenter. The server installed fine, but when i went to configure it with a Roon client, it wouldn’t connect. There are no firewall denies between the subnets (each side can hit the other fine) and there is only a single router between them - the same router between my two local house subnets.

I did a bunch of network checks and saw that the Roon client’s packets were definitely reaching the server and vice versa, but I was never given the option in the client to set it up. I even checked the multicast packets to 239.255.90.90 port 9003/udp which is what the Roon client joins to make discovery attempts. Sure enough, the TTL is set to 2 on those packets, so they should make it through one router.

Here you can see the client at 10.11.12.67 hitting the server at 10.250.250.25 (this is from the server itself):

01:46:59.905901 IP 10.11.12.67.51361 > 10.250.250.25.9003: UDP, length 98
01:47:05.023566 IP 10.11.12.67.51361 > 10.150.0.1.9003: UDP, length 98
01:47:05.027863 IP 10.11.12.67.51361 > 10.250.250.25.9003: UDP, length 98
01:47:05.034936 IP 10.250.250.25.9003 > 10.11.12.67.51361: UDP, length 401

And here is the client seeing occasional responses back (this is from the client):

19:48:58.103041 IP 10.11.12.67.51361 > 10.250.250.25.9003: UDP, length 98
19:48:58.110088 IP 10.250.250.25.9003 > 10.11.12.67.51361: UDP, length 401

They can clearly reach each other and talk to each other. Pretty much any other software works fine between the two machines, so this is a Roon limitation, and not done for any actual technical reason.

My only thought is that for the first connection attempt the client and server have to be in the same subnet, but after that it can be wherever, as long as they’re reachable, done as some sort of artificial restriction on how these things can connect. If that’s the case… that’s annoying. I’d rather have one of my servers doing what it’s supposed to be doing (running on datacenter power 24x7 with gobs of bandwidth) versus devoting one of my desktops to being on and sitting around all day so it can serve local content. If Roon wanted to prevent a ton of people connecting to public Roon servers there are ways around that don’t involve neutering network connectivity and limiting options.

3 Likes

Just edited this to clarify for non tech folks what the issue is - a deliberate Roon limitation, not some sort of technical hurdle that is difficult to overcome. I find this disheartening, as the audiophile community, of which is a big part of the audience Roon caters to, is used to doing what they can to optimize experiences.

This extends to software; even if it’s unconventional or difficult, enthusiasts will often go the distance to optimize for their situation. It’s disappointing to Roon take this kind of artificially limiting approach.

1 Like

hi Joselito, did you find any workaround to the deliberate Roon limitation. I am strugling with the same, as many others do… :frowning:

Unfortunately no. Ironically if you have a remote subnet that you bridge into the subnet that Roon is on (basically using any layer 2 bridging like VPLS, VXLANs, or even something like a Linux gretap interface) will allow you to use it remotely. Still, an overly complex workaround for something that should be natively supported and not intentionally hobbled.

Once you bridged the two subnets together for the first connection to find the core, did you have to keep the two subnets bridged for all future connections? Or can you keep the two subnets separated as long as you have the ability to reach the core?

Appreciate your insight since this is one of the only posts I’ve seen on a potential solution for networking Roon with different subnets.

I haven’t attempted to connect to my Roon Core across subnets, but I have observed that the RAATServer discovery does continue to use the multicast announcements. Looks like they heartbeat between the core and endpoints, so you can’t just connect it the first time and then move it.

That said, Roon appears to listen on ALL network interfaces on the core (at least on a Linux-based system). So if you have multiple networks locally, you could experiment with configuring VLAN interfaces at the OS level and have it participate on each VLAN that you have endpoints. (Again, I haven’t tested this, but my little bit of snooping around suggests that this should work. They join the multicast group on all interfaces on the system (I have a second virtual NIC in my server that bridges to the iDRAC for server health management updates and it creates a listener on this NIC in addition to the main NIC).

In theory, if you installed ZeroTier on the core and the endpoints (e.g., assuming you have OS access to the endpoint, such as with a RPi), you could have any number of physical network hops between the core and the endpoint. And given that Roon pre-buffers several seconds worth of audio, will probably work OK even on not stellar WAN links. But maybe avoid upsampling to DSD512, as that will pump out ~50Mbit/s and that might not be too special over ZeroTier… :slight_smile:

I’ve spent the past few days trying to play around with the interfaces between VLANS to support the core. My setup consists of three VLANS: one that contains the core, one with the remotes (my trusted network), and the third with end points (sonos speakers).

I have a MDNS repeater turned on between the VLANS on in the router to support multicasting and I have the router explicitly relaying the the UDP and TCP traffic on ports 9003 and 9100-9200 across all the VLANS, but that hasn’t seemed to help with the discovery process. Are there other things you’ve noticed or suggest testing to help with the discovery process?

I have no idea if this is a fluke, but this started working across subnets. It works even if my mDNS reflector is off, so I’m not sure what’s happening, or if this is a permanent thing. Anyone else got it working?

Well, this is incredibly frustrating. I have two locations connected together by peer-to-peer VPN.

Thought I’d try using Roon on my laptop and just discovered it can’t find my Roon Core presumably presumably because it’s on my other subnet.

That stinks that it’s deliberately disabled