Indeed. And security through obscurity is never reassuring.
Yes, if you run in Docker and a new port is exposed on Core you’ll need to adjust Docker configuration .
@Benjamin_Leggett - I agree. I work in InfoSec and I’m going to enable ARC. It all boils down to your own personal risk appetite - I’m OK with it, but some people won’t be, and that’s OK.
PS - I do recommend a password with at least 15 characters. I also don’t get hung up on the caps/lower/number/special character thing - a 20 character password with all lower case is MUCH stronger than something like “9*fGlyz”!
PPS - I just set it up and it’s damn amazing. Great job, Roon!
It’s a bit more. Everything goes out over VPN now. I have to give the Roon image a separate IP so I can force all traffic out over the normal PPoE interface in pfSense. NAT doesn’t work very well when the outgoing and incoming interface are different.
I have used the IPAM-driver on a few Debian machines but now I have to use it on QNAP, something I always tried to avoid.
I’m leaving the UPNP Port open too. For those who don’t want to leave the port open:
Navigate to settings > Roon Arc
In the port section enter “0”
Then use Tailscale or ZeroTier (A VPN Solution) to use Roon ARC instead.
One thing I don’t like about the current implementation is that Roon currently seems to respond to random probes on the forwarded port. Other services I on my network do not respond unless they receive legitimate traffic so it isn’t obvious the port is open.
I would prefer if Roon behaved the same way. Unless it receives a packet that has the right credentials then it would not respond and someone randomly scanning ports would not know what port to try and attack. Currently it does not work this way according to GRC Shields Up.
Not for local LAN use of ARC. (Use case: I have poor wifi in the garden, so the regular remote doesn’t get sufficient bandwidth. ARC is just fine with reduced bandwidth settings over wifi)
And for remote access, you don’t need UPnP enabled, either. Just configure the port manually on the router
Is it just tcp or some surface iodine too…
I’d get some super glue on it…
can you give us the IP address(es) that connects to the core server
or dns names
to secure incoming connections
I noted these two addresses 184.108.40.206 and
220.127.116.11 but maybe another
Your phone connects directly to the Core, so that will change
i’m not talking about the phone
the core to activate arc communicates with an external ip
At that point you could just use it for the normal Roon app.
Yes, just saying that some of the external IPs or DNS records for activation and stuff may well be quite stable, but if you want to “secure incoming connections” the phone is also one of those
Normal Roon app cannot handle interruptions that occur with mobile connections. Hence one of the reasons why Roon ARC exists.
I abolished port forwarding in my network already for some time, by using VPN solutions, for having better security. It is disappointing that Roon didn’t come up with a better and safer solution than simple port forwarding. Roon: Please enable use of Roon ARC via a VPN network.
PS.: Roon ARC works via my Wireguard VPN! Great! No port forwarding needed except for the inherent port forwarding for the VPN server.
These are Google Cloud IPs. I don’t believe the way Roon is built inside Google Cloud they “own” any of their public IPs so expect these to change. However, they would change within Google Cloud public IP ranges within the region(s) Roon is deployed. This would need comment from Roon Labs if you wanted to narrow to this range.
As @Rugby pointed out, using VPN doesn’t even require 2.0.
How does Roon verify the connection ARC is working please? Can I limit ingress traffic to my home country, eliminating 98 % of the portscans? It seems to work now, but will it break after some time?
the traffic will come from your phone and from our servers, which are placed all over the world.