Roon Server on Different VLAN/Subnet - Why Not?

I’ve noticed that it’s simply not possible to use Roon if the client and server are on different IP subnets (separate VLANs - Virtual LANs). There seems to be a total reliance on service discovery in order for the client to find Roon Core systems and no ability to specify the IP address or fully qualified domain name of the server.

Relying 100% on service discovery will not be sufficient as networks increase in complexity - IMHO.

My home network is a little more complex than most but the way I have things set up is becoming more common.

As long as the required port(s) are open on any router/firewall separating the two networks, there should be no reason as to why I can’t manually specify the IP address (ideally fully-qualified domain name) of the Roon Core systems.

Unfortunately, I’m left with three choices:

  1. Add a secondary network interface to my computer (physical or virtual - 802.1q VLAN tag) in order for it to be able to connect to the Roon Core on a different subnet
  2. Set up a separate Roon core (too expensive - and unnecessary)
  3. Not use Roon anymore

I keep all IoT (Internet of Things) devices on a completely different network than my home and work computers - primarily for security purposes. Also to keep down the amount of “noise” created by so many different products leveraging multicast & broadcast for service location (ahem! Roon…ahem!). The multicast & broadcast traffic consumes airtime on a wireless network. The more devices you have connected to your wireless network, the more contention for airtime. See where this is going?

Please…at least make it possible for someone to specify the address of the Roon Core server and don’t fail closed when service location doesn’t work.

1 Like

Roon does use multicast to discover endpoints. If you are experienced enough to configure your router to do multicast routing, you will get it working.

1 Like

Trying to support every bodies bastardised networks is a mammoth task even with out VLANs , given the amount of people who bolt on God knows what to extend wireless and cables without a clue about how to do it properly or about DHCP. They don’t support VLANs for a good reason as it adds an even more complex topology to support. It’s in the realm of tinkering for Roon and if you know enough about getting multicast packers to traverse vlans then go for it.

Having IoT vlan is fine I have one but I know it’s one way only generally I can see them from inside my main Lan but they cant see or touch anything on my main Lan they have to use the internet to call back to me. Roon won’t do this and needs two way traffic, so you would need to open up the ports and protocols required to make it work.

iGMP snooping is designed to keep multicast traffic to a minimum and only send it where it’s needed.

@Peter_Bruderer My router (Palo Alto Networks PA220) is configured for multicast routing. What multicast net is Roon using?

The link you shared shows a 255 in the last octet - that’s broadcast traffic, not multicast. If it were multicast, it would be using a 224.x.x.x to 239.255.x.x.

@CrystalGipsy I’m trying to figure out what it is you’re saying… is the solution to just be like the others and blast out “I’M HERE! I’M HERE!” announcements and pollute the network even more?

IGMP does indeed help reduce multicast, but it’s not a security control. Segmenting a network is for more than just reducing multicast/broadcast traffic.

As the kids say: pcap’s or it didn’t happen.

2 Likes

The client sends packets to 239.255.90.90:9003. Then Roon Core also sends discovery packets to 239.255.90.90:9003.

But there are also some packets sent to the broadcast address. I do not know if you can ignore them, if multicast suceeds. I was too lazy to find it out.

You got at least a reasonable firewall. I understand that you want to segregate your networks, when you run Palo Alto at home.

I am also using a PA-220, but I don’t think I can run @Aaron_Turner’s code on it. So separate Roon Core and clients is not an option at the moment.

No I am just saying why Roon doesnt support it. If you want to have them outside your network then it’s your choice but it’s not up to Roon to support everyone’s network infrastructure they support the most common denominator a single Lan.

It can work you just need to administer.and work it out it your self others have managed it. Roon uses a few different methods for discovery though depending on the protocols the endpoints used.

Roon supports Slimproto (squeezebox streaming) which does work in a L3 setup. On LMS at any rate. I have not tested with squeezeboxes using Roon’s version so I don’t know if that works.

pcap is an abbreviation.

If you want to sniff traffic on Palo Alto, there is a knowledge base article:

I’m certified trainer on Fortinet products, so I can only give you some rough advise on PA.

1 Like

Also Chromecasts will work on another vlan as long as you have mDNS set up. Works on my Unifi setup.

I have a PA-220 as well (got mine through work). Had no idea they were so popular. :slight_smile:

They are! But it is not a SOHO device. Did you get yours preconfigured, or are you working in the firewall area?

I wasn’t asking for VLAN support. What I stated in my original message was that I was asking for the ability to specify the IP address or FQDN of Roon Cores. If you have a way to point the Roon client directly to Roon Core, then there’s no need for discovery. Of course, discovery can/should still occur, but it wouldn’t be the end-all-be-all way of learning about Roon Core servers.

Thanks, @Peter_Bruderer - not having issues with Palo - I used to be an SE at Palo so I’m very familiar with how to take a PCAP. I appreciate the offer of assistance though! :slight_smile:

The issue is that the Roon server is not sending anything via 239.255.90.90. The only multicast net that it’s transmitting to is 239.255.255.250 - specifically for SSDP and uPNP (yuck - uPNP!). I’m sure it’s listening for 239.255.255.250 (9003/udp) - it would have to. (see below).

The Roon client is indeed using 239.255.90.90 (9003/udp) and that traffic is being accepted. (see below)

For the record - I wasn’t asking for assistance with troubleshooting my firewall. But I appreciate the offer of assistance! If you ever want training on PAN-OS, feel free to let me know. It was my primary focus while I was an SE at Palo Alto Networks, so it’s one of my specialties!

Network topology: PA220 802.1q trunk connected to a Cisco 3560X switch which is connected to a Cisco 3650CG switch (1GB fiber GBIC). Both Roon Core and Roon clients are connected via Ethernet to the Cisco 3560CG switch. Wi-Fi (even though it’s not a factor here) is Ubiquiti AC-Pro APs and a CloudKey 2 Plus controller.

PA220 is configured for IGMPv3 and PIM

Multicast groups for 239.0.0.0/8, 224.0.0.0/24, and 224.0.1.0/24

PAN-OS reserves a special security zone (Multicast) specifically for any traffic destined for any of the aforementioned multicast nets. In this rule, the Roon client is in the “JeffH_L3_Zone” and the Roon Core is in “Trust_L3_Zone”:

1 Like

I actually work for Palo Alto Networks and requested one just to learn a bit more about our products. Mine definitely was not pre-configured. Took me the better part of a day just to get PanOS updated from v8.0.6 to v9.1.7. LOL. My day job does not involve hands-on work with firewalls, so it’s nice to have one to tinker with. I’m just amazed to see others here who have one too since, as you suggested, it’s a lot different from your typical UniFi USG. :slight_smile:

1 Like

Your network topology is impressive but definitely massively uncommon among Roon subscribers. FWIW, I agree with your feature request…at least for connecting Control devices to Core. Unfortunately, Output and Display devices generally don’t offer a place to enter Core’s unicast address, so support of some kind of discovery protocol is tough to avoid. Many Output devices are 3rd party appliances with minimal functionality in firmware that’s difficult to change.

But, I may hit you up via DM if I have questions about PAN-OS. :wink:

I’ve got a PA-220 but it’s too much like my real work to set it up. They are not preconfigured but the Day One config helps a bunch. I think it’s called Day One.

The vast majority of my IoT devices are on Wifi so I simply put them on a DMZ/Guest SSID and call it a day. Roon et al lives on the inside. Unifi Edgerouter X is my home fw.

I guess I would ask the OP - Why do you want to segment Roon server from Roon clients? Just worry about your IoT devices as you have. Should they allow it, sure, but there are probably <50 Roon users that would ever use it so I can see why the developers just go for the blast away method to find each other and it works.

If you want to cut down on unnecessary traffic add PiHole to the mix. ~40% of my DNS requests are stopped, trackers and other data miners. The caching is nice too.

1 Like

Yeah. Although I have a PA-220, I’m just using it in a mini lab environment. My home network is similar to yours. UniFi USG is the home fw in my case. IoT VLAN is firewalled off from the home network and only has access to the public Internet for stuff like FireTV, thermostats, irrigation system, weather station, garage door controller, AT&T Microcell, etc.

1 Like

I figured it was more complex…but I always acknowledge that when I make requests. I know that my network is not indicative of the typical customer. But I feel pretty strongly that we’re going to see more and more cases where people are segmenting devices on their network. The last thing I want is for a vulnerability to be exploited in a camera or some other solution manufactured by the lowest bidder to be the entry point into my network.

As far as Roon Core sending to 239.255.90.90 - I’m not seeing that. Is it possible that only occurs with Roon Core on certain platforms? I’m running the Roon ROCK on an Intel NuC. Since it doesn’t double as a Roon client, I wonder if it would even need to perform any discovery of other Roon Cores?

Have you tried running Core on Ubuntu or similar? Might be worth the time to set up just as an experiment since you can SSH in and get a packet capture from Core’s side of the network. AFAIK, you can’t SSH into ROCK.

Of course, you could just mirror the traffic on Core’s switch port and do the packet capture from another device without having to set up Roon Server on another O/S.

I agree that default home network topologies are likely to become more complex, with IoT VLANs becoming more common place. But, I’m struggling to imagine a situation where you would want Core, Outputs, Displays, and Controls on different VLANs (apart from deploying Core in the cloud or setting up an Output in your car).

Again, I think this is a reasonable feature request, but I don’t know how Roon Labs would implement it in the general case since few 3rd party Roon Output devices offer a place to enter Core’s FQDN or unicast address. Same for Displays.