Problem: is ROON OS 1 as secure as V2 and if not should up upgrade?
My Intel NUC I5 2.3Ghz works just fine but appears to receive few ROON OS upgrades - its currently on ‘Version 1.0 (build 259) production’. My understanding is that this ROON OS V2 is available but as my hardware does not support newer features I will not receive new ROON OS updates. (with the possible exception of critical updates - although I can’t find that written anywhere).
Roon OS 2 appears to be based on a later version of Linux core and therefore is inherently more secure IMO.
One reason I bring this up is that I see several intrusion attempts due to port 55000 being open for ARC. Although thats not necessarily going to cause problems it is inherently more risky than not having the port open - and I am concerned that Roon seems to be leaving Roon OS 1 to languish.
Can I force a V2 upgrade and would that really help?
I am thinking that maybe I should move Roon Server to something more in my control. Your thoughts.
Roon OS 1.0 build 259 is currently the latest version of RoonOS that can be run using Legacy BIOS boot.
To run Roon OS 2.1, you will need to have a UEFI boot NUC. The NUCs that are currently stuck on Roon OS 1.0 use the legacy BIOS boot. However, many of these NUCs can be set to use UEFI boot in the BIOS. I beieve that 5th generation and later NUCs can all support UEFI boot (although for some early NUCs (7th gen and earlier?) it would be advisable to make sure that the BIOS was up to date before changing the boot method.
If your NUC supports UEFI boot, you can ‘reinstall’ ROCK to get the latest version of Roon OS (after doing a database backup) by setting the BIOS to UEFI boot and then reinstalling RoonOs from scratch. The installer may not install the latest version of RoonOS but once installed, you can use the WebUI to ‘reinstall’ RoonOS and it will install the latest versions of Roon OS and the Roon Server application. Once that is done, you can restore your database from a backup and you should be good to go.
Having said that, other than the potential to have more recent versions of the kernel and included packages, I don’t think that there is much difference between Roon OS 1.0 and 2.1 security. The obvious difference is the support for Tailscale as an alternative to port forwarding. However, neither version employs a firewall. By default, the Roon Server application will still listen for ARC connections on port 55000 (or what ever is configured) and so this port will still be open.
Roon has always relied upon the gateway device (the router) for security and assumed that the local network does not have any bad actors.
On both versions of Roon OS, you can stop the Roon Server application from listening on port 55000 by setting the Roon ARC port number to 0. On RoonOs 2.1, you can still connect ARC using tailscale when the ARC port is set to 0.
FWIW, I always ran on ROCK, because it was the simplest, and I’m not very smart, or at least I generally like things that just work.
Recently migrated the same several year old 10i7 and 8i5 to Ubuntu server (with a lightweight xfce install so I can run HQPDesktop as well), and it was shockingly easy and thus far (knock wood) just as stable. Also running HQPDesktop on both of those machines, and Plex Server on the 10i7. A person who used to mess around in the computer lab in college + ChatGPT can get stuff done.
I by no means am recommending this to those who don’t know what they’re doing, but if you do know what you’re doing, and I’m guessing you know far more than I, it’s much less painful than I thought it was going to be, and far more flexible in terms of using things like rsync, keeping machine patched, netdata, all that stuff. And seems just as performant (no reason it shouldn’t be, obviously). I also closed my ARC port and my Plex port, and now just use Unifi Teleport to access those tools. You could use Tailscale or whatever floats your boat.
[I always fear I’m going to suggest this and someone will get annoyed at me for leading them down the garden path of “it’s not that complicated” when in fact it is somewhat complex. YMMV]
My understanding of this is that the 2.1 version was created purely for the later NUCs that no longer offered the legacy boot in the firmware, so Roon created a UEFI boot version & named this “RoonOS 2.x”
This version also has the Tailscale option.
The ‘core’ Roon functionality offered is identical, and if Roon and ARC are all working fine, there is no real advantage or reason to re-flash a NUC built with a legacy boot process.
Oh bad actors will find any open port. Scans are cheap when you have distributed resources. Mine (my ARC port) was something random for a long time, and I changed it around a few time s, and Unifi IPS was frequently warning and blocking. Teleport VPN ftw.
Not quite true. Builds of RoonOS 1.0 (including 259) support UEFI boot as well as legacy BIOS boot.
Support for UEFI boot was added in Roon OS 1.0 (build 254) in Nov 2022. See:
Support for legacy BIOS boot was dropped in RoonOS 1.0 (build 261) in Jul 2024. See:
Thus ROCK installs on modern NUCs done between November 2022 and July 2024 would originally have had one of the Roon OS 1.0 builds installed but may or may not have been upgraded to Roon OS 2.1 depending upon whether they were installed using legacy BIOS boot or UEFI boot. Those ROCK systems using BIOS boot, will only update Roon OS to build 259.
Correct on both points.
Essentially correct - but some people may consider the use of Tailscale to be more secure than using port forwarding and may thus wish to migrate to UEFI boot if their hardware supports it.
But, from these release notes, it is stated
" There is no practical (or audible) reason to change from legacy boot to UEFI so there is no need to worry about which mechanism your existing device is using."
And “However, there’s no need for concern if you have an older ROCK installation, as the update is specifically designed for newer hardware capabilities introduced in Build 254.”
So as a user with an older ROCK installation on a NUC7i7DNK (the same board used in a Nucleus+ Gen B), created using a Legacy BIOS boot, which was the only mechanism at the time of installation, I see no reason to revise this.
Nor I believe should the OP worry about this.
Particularly based on the release notes here
and the comments
“version 2.0 should have been the UEFI build, but it wasn’t. We’re correcting that now with this update. If you want to think of a 2.0 version, consider builds 1.0.254 to 1.0.261 as 2.0 (builds 254-261).”
So the version “Version 1.0 (build 259) production” running on my NUC is RoonOS 2.0
I would be interested to determine what Roadmap exists for RoonOS and ROCK installations, as there has not been a release since the Tailscale release of Sept 2024
I am not sure if I am supposed to reply to my own post but as this gathered several replies I think this may be the fastest method:
First of all thanks everyone for taking the time - your comments gave me some ideas and solidified my thinking so here is the outcome:
I am closing port 55000 on my router as its just another small nuisance and unnecessary risk (all be it small).
with the port closed I will use my own Wireguard VPN (which I need for other purposes) to pierce my firewall. In my case its free with my Ubiquiti UDM gateway - ARC ran fine with Wiregard VPN and I will modify my IOS shortcut to turn on the VPN when I connect to my car where I use ARC. Tests out fine.
as for the NUC - in the longer term I will upgrade it to UEFI boot (which I believe it supports) and then to OS 2.
Overall my experience with Roon OS has been good and in my case performs as a maintenance free appliance which works well for me.
There were a few comments suggesting that the port number be changed, that won’t do anything as a port scan will pick up any open ports. Other comments questioned whether the underlying Linux was different between OS 1 and 2. It looks like R OS 1 is based on Linux 4.14x and OS2 5.10. Evidently its possible to SHH into it but I didn’t verify, however if correct I would see this as significant re performance of Network components, patches for security and stability. I do know one thing, staying current is a good place to be so I will make the leap.
For me Roon overall has been an off and on project trying to squeeze more sound quality out of it and its been relatively reliable given its complexity. I think ARC has been more trouble than any other aspect of the product but since my ARC config was is a ‘stable state’ I ignored Tailscale simply because I didn’t see any need to investigate. The replies from this post re Tailscale got me thinking about VPNs so I tested ARC with my own VPN from my car to the house and it works fine. I think Roon articulate this point better although I will admit to be a bit slow with that one.
This all started when I turned on Firewall intrusion detection on my Firewall - Roon pops up with several points of interest. Thats not to say Roon is doing anything wrong but I did move it to a more secure VPN (despite Roon stating not to) to better isolate it and now am turning off the ARC port. I also turned off UPnP years ago - Roon should not be telling folks to turn that in IMO for security reasons.
So to save money /effort / headaches I will stick to my existing NUC till something else dies or becomes obsolete on it - just keeping it current.
Nobody knows what is going on in Rock since the developers hacked the OS to bare minimum for some reason. They took out all the diagnostics and maybe much more, how would we know.
There are many very good versions of Linux that will sound the same and give you full functionality of Linux: security, diagnostics, and if a gui if the owner requires it.
Nobody should use the default port forwarding address for arc.
