Roon Server on Different VLAN/Subnet - Why Not?

Funny you say that! I was just thinking of setting up another computer on the same VLAN as the ROCK. I just took another look at the multicast routing diagnostics and see that my client joined 239.255.90.90 but the ROCK did not. Multicast routing won’t forward to devices that aren’t joined to the same multicast group.

I’m going to do just what you suggested and see if running on another OS (likely Ubuntu) behaves any differently.

Great minds think alike!

1 Like

My Roon server is running on Ubuntu 20.04.1

  1. the client sends a multicast request to 239.255.90.90:9003 from :57963
  2. the server responds unicast to the client :57963
  3. the server sends a multicast request to 239.255.90.90:9003
  4. the server sends a multicast request to 224.0.0.251:5353
  5. the client connects to the server port 9003
  6. the server connects to the client port 9003
  7. the client initiates a connection to the server port 9101
  8. client and server start communication on UDP high ports

I see you know your devices. I leave the debugging up to you.

As you can see in the other thread, it is possible to get it working. Good luck!

1 Like

I’m not suggesting my experience is your solution, I’m only offering my thoughts here.

I too have a VLAN segmented network with 4 VLANs: device management (only infrastructure), user (trusted main network), IoT (primarily HomeKit devices), and guest (untrusted visitors to my home). My Roon core is an Ubuntu 20.04 LTS rackmount server, and my primary endpoint is a Bryston Roon streamer, which internally uses a Raspberry Pi 3B running a Debian kernel.

I allow the core and the Bryston onto the trusted user network because they’re both running robust and secure Linux-based operating systems. My trust level in them is way higher than in a HomeKit-enabled fan or light switch, whose firmware may never be updated in years.

My firewall allows the user VLAN to open connections to the IoT VLAN but not the other way.

That’s my thinking anyway.

2 Likes

Actually, I take that back. The ROCK is also joined to 239.255.90.90.

I’m still going to test with another system.

1 Like

Hey @Kuryan_Thomas thanks for the input! That’s pretty much what I’ve done here. Given the fact that the Palo Alto firewall is a stateful firewall, technically speaking there should be no need to allow traffic from the server in the IoT network back to the trusted network, but in this particular case, I did add a rule to allow it - at least during the troubleshooting phase.

I’ll report back with my findings once I’ve had a chance to get Roon Core running on a different system.

I guess based on the number of people responding on this thread, there are more running segmented networks than I thought! GOOD!

1 Like

I experimented with having the Roon core server be dual-homed, one on the user VLAN and another on the IoT VLAN, with ufw rules enforcing separation. It worked, kind of, but it was intermittent.

I finally thought through it and realized that my VLAN architecture was based on trust rings, so if I could trust a device, there was no reason not to admit it into a higher trust ring even though technically it’s supposedly a “thing” as in IoT. Once I realized that, I just bonded my server interfaces instead of dual-homing them and put it on the user VLAN.

1 Like

I’m just going to chime in here. I have a UniFi setup with 3 VLANs (Standard, IoT, NoT) ideally everything that doesn’t need access to my main network but needs internet lives on “IoT” and anything that needs no internet connectivity lives on “NoT”. So my ideal setup is ROON Core on “IoT”, various endpoints on “NoT”, and of course my main desktop PC endpoint (desktop DAC) on the Standard VLAN.

I’ve tried multiple things and there is no “straightforward” way to accomplish this within ROON, which is honestly quite silly. You CAN manually specify the ROON Core IP address from a ROON Client (albeit a bit hidden) however the ROON Core will not pickup the client/endpoint as a playback device.

I see no reason why you can’t manually enter the ROON client/endpoint IPs in the ROON Core somewhere. Relying on multicast or what have you is “convenient” for a lot of users sure, but it’s messy and further clogs up a network. Also, there shouldn’t be a real functional reason not to support multicast (as it currently stands) and optional manual configuration for more advanced users.

I wouldn’t say it’s a “make or break” feature for me persay, but it’s definitely a very strong negative in ROON’s favor in my eyes. If anything it paints the ROON developers as out of touch and unwilling to adapt. This isn’t the first thread I’ve seen discussing this shortcoming/oversight and I’m sure it won’t be the last.

Currently I have ROON and all endpoints on the “Standard” VLAN, which works, not ideal, but it works.

2 Likes

What you’ll find is all the “workarounds” force removing a layer of security to make it work. I stopped tinkering with it as it was compromising my security model. What you’re running into is not, I suspect, a technical limitation that Roon doesn’t want / know how to overcome but decision tied to licensing. Roon is licensed per Roon Core. A Roon Core, by design, works on a single broadcast domain. I don’t believe Roon is going to make it easy to expand beyond the single broadcast domain until they roll-out mobile.

I, reluctantly, put ROCK on my “insecure” “anything goes” “IoT” network… but I did it as a VM with a hypervisor that controls networks via Open VSwitch. That allowed me deploy ROCK, without any additional hardware cost, into the same “IoT” I was going to put all my endpoints anyway. And, since I don’t have any real control over ROCK anyway, I’m happy it lives in that network. It’s also the only network I have where the wired and wireless is flat.

As you’ve already identified… Roon is chatty… maybe chattier than it needs to be but I don’t work there so won’t argue with their decisions on that. After I decided to move it, and learned more about how chatty it is, I’m really glad it sits over away from my important stuff. It can go play with the other appliances, IoT stuff, and general experimental stuff over away from where I do my banking :wink: It’s really designed to live in a single broadcast domain. Doing much different is either going to be a headache or remove enough security to question why you’ve got two domains anyway. At least, that’s my opinion on it after watching this debate and looking at various configs for a while.

@moderators Looks like this has morphed into something akin to a #tinkering thread … maybe the bulk of this (all perhaps) should be moved - I think there might also be a similar #roon:feature-requests on this too.

Why? In my mind, stuff on an IoT should have absolutely no access to internal resources, like NAS, Displays, and Outputs. These things should only access the public Internet and be controlled by aps via a public proxy. That’s not Roon Core, IMHO.

1 Like

Hello @JeffH

I run Roon Server (192.x) and clients (10.x) on two different IP networks. I run Edgerouter with mDNS service (repeater - NOT reflection) and this works well with RAAT and Chromecast. With my last test there have been issues with the implementation of Airplay (likely on the Airplay side of Roon Server - Apple device airplay to airplay works well).

I totally agree. Roon, you need to keep up with the times and allow for use of different subnets. We deal with high end residential systems, and EVERY installation has multiple subnets, essential for both security and reliability. We keep one especially for High Street junk, that the EU will buy as the latest (insecure) gadget. The main network is for the secure Pro equipment. Do Roon need to live in the junk world forever ? The product they produce is better than that !

I’m still not sure that I follow. When would you put Roon Core on a different VLAN from Controls, Outputs, and Displays?

There are obvious benefits to putting IoT devices in an “(insecure) gadget” or “junk” VLAN. Many folks have three or four different VLANs:

  • Networking Infrastructure (managed switches, access points, network controller)
  • Trusted Clients (phones, laptops, NAS, Roon, Sonos)
  • IoT (smart devices like thermostats, bulbs, garage door, irrigation system, weather station, FireTV, Android TV, fridge. Internet only. Firewalled off from other VLANs)
  • Guest (optional, but used for visitors who you don’t trust. Internet only. Firewalled off from other VLANs)

With the possible exception of Roon compatible “smart speakers”, which you may wish to segregate to the IoT VLAN, I can’t think of a reason for putting the various bits of Roon on different networks.

4 Likes

Fair point, ROON Core should likely be on the “Standard” VLAN, then various endpoints on IoT and NoT as needed.

Moot point either way though, considering I need a flat network for ROON to work properly anyways, so everything lives on the “Standard” VLAN

One scenario that I can think of, is if you have control points that are always logged in; tablets and whatnot placed around the house. I would then - in case of burglary - prefer to have them on a different network from the core which would have to have access to any backend storage.

One solution is to put the core and control points on the same network, separate from the trusted networks, and have only the music files stored there. This, however, makes the ad-hoc control points more complicated to get running, i.e. phones and work tablets.

But wouldn’t those tablets, phones, etc., be locked? For example, FaceID on iOS devices?

Yes, that is certainly advisable. But that has some drawbacks, in as much as guests can’t interact with the system or one of instant availability; for instance an always-on display á la the Sooloos. But, yes. A lock-screen is definitely an option.

1 Like

I have passwords on Fire Tablets that are only used for Roon. Guests get the password. The only software, besides the stock stuff, is Roon. Someone uninvited… the device is still locked. My devices, biometric locked, is stuff guests don’t get to touch. When you can get Fire devices for < $100 its an a low cost way to add some physical security by simply not handing my device to a guest.

WOW! What did I do???!!! I created a thread that spiraled into a great conversation about security. I love it! I’m glad to hear others are running complex networks in their homes. Heaven help my wife if something happens to me. She’s going to need to power everything off and just use the ISP router. LOL

Anyway - I got everything working! :smiley:

As it turns out, it was a configuration issue on the Palo Alto Networks firewall.

First - I tried building an Ubuntu Server and installing Roon Server - it made no difference. The behavior was exactly the same as the ROCK (Intel NUC). Any time I launched the Roon client, it was unable to detect the presence of the ROCK (or Roon Server on Ubuntu) that’s on my other VLAN.

I tried building a router running VyOS (Vyatta router) as it’s a great software-based router and supports IGMP + PIM, but decided to abandon that effort because I had a funny feeling I did something wrong on the Palo Alto Networks firewall. I figured it would be a better investment of my time to figure out what was broken, rather than waste time trying to set up a VyOS router, then go to fix my firewall. That was the right move…IMHO.

There were two separate issues:

  1. Multicast routing was missing some options
  2. A security policy needed to be added to allow traffic from the security zone where the ROCK lives to the security zone where the Roon Client(s) live

The initial design goal was as follows:

Place the Roon Core/ROCK in an IoT security zone (separate IP subnet/VLAN) from where Roon clients exist. The firewall rules/security policy should only allow traffic to originate from the zone containing Roon clients TO the zone containing Roon Core/ROCK.

Remember - stateful firewalls only require a security rule to allow traffic in one direction. The response from the server is expected and stateful firewalls will automatically allow the return traffic.

All of the following examples are from a Palo Alto Networks firewall running PAN-OS 10.0.3. This should also be possible with any version of PAN-OS starting with 8.1.0 but your menus may look different. When in doubt, refer to the Palo Alto Networks TechDocs for your version of PAN-OS.

The original configuration was set as follows:

Under Network -> Virtual Routers -> ‘default’ (or whatever your Virtual Router is named)
Select Multicast

I had Multicast enabled, but I did not have anything selected under Local Rendzvous Point -> RP Type

On the Interfaces tab, I added an entry called “IGMPv3_PIM” and checked to ensure that IGMP Enable and PIM Enable were both checked (this was done correctly)

Within the ‘IGMPv3_PIM’ option, I added both network interfaces (ethernet1/1.223 is in the zone where the ROCK is installed & ethernet1/1.224 is where the clients are - they are in SEPARATE security zones). I also added three multicast networks - 239.0.0.0/8, 224.0.0.0/24, and 224.0.1.0/24). It looks like having 224.0.0.0/24 and 224.0.1.0/24 were incorrect/unnecessary (especially in the case of Roon as the Roon multicast network falls within 239.0.0.0/8). The other two multicast networks were intended to support other applications. (PARTIALLY correct).

I also had a security rule that allowed ANY traffic from both security zones to the special reserved ‘multicast’ security zone. Even that was insufficient as another security rule was required to allow the ROCK to initiate connections back to the Roon clients.

NOTE: I provided the previous steps to document what I had earlier that was NOT working. Now…on to how I fixed everything…

For reference purposes:

Trust_Zone: this security zone contains interface ethernet1/1.224 and is where the Roon Clients live
IoT_Zone: this security zone contains interface ethernet1/1.223 and is where the ROCK lives (as well as other IoT devices)

  1. Deleted all of the previously mentioned Multicast configuration from the Virtual Router & removed the Security Rule allowing traffic from the Trust_Zone and IoT_Zone to the ‘multicast’ zone (a special zone that is pre-defined in PAN-OS - DO NOT attempt to create a zone called ‘multicast’)

  2. Committed changes - then ran the following commands from the CLI to ensure that all multicast routing entries were removed

show routing multicast fib
show routing multicast route
show routing multicast pim state

  1. Navigate to Network -> Virtual Routers -> ‘default’ (or whatever your Virtual Router is named) - ensure that both interfaces containing the Roon Clients and ROCK/Roon Core are added to the Virtual Router

  2. Select the Multicast tab

  3. Check the box to enable Multicast & choose ‘Static’ for ‘RP Type’ under Local Rendezvous Point, select one of the interfaces for the RP Interface (I chose ethernet1/1.223 which is the interface where the ROCK/Roon Core lives), then select the IP address for that interface which should be automatically populated when you click the drop-down select. Mine is an Address Object that I used to specify the IPv4 address on the Interface object (VLAN0223_L3_192-168-223-1–24 which equates to 192.168.223.1/24). Lastly, add 239.0.0.0/8 to the Group List

  1. Select the Interfaces tab and click Add. Provide a name (mine is ‘Multicast_Group’), add the two interfaces representing where the clients and servers live. Don’t add anything to either of the columns in the Group Permissions section

  1. Select the IGMP tab and make sure that the Enabled checkbox is selected

  1. Select the PIM tab and make sure that the Enabled checkbox is selected - then click OK to save that configuration

  1. Click OK again to save the changes you made to the Virtual Router

  2. Navigate to the Policies tab -> Security & add a new rule - provide a name (mine is ‘Multicast_Allow’). Leave the Rule Type set as ‘universal (default)’.

  1. On the Source tab, add the Security Zones containing both the Roon Clients and ROCK/Roon Core - leave the Source Address set to ‘Any’

  1. On the Destination tab, select ‘multicast’ from the drop-down select above Destination Zone. Leave Destination Address set to Any

  1. On the Application tab, leave the Applications set to Any

  1. On the Service/URL Category tab, change the drop-down select from ‘application-default’ to ‘any’ (the ‘application-default’ option performs additional protocol validation on traffic processed against the rule. If PAN-OS sees traffic it doesn’t recognize, or traffic on a non-standard port, it will be rejected/dropped. Leaving this set to ‘any’ will ensure that any proprietary applications or applications not recogized by PAN-OS are permitted)

  1. On the Actions tab, set Action Setting to Allow. You can choose Log at Session Start and/or Log at Sesson End temporarily while troubleshooting, but you probably don’t want all of the multicast traffic polluting your logs. That is your decision. I do not log multicast traffic.

  1. Commit your changes to apply the Multicast and Security Policy modifications

  2. Make sure that ROCK/Roon Core and a Roon Client are running on their respective networks - otherwise you won’t see the following networks registered!!! Open an SSH session and run ‘show routing multicast pim state’

  1. Run ‘show routing multicast route’

  1. Run ‘show routing multicast fib’

NOW - all is still NOT GOOD!!! The client will still NOT see the server! Why?

Let’s look at the logs - navigate to Monitor -> Traffic log

Here we see traffic from the ROCK to one of the Roon Clients dropping on the interzone-default security rule. NOTE - the intrazone-default and interzone-default rules have logging DISABLED BY DEFAULT! You need to enable logging if you want to see what the firewall is dropping. Use the Override button to accomplish this (refer to the Palo Alto Networks TechDocs for more details - https://docs.paloaltonetworks.com/pan-os/10-0/pan-os-web-interface-help/policies/policies-security/overriding-or-reverting-a-security-policy-rule.html)

This tells us that the ROCK needs to be able to initiate a connection back to the Roon Clients as opposed to the Roon Client only being allowed to connect to the ROCK. I’m not sure why this is, but it is. This requires we create a security rule to allow traffic from the ROCK/Roon Core to the Security Zone containing the Roon Clients. Once you’ve monitored your logs for a while, you can restrict the traffic down to only the ports required.

This somewhat breaks the overall goal of the design as we’re trying to ensure that NOTHING in the IoT zone is allowed to connect to devices in the trusted network. If the Roon Core were to become compromised, an attacker would be able to connect to devices in the trust network. The only option here is to restrict the attack surface as much as possible.

  1. Navigate to Policies -> Security and Add a new rule

  2. Specify a name - in my example I use ‘Roon_to_Trust’ and leave the Rule Type as ‘univeral (default)’

  1. On the Source tab, specify the Security Zone where the ROCK/Roon Core lives and select the Address object that represents the ROCK/Roon Core in the Source Address field

  1. On the Destination tab, specify the Security Zone where the Roon Clients live - you can restrict the Destination Address if you know which IP address(es) will be running the Roon Client - I left mine set to ‘Any’

  1. On the Application tab, leave it set to ‘Any’ as ther aer no App-IDs for the Roon protocols - you can create App-IDs if you want but that is not within the scope of this documentation

  1. On the Service/URL Category tab, change ‘application-default’ to ‘any’ as the Roon protocols are proprietary. PAN-OS will likely drop the traffic as it doesn’t recognize it. You can create Service objects for the layer 4 TCP/UDP services if you want, but that’s up to you. It is recommended that you do that - monitor the logs for a while to make sure you know which protocols/ports are used or refer to the Roon documentation

  1. On the Actions tab, set the action to Allow and Log at Session End

  1. Click OK, then Commit your changes

Go back to the Roon Client and see if it connects. BINGO! It works!!! MISSION ACCOMPLISHED!

*** Note that the ROCK is set to obtain its IP address via DHCP, but I have a DHCP reservation set for 192.168.223.104 for the MAC address of the Ethernet adapter in my Intel NUC. That way, I know the IP address will always be the same.

6 Likes

@moderators - if you would like, I can help convert this to documentation as opposed to leaving it stuck in a forum post.

2 Likes