Indeed. And security through obscurity is never reassuring.
Thatâs tinkering
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 34.73.75.215 and
35.190.182.123 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.
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.