Roon should create a steady secure tunnel instead of relying on port forwarding

You know, you can do this yourself. ARC works over VPN connections. So instead of forwarding the ARC port on your Roon server, set up a VPN tunnel and use it with your phone. ARC will work with that. Now the security issue is up to the VPN provider, which probably employs more security experts.

I hope that is a joke…

We are talking about consumer ready solutions. Those should be both easy and straightforward to use as well as being safe.

Another problem is that we do not know what kind of protocol is transported over this connection. It is an undisclosed protocol over TCP. Is it encrypted? Is it inside TLS? I did not find any information.

3 Likes

That’s wrong, but I will not get into details :slight_smile:
ZTN is an architecture, not a solution.
and this is an Audio forum :wink:

Another (more elegant) suggestion (which is one of the tools in the ZTN arsenal) and works with Ipv6 and Ipv4: use UDP pinholeing, like Teamviewer does :wink:

It is described here (for TeamViewer)

and in Wikipedia :wink:

@danny has said it’s encrypted. Various folks have snooped the wire and found out it is using TLS. True, it’s kind of hard to find out what “we know”, but it’s all out there.

TLS is nice, but doesn’t solve all security issues. Some questions that come to mind are:

  1. How are client connections to the Roon ARC server authenticated? It is very rare that this is done via TLS Client Certificates and is much more often done over TLS. But in such cases, TLS doesn’t prevent anyone from trying to connect to Roon via ARC.
  2. Are there any bugs or design flaws that allow an unauthenticated user from gaining access they should not have?
  3. Once they have access, can they use that to do things like run arbitrary code on my Roon Core?

This is probably a greater concern to me than some “bad guy” connecting to my Roon Core via ARC and then judging me based on my musical tastes.

Edit: Since Roon seems to run as root (at least on Linux), this is very non-optimal. Roon should be dropping privileges or running as a non-privliged user so if there are any bugs in the code, an attacker has a harder time causing havoc.

Danny, I can understand your perspective as an insider, but I’m one of the affected, and I think you are only seeing the tip of the iceberg. I couldn’t make ARC work outside my home network, and Roon help sent me to the UPnP guidance. That sent me Googling to find out what the heck that is. I have zero knowledge of networks and security, but immediately learned that there are security risks with UPnP and port forwarding. Equally important, I’ve not spent at least a dozen hours trying to understand the risks, how to implement if I decide to accept the risk, and I’m about out of patience. ARC is a consumer product at heart. I’m a music lover, not a network engineer. I don’t want to be suffering this stuff just to make an app work on my phone. I don’t have to do that with any other consumer product. I just want it to work, and Roon hasn’t accomplished that. No matter the numbers you have seen, there must be thousands of current and prospective Roon customers who will experience the same. So in my view, your current attitude will cap your market and customer growth.

1 Like

Roon ARC is a nice feature, but not necessary if someone is concerned about security. The method to make Roon ARC work is port forwarding. If you don’t get that automatically, you can do it manually as I did. It’s not really that difficult, but some people may need to get some help here or from an outside source.