Sorry I know this has been up in the air a couple of times already, but from the other topics I’m having a hard time figuring out, if Roon 2.0 has made any changes to this.
Been wanting to enable ARC while still maintaining a fairly high level of security in my network, thus I decided to setup a DMZ vlan (192.168.4.0/24) in my network where my Roon Core (NUC) was suppose to be. All of my roon endpoints I planned should stay in the main vlan (192.168.1.0/24).
But after having moved the Roon Core from the main vlan to the DMZ vlan the core can no longer access my roon ready/tested endpoints. I’ve disabled all rules in the Unifi DMPro firewall I’ve configured to restrict inter-vlan communication, but still the roon endpoints do not show up.
So unless there is a fix in either roon or unifi which enables what I would like to accomplish I guess the only possible solution is to ensure that all the roon endpoints are on the same vlan as the core - maybe on a specific vlan, but that would also mean that all the endpoints will be on the vlan which will be accessible from the internet, as the core needs to be accessible for ARC to work; yes, I know I will only open for access to the core, but still. I’m having a hard time evaluating if the roon endpoints are secured enough to be “put on the spot” in this setup?
That is correct.
The Core, clients and endpoints need to be in the same collision domain to comply with the Roon best practices, aka to work.
If you do not want to expose the ARC portforward to broad, you could allow only certain networks you use to use the ARC port.
I just open my ARC port when i need it, but logging shows no real threats when opened.
With tinkering you could make the Core discover endpoints on another collision domain and clients to use the Core. This can work if you use a router that allows for «some» tinkering but YMMV.
Is the above worth it?, not for me, it is APITA…
There’s a way to make this work by enabling UDP on port 9003 to traverse the vlans (see the wonderful work done on the thread below), but it’s not for the faint of heart. You don’t sound faint of heart, so may be worth it for you. Not for me - I use UniFi remote config app to close down the ARC port when I’m not using it for a while, and deal with the security risk the rest of the time.
Here’s what it’d take.
I should mention that I am still pursuing this solution for a different purpose… I’m trying to create a site-to-site vpn so I can run two homes from a single core, though I have relatively low expectations that it will work flawlessly given how network sensitive Roon is. But I’m stubborn, and I hate having two cores and the resulting backup/restore mayhem. But for ARC since there’s a simpler solution I deal with it. Perhaps inconsistent, just want you to know why I’m active on that thread.
Thanks for the heads-up @Johnny_Ooooops - I think this might be too far for me … at least for now. I think I’ll wait until Roon provides support for different vlans.
You’re adding “security” to your network without understanding some of the attack vectors / surfaces used to breach that security. This can make you more vulnerable than just sort of leaving things alone.
“Roon” needs to be on the same broadcast domain. Now, this means 2 things depending on what network layer we’re talking about. Ethernet has a broadcast domain and IP has a broadcast domain. On top of that, Roon also utilizes multicast. All of these things can be made to traverse both ethernet domains and/or IP subnets. But, allowing that to happen, in my opinion, removes and security you thought you had in place by separating them in the first place. Separate things into their own corners of the network: Good. Breakdown that separate to make things “work”: Bad.
So, let’s talk about ARC as an attack surface. Let’s say, and this has not been proven in anyway to be true, that ARC is vulnerable. An attacker gains access to the Roon Core by exposed ARC port. In your 2 subnet “working” scenario the attacker also has access to everything the Core talks to (all your endpoints) because you had to leak broadcast traffic (visibility to the other network) and various ports for the 2-way communication. You might only be slightly safer as you’d probably shutdown common service ports like 22, 80, etc. But if the is a vulnerability in ARC then there is probably vulnerability in things like RAAT, or Airplay, or some other thing you’re leaking. All the extra work you did to put things on 2 subnets in the name of “security” kind of goes out the window. And, honestly, if you’re monitoring such attacks they are happening without you knowing no matter how many subnets you have.
But, let’s go back to the original problem… You’re wanting to use a non-standard configuration because you believe ARC is an attack surface. So why then would you expose ARC? Use a VPN. Something like OpenVPN or Tailscale. VPN into your home network and use ARC that way. This actually works great. Your Unifi DMPro already supports a couple different VPN solutions. Just give it access to ARC port on the “Roon” subnet and you’re good to go. Your attack surface just moved from ARC to whatever VPN you decide to run on the DMPro (which, has more users / exposure than ARC so is “probably” better hardened).