Roon on multiple subnets

Roon Software Discussion
1

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
2

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
3

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

4

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.

5

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.

6

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:

7

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?

8

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?

9

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

10

Roon is simply for what networking concerned not on par with the nowadays best-practice network-configs, It can only deal with one single subnet, Core and endpoints should all reside in that, It’s possible to connect from another subnet with roon remote. But music can only stream to endpoints within de subnet the core is connected to. I think it would be a wise thing for the developmentteam to make some efforts to change this because this concept is simply not tenable in many currently used network environments. A substantial flaw for a furthermore quite good product,

11

Not a flaw it’s a design decision to keep it simple and less support calls using a well known device discovery protocol. It’s hard enough getting it to work reliably on a simple flat network for some users let alone open the can of worms of VLANs. Sonos the leading brand still only works on a single network unless your a network twiddler as it also relies on UDP for discovery. Same goes for Heos and anything using UPnP as it’s discovery method.

AirPlay and Chromecast work across VLANs using mDNS but can run into issues just like anything else it’s all down to the Wi-Fi implementation and software. Some cheaper brands don’t always handle mDNS well though. Most modern systems seem to be good given the prominence of AirPlay in the home but even then some will block wireless to wireless multicasts and result in non discovery, some mesh systems do this. Multicast over wirlesss isn’t particular efficient either as it takes up much more airtime so can make networks more vulnerable to latency have worse performance.

I do agree though that perhaps they should switch to using mDNS for all, if it works well for Apple and Google it must have some merits.

12

Er no. That’s just rationalization. Have you dumped the packet communication that happens for discovery? It’s not straightforward or simple at all, and doesn’t use any kind of best practices or standard protocol. You in fact can get around the subnet limitation (VLANs have nothing to do with the issue) by brute forcing the UDP packets over a router. But it’s ugly and hacky.

The software devs either implemented their own ugly discovery protocol because they didn’t know better and thought they did (a really bad thing to do in the dev world) or they did it as a form of security through obscurity (which failed, since you can get around it). Either way, it’s clear it was never meant to scale. It’s a terrible blemish on software that’s supposedly for a niche group of power users.

13

It uses UDP port 9003 solely for discovery of RAAT endpoints and mDNS for others such as AirPlay and Chromecast. It uses a bunch of other UDP and TCP ports for other communications between endpoint and core. UDP will not traverse subnets in any standard network you have to configure it to do so via whatever works on your router etc. When I looked at the traffic once using wireshark nothing shouted out as being bad to me.

14

UDP won’t traverse subnets? Um… that pretty much says we shouldn’t be putting much stock in your opinion on this subject.

15

I wouldn’t call it ugly but it’s certainly not pretty. :wink:

I also assume some of this is related to the way Core is licensed. This “broadcast domain” limitation works in favor of 1 Core per network.

16

Yep - it’s pretty much a low-key form of DRM (it makes a single core in a central location accessible by dozens / hundreds of clients spread out across the internet more complex), and I suspect that wasn’t by accident.

17

It’s multicast (and broadcast) traffic that doesn’t (by default) traverse subnets. The transport layer protocol is irrelevant (and there is plenty of unicast UDP traffic out there).

18

A lot is blocked yes, but mDNS tends to be allowed pretty easily as all AirPlay and Chromecast use it and they can work fine across subnets. I have all my Chromecasts and AirPlay devices on a separate VLan and phones and remotes on another they all work fine. Roon sees them all as well and is on its own subnet.

19

Perhaps read my whole sentence rather than quote the bit that suits your agenda. I’m out of here you seem to have a beef I’ll leave you to it.

I

20

Never said it wasn’t possible. I run AirPrint, which uses mDNS, across subnets. My point is the router has to be configured to do so. There is a reason why subnets are referred to as broadcast domains.