If being behind a CGNAT (which is probably the majority of users these days) prevents ARC from working and there is no solution, then Roon is at fault. Trying to get this app to work reminds me of the early days of PCs, when you had to spend hours to figure out the simplest procedure. I have my Roon server on a Windows Surface Pro and it works flawlessly. I would really like to have the ability to use ARC but telling me I can’t unless I purchase a dedicated IP address (for which my ISP wants $40/month) is totally unsatisfactory.
2 Likes
If you have a computer or Raspberri Pi to run it on already, you can work around this with something like Tailscale for free: Tailscale implementation with ARC to circumnavigate ISP CGNAT
…and gaming consoles etc.
This is exactly my point. I just want to listen to music, not become a networking expert.
1 Like
But you can still listen to music with Roon 2.0 just like you always have done. CGNAT only affects the new additional (and very wonderful) Roon ARC, which gives us access to our Roon environment from anywhere. Unfortunately if you are in the minority of users whose ISP use CGNAT, then sadly you need to take additional measures to get it to work.
This is hardly Roons fault, to engineer a workaround to the issue built into Roon ARC would probably have caused significant delays to releasing Roon ARC and the effort may not be worth while as hopefully CGNAT will be a diminishing environment, and for business reasons releasing a working service to the large majority is deemed the appropriate thing to do. Especially as there is a way around the problem if you want Roon ARC with CGNAT.
Sometimes if we want something, we have to make an effort, embrace it as a new learning experience maybe?
2 Likes
A Roon mod said exactly this in another thread. Look, I know it’s really frustrating that it’s not as simple as you flip a switch and then ARC works for everybody. I’m in the same boat myself (CGNAT with Starlink). But you have to understand that networking is really complicated, and it gets even worse when you throw the internet into the equation. There are a lot of things, like CGNAT, that are outside of Roon’s control, and it’s not trivial to engineer around all those configuration possibilities. Especially on top of all the engineering they have to do to get the whole ARC system to work well in the first place. We probably wouldn’t have ARC for years from now if they had decided to try to implement some sort of VPN or relay system into ARC that could navigate between all the various internet and network configurations people have. It’s unreasonable to expect them to do that, especially in a v1.0 release. They’re not streaming to you from a publicly accessible system like Qobuz or Tidal (not directly anyway). They’re connecting you to your private core in your home. That is a very different beast. And also like @Edmund_Comber said extra especially when there’s a free, well established solution to work around it. Why reinvent the wheel when someone’s already done it? That’s neither a good business decision for Roon or a good use of their engineers’ time. Yeah, it takes some time and effort to get Tailscale up and running. But you only have to do it once. And after that it really is as simple as flipping a switch to get ARC to work with your setup.
1 Like
Everything said here is well put and I don’t disagree with it. But honestly, this is beta software and to promote it as anything more than that is unfair to users who, for whatever reason, don’t want to, or don’t have the time to make the effort. What happens is that the excitement is generated and then after hours of tinkering with not only Roon, but every other piece of new or upgraded software out there, a sense of exhaustion sets in. That’s where I am right now.
Not at all. The vast majority that have run ARC got port forwarding working automatically. Only a tiny minority have had port forwarding issues.
Support for IPv6 in the ARC connectivity would help people stuck behind CGNAT.
You’re assuming that the ISPs universally support IPv6.
It’s another wild assumption - such as the ARC implementation relying on port forwarding without an ability to specify the public IP.
It doesn’t matter how it gets skinned, it’s a poor implementation
I am new to Roon and such an approach is a disappointing insight.
I get why it’s done this way - to make it simple for users. But the approach is flawed and ignores modern ISP network design approaches.
1 Like
I second this. I nearly called all ISPs available in my aera today and none of them could offer me a plan without a shared public IP (I put it this way because starting to talk NAT on the phone with those people is a waste of time).
It’s probably been said elsewhere but Roon Arc I think would be better to be sold as an add on extension. I have CGNAT implemented via my ISP and whilst I have ARC working via Tailscale , it’s not a solution for everyone, it needs at least basic network knowledge to implement. Plus the combination of Tailscale and Arc on iOS is heavy on the battery usage, thus you have to force close Tailscale to preserve battery life. I suspect once the novelty wears off I’ll be back to Tidal for mobile use- which is completely hassle free
Hello Danny,
What is a tiny minority? Can we count and define the exact percentage? I think it is not helpful (in both directions) to use such „undefined“ statements.
BTW, I cannot use ARC either and this is not the fault of Roon, it is because of my provider setup. For me it’s not critical, I use Apple Music or Qobuz in e.g. my car.
Kind regards
Tom
1 Like
I managed to get it to work without installing a VPN client on my mobile device. I do have an OpenBSD router that is capable of doing sophisticated routing and has a Wireguard VPN open to a cloud server I rent on Vultr to get a static IP.
The trick was to ensure all traffic between the Nucleus and the two hosts porttest.roonlabs.net and push-connector-v2-0.prd-roonlabs-1.prd.roonlabs.net are routed over the VPN, and of course to have the VPN port-forward the chosen port over TCP and UDP to the Nucleus (not sure if UDP is really required, but it now works so I am leaving well enough alone).
I agree Roon should redesign the network connectivity component of ARC. Too many assumptions embedded that are no longer valid in this era of CGNAT. They could look at how magic-wormhole is implemented, for instance, or WebRTC.
1 Like
Hey, very interesting, thank you. Any chance to get your wireguard conf files as an example?
It’s OpenBSD so I am using the kernel WireGuard implementation.
In any case my setup needs more work, as I am getting inconsistent results, seemingly dependent on what CGNAT gateway is being used. On my iPad mini using Three 5G, it works fine, but on my iPhone 12 using EE 5G, I keep getting the “poor connection” message. It may be something screwy with my phone or a bug in the Roon ARC app as it fails even when I am on the same WiFi network as the Nucleus.
Definitely a bug in Roon ARC. Deleting the app and reinstalling it fixed the error message.
This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.