Security with Roon ARC / Roon 2.0

This is exactly what I’m refuting. It is my opinion that disabling UPnP does not actually prevent any “escape” routes. It’s purely theatre and actually impacts no nefarious software in any meaningful manner.

You mean the same providers that introduced the buggy/exploitable code in the first place, or are there others with reasonable implementations that also recommend this? And if so, who and what is their reason for such a recommendation?

While I’m a fan for knowing more about how things work, it is completely unnecessary in this situation to achieve safe success. You’d have to work hard to create a security issue here. It’s not going to happen by accident. If someone believes otherwise, I’d like to hear in explicit exploitable detail how that might occur. I’m genuinely curious so we can update the docs and help-guides to help future users avoid such actions.

I agree with almost everything at a high level (I disagree about antivirus) in this guide. It’s a realistic guide to what you can do to reduce threats.


Summarised as: always use unique strong passwords, keep all soft/firmware up to date, delete any apps you’re not actually using.


From that CISA guide:

  • Disable Universal Plug and Play (UPnP) when not needed. UPnP is a handy feature that allows networked devices to seamlessly discover and establish communication with each other on the network. However, though the UPnP feature eases initial network configuration, it is also a security risk. Recent large-scale network attacks prove that malware within your network can use UPnP to bypass your router’s firewall, allow attackers to take control of your devices remotely, and spread malware to other devices. You should therefore disable UPnP unless you have a specific need for it.

What I understood – and I’m no IT security expert – about disabling UPnP: it should be done because especially with IoT stuff there’s always a good chance implementations may contain known as well as unknown security related deficiencies and / or backdoors; the latter may be there by design or by accident. Getting support and security updates for IoT devices isn’t a given either.

Recommending to enable UPnP without knowing what else is operated in a particular home network seems like a risk I would not take. Especially when experts seem to believe disabling it is the SOTA approach.


Roon security bounty, Roon Red Team.


It seems pretty simple to me. When enabled, the malware can configure port forwarding, so that someone from outside can enter the network via that port. When disabled, they can’t use upnp to configure port forwarding. Are there other ways? Sure, but it’s one less.

I would say literally all the big corporate network vendors. I’m sure you know them. They have reasonable implementations as far as I can tell, and I’ve stated the reaason just above. Maybe we just have to agree to disagree, but aluding on their buggy / exploitable code, seems a bit lame. I would never have brought it up, but since you opened that gate, I dare say Roon is not without bugs either.


They suggest this because they don’t want a corporate employee to open ports into the corporate network. Not because of malicious software. Malicious software that relies on port forwarding wouldn’t be very effective. Many of these vendors don’t even support automatic port forwarding configuration. Example in the SOHO space: UniFi EdgeRouters need extra addon software to do it.

Again, because of the exploitable nature of poor implementations, not because they will open random ports inbound.

I think the critical piece people seem to be missing is that it is not hard for a malicious piece of software to tunnel in traffic without port forwarding at all. This was demonstrated at scale with Back Orifice back in the late 1990s, and the ease of implementation as well as proliferation of this type of code has made it quite widespread.

Great example of why one shouldn’t talk about security without expertise. Most IoT devices have mechanisms for tunnelling in traffic without port forwarding, but no one talks about them (outside security circles) until they go awry. There was quite a fiasco with the first generation Wyze cameras just recently.

Turning off a mechanism to make port forwarding easier will only make it more difficult for legit software. It won’t do anything to the malicious software. At best it’ll give you a sense of false security.

If Roon had access to a good cross-platform QUIC implementation, we’d skip the port forwarding completely. It’ll happen someday, and when that happens, we’ll be able to get through routers without any configuration, UPnP/NATPMP/PCP, or manual port forwarding. One less thing to configure or worry about, and an overall better experience.

The malicious software out there doesn’t have requirements like we do, and is not hindered by you turning off support for UPnP/NATPMP/PCP.

An example of legit software that uses the above QUIC technique is TailScale. They have zero issues getting through your router. they can afford to do this because it’s a core part of their value proposition. If we went down this road, we’d be releasing ARC a year later than we plan to.

Because we prefer users to have a good experience out of the box, we will move towards mechanisms that avoid all this mess. I predict in a few years, there will be very little software being built on TCP, which should also eliminate this entire class of configuration. The mass adoption of HTTP/3 will be the final nail in the coffin of TCP.

Our advice is to turn on UPnP for a good experience or set up manual port forwarding if you can’t/wont, and none of this will matter later on.


@danny random thoughts / questions

RE: QUIC / TailScale…
Could you hack-up the Chromium (not Chrome, but Chromium) code to make this happen? It supports WebRTC which means it implements ICE and will return everything you need to then establish a QUIC transport between Client / Server including opening WebTransport via the Chromium code to facilitate API calls / streaming. You can also combine this with RTCDataChannels for peer-to-peer stuff. I assume this is what TailScale is doing based on initial read of their overview architecture. There is even some work to make the RTCDataChannnel do it’s peer-to-peer set-up but then use quik as transport. (RTCQuicTransport Coming to an Origin Trial Near You (Chrome 73) - Chrome Developers)

You’d need infrastructure to tell both client and server to go initiate a connection towards each other but you already have that. Won’t be 100% without TURN but it will may very will be closer than port forwarding.

Appreciate your feedback on this topic and I agree with you about 99%. The only bit that isn’t addressed in your response is the acknowledgement that UPnP changes the attack surface and it does this without any validation. If the router / firewall supports UPnP then the attack surface is able to change without the user knowing. This automagical reconfiguration of networks may expose additional / unintended attack vectors and that’s the real security concern. But, you’re right, using or expecting UPnP to be available as part an attack is lame and there are far more reliable ways to gain access into a network. But this automagical adjustment of attack surface is why I keep it off and statically configure. It’s also why Enterprises will never turn it on.

It depends on if you consider a DoS a security issue. It would not take much to overwhelm my Roon Core with attack traffic even if that attack traffic wasn’t modifying or compromising my data. Some goof on the 'net who decides they don’t want my Roon to function isn’t too far away from succeeding once they identify my IP:Port for ARC. It takes CPU cycles to throw things away. This is why I plan on using ARC behind a firewall once launched. My VPN concentrator does a better job of throwing away rouge attack traffic than a web service. Then I just have to worry about some goof eating up all my bandwidth. It’s never foolproof but this “always on” does allow for a fairly targeted attack against a single service and that can fall down pretty quickly.


Doesn’t sound like you think it’s quite around the corner.

But once it’s readily available, does it mean that RAAT can also be drastically simplified? I mean, if the transport layer already combines TCP-style redundancy with UDP or better speed, fast initiation, secure connection, multiple streams …

Seems it ticks a lot of Roon boxes straightaway.
(And will everybody else be able to do something akin to RAAT, on the cheap :thinking:)

I don’t think any of this has anything to do with RAAT just the ARC connectivity.

Nothing to do with ARC testing for sure, so maybe I should not have asked/posted - can hardly do this in the main forum though :slight_smile:.

Most LANs use TCP/IP :wink:, so the QUIC observations from Danny seemed relevant to me. I may completely misunderstand.

People talk about ports like they’re traffic trap doors… they‘re not, it’s just a number in the tcp/ip header. “Opening a port” doesn’t suddenly expose your network, it was exposed the moment you plugged it into the internet. So forget port paranoia, use strong passwords, and trusted software.

1 Like

Agreed. Also always disable default/built-in admin and guest accounts, and create new ones that are unique to your device/service… and as you say, use a strong, unique password for each.

I’m not sure I understand. In what ways do you find RAAT to be complicated?

Don’t think RAAT is complicated at all - it’s invisible to me as a user, so great! I was thinking about what you would have needed to code so it works on top of TCP, and imagined it would be a smaller / easier task with QUIC. Starting to suspect from your response that my thinking is flawed …

1 Like

An “I’ll get my coat moment” :wink:



And hat and sunglasses


I would love QUIC support. I use it already for AdGuard DNS and it’s amazing.

Others say something else.

For example: the Federal Office for Information Security in Germany provides some certification scheme for secure consumer grade internet devices; for broadband routers, to comply a device shall not offer automatic port forwarding. Looks like not that many manufacturers actually claim conformance, but for instance AVM seems to deliver their Fritz!Boxes with upnp auto port forwarding off by default anyway.

That’s why I’d rather turn to CISA or the German BSI (from the above example) for IT security related recommendations.


Not quite.

4.3 Firewall
The end-user MUST be able to configure the set of rules being used to adjust it to the specific (security) needs of the respective network. The firewall MUST NOT contain any port forwarding rules configured initially.
After initialization the firewall SHOULD allow all outgoing communication from the private network and deny all not requested incoming communication from the public network.

Note their emphasis on initially. And my search of the document did not find any mention of UPnP or not allowing it.

Regarding Fritzboxes, UPnP off by default seems reasonable if one doesn’t need it (the principle of least privilege also makes sense for services that you don’t consider a risk) but in the case of Fritzbox it would not make any sense to enable it by default, because UPnP rights can/must be assigned in the admin interface to specific devices on the network.

1 Like

You’re right. Only after getting ready to operate, they want the router to not have any port forwarding configured. That’s what I meant with automatic.