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

Dear Enno

We never met in person: I’m Stefan - an enthusiastic Roon customer - trying to help users get arround networking problems related to ARC.

The following post (see my comment within the post below) hopefully landed also on your desk.

Roon users are mostly overwhelmed about the required networking skills they would need. I personally (as an Engineer working for a big tear mobile operator) believe, the connectivity architecture choosen for ARC is not suitable at all for the majority of your users. Hence, the setup experience might destroy the good functionality of ARC in all respective domains. A kind of sxxx-storm is for me foreseeable at the horizon.

Don’t you think, Roon should stand-up and stop the mess around ARC?

To give you a bit of high-level perspective on the ARC connectivity miss-conception:

(1) ARC connectivity setup based on UPnP: many users (including me) don’t trust the choosen implementation on their router and hence, disabled this function;

(2) ARC connectivity setup based on automatic Portmapping: many legacy routers (equipment provided by the ISP to their customers) do not support this;

(3) ARC connectivity setup behind a double NAT calls for port-forwarding rules in routers and/or firewalls. Evenmore, Roon recommends (I guess due to simplicity) to put one device in bridge mode, which may cause troubles on services others than Roon such as IP-TV etc.

Out if this hurdles, some Roon users start to place the core into their DMZ, which is, frankly speeking, super-stupid and very un-secure.

If you want simplicity and security, a solution where the core establishes a steady secure tunnel to your infrastructure might be the way to go. However, this will be at expense on your datacenter side.

Kind regards


I fully support

This was already discussed in the early access program.which you could have participated in if you so much want to help Roon.

Roon’s CTO addressed the alternative briefly here.

Roon are well aware of the issues you raise. Significant effort was put into resolving as many of the port forwarding issues as possible during testing. Hence all the deaths led instructions and links on installing ARC. Sadly some ISPs do make this difficult.

Some users are struggling but given that there are over 100,000 who have installed ARC already the number posting here is quite small and does not demonstrate that

Your letter makes hyperbolic statements like this and states the obvious in many others. What decision would you have made as CEO? Would you have made your customers wait even longer for a mobile solution or gone forward with port forwarding?


+1 Actually, I am a software engineer concerned with network ‘stuff’ among other things, and I don’t get ARC running, because network configuration is notoriously obscure. I also strictly followed Port Forwarding Instructions for (Most) Fritz!Box Users, incl. the remarks on repeaters at the start. Repeaters even caused me troubles re. Roon Remote more than a year ago.

1 Like

Rather than enable UPnP, I instead VPN into my home network on my phone, and then streaming and syncing of music works great. There are lots of VPN options out there that folks can use if security is the concern.


As CEO, I would have challenged the value proposition against the technical implementation and the usability, and decided with my team and test-customers, if the product might become successful or not.
If you don’t follow such principles, then you earn what so many folks write in the support forum about horrible problems, which I’m convinced from a architecture point of view, could be circumvented. You don’t need an university degree to understand, what I write on your comment, but many of Roonlabs customers might need one to get ARC up-and-running.

Hence, find the error.


Why does the forum admin changed my title?

1 Like

I would like to add my support to this. My ISP has CGNAT and although services like Plexamp can cope with this ARC cannot. A secure tunnel would seem to be the ideal solution for all users.


Roon could even implement a split between user- and control plane. Hence, all synch traffic belongs to control plane going to roons datacenter, while user-plane traffic (streaming content) goes directly from the core to the mobile device;-)

1 Like

Roon doesn’t need to re-invent the wheel. Use Tailscale. It works today with ARC. It’s easy to use, secure and reliable.

And you get the additional benefit of having an awesome VPN wherever you go. Maybe you want to access other services on your home network? Or maybe you want to run a Pi-Hole for ad blocking? Well now you can get ad blocking at home AND on your phone no matter where you go. It’s awesome really.


Basically, I’m with you as I aswell operate my own VPN at home. However, if you can show me 80 out of 100 paying roon-users being able (and willing) to install and maintain your proposed approach: I’m all-in with it. But: I doubt you’ll find them. I think, Roonlabs engineers are smart guys already challenged such an option.

When paying USD100 YoY for a service subscription, a customer can expect a fully working appliance without having the hassle of installing & maintaining 3rd party software.

In your approach, I see another disadvantage (at least for Roonlabs): having just one pipe towards roonlabs datacenter, will cause Roonlabs to pay for the streaming traffic. Remember: someone has to pay the payload;-)

Hence, traffic split between UP und DP would make sense technically and commercially and is not about reinventing the wheel :wink:

The debate is open.



No, there is no need for a “big pipe” to the Roon datacenter with Tailscale. Each Tailscale node creates a direct connection to each other for transferring data- even if both nodes are NAT’d and do not have UPnP enabled. It’s basically magic.

But that’s the thing… Tailscale is networking & security magic. And I don’t expect the people at Roon to be experts in the voodoo that the Tailscale developers are to re-create it. Which is why they used industry standard protocols like UPnP which work well most of the time but are not awesome by any means.

I think Roon is correct though that the vast majority of their customers will happily ignore these security concerns and enjoy the Roon experience on the road, at work, etc. For the rest of us, we’ll do the needful and configure VPN’s or whatever.

As someone who has helped many people listen to Roon remotely in the pre-2.0/ARC world: I believe that ARC+UPnP is sufficient for most Roon users. For those who are more tech and security savvy, they’ll continue to hack things with various VPN solutions- but it will be easier now. I still see people talking about using OpenVPN with ARC which IMHO is just insane, but people will use whatever the path of least resistance is I guess.

I should mention there is a very good reason why Roon did not go with a VPN technology for ARC: iOS only allows a single VPN to be active at any given time. So anyone who wants to use a different VPN (for home or work) would not be able to use RoonARC at the same time and have to deal with constantly switching between VPNs. That IMHO would be a far worse user experience.


Great discussion Aaron, thanks!
You touched a field (VPN config inside iOS), I can’t further argue as I’m lacking of expertise here. However, for me it is not about having global VPN settings in iOS. This would be the wrong way. Tunneling and security must be handled inside the app itself. Whether this is allowed from Apple et al. I don’t know. Maybe someone else can enlight me here.

Roon could implement their own “tailscale like” architecture. The way tailscale gets around NAT and discovers public IPs is all open source libs and baked into the web standards. However, troubleshooting it is a bit of a bear.

It’s also a large leap from what they accomplished in 1.0. I suspect ARC would have seen further delays had they tried to do this day one. But, I think its worth investigation for a next-gen ARC architecture.


This is how modern VoIP protocols work. They use a similar discovery to tailscale for peer-to-peer secure communication. So, yes, its all available to do this inside the app even if you’ve got an active VPN profile running.

You should think of it as a very limited scope VPN or secure tunnel used by a single application for peer-to-peer communication. It is brought-up and torn-down only as the application needs it.


@Aaron_Turner @ipeverywhere thanks for pointing me towards Tailscale. Love to deep dive their solution which I was not aware off til now;-)

Personally, I would have held out for a “solution” that sync’ed playlists to the mobile device along with appropriately lossily transformed (with the user allowed to choose an appropriate transformation) versions of the tracks in the playlists, and would not require an Internet connection to play them. After all, it’s a brand new mobile app, it could have done anything. I’m sure that there would also have been complaints about that approach.

I’m OK with what Roon decided to do. It just not what I wanted as a mobile solution. And it seems almost pointless given the prior existence of VPN tunnels, which achieve pretty much the same thing. Perhaps it’s a step toward a more far-reaching transformation of Roon that we don’t know about yet.

@ipeverywhere – you and I had this discussion already here:

Brian chimed in with more however, you may have missed it:

to reduce the soapboxing and focus on the meat of your message.


Hi Aaron, Is it possible you could elaborate on how this works?

I have a CGNAT and a USG3 router, I’m fairly technically capable, how do I utilise the magic that is Tailscale?

To @danny and @ipeverywhere
I need to challenge this a bit;-) because: if I look back, how Roonlabs marketing department advertised (I tend to write: hipped) the new version with words like: “our biggest and most revolutionizing update ever”. Then expectations are set high and you need to deliver!

The technical implementation followed by the massive troubles caused on the user-side are not inline with what marketing promised.

When I then read, that some of you guys have already talked about those problems, why the hell does the company release such a complex ARC product? Some useres were claiming they wait since years for this functionality -we can challenge this on a separate debate- why not making it right from day one, even if it take some month more?

With such problems on launch, Roonlabs may face the risk of loosing credits in its community. And that hurts me, because I’m a big Roon fan!

First, let me acknowledge that you and everyone here at Roon Labs are in agreement that everyone who had problems is important and we’d like to see the number of people who have problems as low as possible… even zero.

That said, you seem to be guessing incorrectly on the scale of things.

We are seeing over 100k ARC connections up and running as expected, and this forum has a few hundred complaints.

We see more non-working ARC router configurations outside the forums, but the number still puts a success rate of greater than 99%. Even the number of users that have switched to 1.8 Legacy is measured in the low 100s of users, and those are mostly being driven by older operating systems that can’t be updated.

I think your goals are correct, but I absolutely disagree with your interpretation of the situation. But then again, I have the advantage of seeing the big picture.

I have to ask, were you personally affected or did your situation go smoothly?