I see the same behavior. I also get the same message, but I assumed it was because I turned off UPnP and deleted the port fowarding rule in my router.
Could someone clarify pleaseâŚ
I have ARC working via a Wireguard VPN and so far seems OK. However, Iâve seen posts on the forum suggesting this wont work in a reliable manner (thatâs my interpretation) because Roonâs servers (in the Googleâs Cloud AFAIK) need to communicate to my Roon Core for ARC to work correctly. Maybe I have misunderstood but many people seem to also be saying ARC works over VPN OK and Iâm assuming they dont have any Roon server addresses configured. I appreciate this isnât a supported solution.
Thanks
Hi Michael
I use ARC with TailScale and that works perfectly, so I see not issue with your solution.
If anything it is more reliable with TailScale than without and I have been playing music from the office all day today.
2 Likes
When ARC came out I wanted to try it out. So I set up the port forwarding and got ARC to connect after some hiccups on my UniFi Dream Machine based home network.
It only took a few days for attacks trying to exploit the opened port. And since I have Roon Core running on my personal MacBook Pro, I didnât want to risk anything and closed it never to use it again.
Did anything change from when ARC was introduced? Did the architecture so that the Core creates outbound connections/tunnels instead of a cloud-hosted server trying to reach my computer through an open port?
P.S.: When working with a team on cloud-hosted data services, outbound tunnels were the most secure thing that would be OK even for business critical data hosted in the cloud.
That long? As there are attackers out there routinely probing open ports on all visible devices, that is really expected, and of course, it doesnât necessarily mean those attacks are going to succeed. After all, the most secure system - even more secure than tunnels - is a brick.
Do you have all the IDS/IPS/DPI functions turned on in your UDM?
Yes, Iâd say yes. It is set to Detect and Block (i.e. IPS) with 10/11 categories turned on along with using their real-time malicious software database.
It is just that I do not trust Roon or the OS on my main computer to handle attacks from the internet on an open port.
Does Roon publish IP addresses of the Roon cloud servers somewhere so I could limit the incoming connections to an IP range? Keeping it open to any incoming traffic seems too risky to me. 
Roon Cloud servers supply the IP address of Roon Server to the ARC device.
Then the ARC device itself makes the connection, not Roon Cloud server.
I was talking about the firewall hole / port forwarding ARC wants me to create. I would be more comfortable leaving the port open if I could limit the IP range for the allowed connection to my Roon Core. As far as I understand, the architecture is such that the ARC cloud servers connect to my Roon Core after my mobile device connects to the ARC servers.
Yes, thatâs how I read your question.
I donât believe this is the case, afaik after contacting the Roon cloud servers to obtain the IP/Port of the user Roon server, the ARC mobile then connects using supplied info to the users Roon Server (or Tidal/Qobuz/KKBox servers) to instigate streaming.
It would be good to get Roonâs official comment on this so Iâll tag @support to see if they will provide clarification.
Thank you, @Carl. Didnât know the details of the architecture. If it would only my mobile connect then I could limit it to the range of the mobile provider IP range. This would definitely decrease the attack surface 
Unfortunately, both your mobile and Roonâs cloud servers may use different IP addresses from time-to-time â your phone uses GCNAT (IPv6) and Roon cloud, Google infrastructure and Cloudflare.
Although we donât know how the connection with your Roon server is negotiated, I doubt it is any less secure than, for example, an SSH connection that only allows connections using SSH keys*. Whilst you may see port scans on the router, the âdoorâ is firmly closed to anyone without the âkeyâ.
*Your mobile device is uniquely linked to your server when set up, and this can only be done inside your home network.
2 Likes
I disagree with this statement. I have reset and reinstalled Roon ARC while on a remote network on more than one occasion, as far as i know.
References to your statement? Or was this an assumption?
ARC is linked to your user ID and therefore your server, i.e., your subscription. Setting up ARC can only be done from your home network (I include automatic config here, too.)
But yes, if port forwarding is already set up, you can reinstall ARC away from home with a valid login (note that ARC doesnât request a password but uses secure delegation.)
1 Like
I understand what youâre saying.
But in the scenario when a user uses a router with UPnP Config enabled, shouldnât the same be possible? I.e. initializing Roon ARC from a remote network/WWAN?
Even when UPnP is enabled and successfully activated, this occurs inside the private network. ARC remote canât access the server without authentication and an open port, i.e., you cannot remotely open the port.
1 Like
This is getting into semantics Martin, if someone sets up a Roon Server on a local area network, using only Roon Remote and has got an UPnP enabled router⌠Can he/she not then, while on a remote network, download Roon ARC and initialize it?
This was what i objected about, as you state that it is not possible. And yet i have done that on several occasions.
Can we agree that Roon ARC requires either an UPnP or Port forwarding exercise on the local network, but attaching/initializing a remote Roon ARC client can THEN be performed on any Internet capable network or WWAN?
Both server and ARC remote have to have the same user credentials, and installing Roon server, including ARC setup, whether done manually or not, is a local-only activity. Account management is handled in the cloud (this is, in part, what I mean by delegation.)
Yes, you can reinstall ARC remotely and reconnect to the server, but this isnât doing anything from the outside-in as itâs already setup, and so are the credentials. Whatâs more, Roon already has two-way communication with your server and ARC remote, and doesnât need an open port for this purpose. However, ARC remote, which controls playback, recieves the stream directly from your server, and this is why a port is opened (itâs also why it works with Tailscale.)