Roon networking analysis

[iso]

The goal of this post is to cover networking ports used by Roon.

Earlier today I spoke with product development and gave feedback that proper networking documentation was needed. It would serve to make installation easier for users with non-standard network setups, such as multiple firewalled network segments. Documentation would provide needed information to those without the skills to perform packet analysis, as well as speed things along for those that do have these skills but want as friction-less of a deployment as possible.

I’m intending to publish my findings as a means to provide some information to the community until official documentation can step in. If you do not want to review the entire post and just want to jump to the results, check the TL;DR below.

Analysis of traffic:
The capture being referenced is watching with a filter targeting the roon core (source OR destination), and the core is running on Fedora 40. This traffic was captured by stopping the roon service, beginning the capture, and then starting the roon service. Once running, a mobile client in a separate VLAN/subnet (roon remote) was connected, began playback of audio, and then stopped.

EDIT:
The firewall in my environment has MDNS and multicast enabled. The firewall rule suggestions at the end are assuming you allow multicast between the subnet the roon core is on, and the other subnets the remotes/bridges are on.

Roon Core traffic flow after startup:
-DNS query for api.roonlabs.net was performed for A/AAAA records.
-IGMPv3 group 239.255.255.250 was joined via multicast to 224.0.0.22
-SSDP discover packet sent to multicast 239.255.255.250 over UDP/1900
-NAT-PMP external address request sent to gateway over UDP/5351 (Note: I have NAT-PMP/UPNP disabled, so no further information was gathered on this. At this point, if you have either enabled, it should “Just Work™”, and automatic configuration of your firewall should occur.)
-3-Way handshake to api.roonlabs.net performed (TCP/443)
-TLSv1.2 handshake to api.roonblabs.net performed (for the cipher nerds out there, the server selected TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 [0xcca9] which as of this posting is rated A+)
-DNS query for bits.roonlabs.net for A/AAAA records
-3-way handshake to bits.roonlabs.net, and subsequent TLS connection (interestingly enough, TLSv1.3 using TLS_AES_256_GCM_SHA384 [0x1302]. Also rated A+ as of this posting)
-Roon Discovery (UDP/9003) packets sent to multicast 239.255.90.90, and subnet broadcast address. These packets reference TCP/9200
-Roon Discovery (UDP/9003) sent again to multicast address above, packets reference TCP/HTTP/HTTPS ports 9150,9330,55000 respectively
-First Roon Bridge attempts connection to core over UDP/37831 (which was source port for Roon Discovery Packet)
-Second Roon Bridge attempts connection to core over UDP/37831
-Subsequent UDP packets observed that return to core over UDP using the source ports used by Roon Core when performing Roon Discovery.
-First Roon Bridge connects to core over TCP/9330
-First Roon Bridge performs websocket connection.
-Core performs DNS Query for push-connector-v2-0.prd.roonlabs-1.prd.roonlabs.net
-Core connects to push-connector above over TCP/80 and changes to websocket
-Roon remote (mobile phone) begins sending ICMP to multiple ports listed in Roon Discovery packet
-Roon Core sends UDP packets back towards Roon Remote over UDP. Destination ports are all ports that were attempted by Roon Remote over ICMP.
-Roon Core sends Roon Discovery packet to Roon Remote
-Roon Remote connects to Core over TCP/9332
-Roon Core sends multiple UDP packets to Remote, all high ephemeral ports
-Roon Core sends TCP/Ephemeral to remote. Likely audio playback. Worth noting there is some DPLAY packets in there as well, but these are also using the same ports.

The above process of announcing to multicast/broadcast/SSDP appeared to be consistent across restarts of the roon core service. After a pattern was observed, I moved from following flows to inspecting traffic by source, grouped with destination/protocol. Below are the observations.

Roon Remote ports observed:
-Connections to Core: TCP/9330, TCP/9332, ICMP(UDP)/Ephemeral
-Connections from Core: UDP/9003, UDP/Ephemeral, TCP/Ephemeral

Roon Core ports observed:
-Connections to gateway: UDP/53, UDP/5351, UDP/5353, UDP/9003
-Connections to subnet broadcast: UDP/9003
-Connections to multicast: IGMP, UDP/1900, UDP/9003, UDP/5353 (might not be tied to roon. PTR records are for raop and googlecast)
-Connections to remote: UDP/9003, UDP/33990-58611, TCP/37176-50608
-Connections to bridge: TCP/9200, TCP/41975-43684, UDP/34685-60020
-Connections from remote: TCP/9330, TCP/9332, UDP/33990-41114
-Connections from bridge: TCP/9330, TCP/54282-60682, UDP/36472-47701
-Connections to external: api.roonlabs.net, bits.roonlabs.net, discovery.roonlabs.net, push-connector-v2-0.prd-roonlabs-1.prd.roonlabs.net. Everything used TCP/443 except for connections to push-connector, which used TCP/80.

Roon Bridge ports observed:
-Connections to core: TCP/9330, TCP/54282-60682, UDP/36472-47701
-Connections from core: TCP/9200, TCP/54282-60682, UDP/37381-43071

Some final thoughts/takeaways:
Looking at the ephemeral ports, there appears to be a clear distinction between TCP and UDP port ranges. Another item worth noting is that ephemeral ports are not following RFC 6335 which states this should be in 49152-65535 range. My best guess (and why I called out the Fedora 40 host) is that this is following standard linux port ranges, which is typically 32768-60999. This is an important detail if you are planning on using accurate firewall rules between your core and bridge/remote, as this range will depend on the host OS since it appears Roon’s software is not hard coded to a specific range. It would be nice to receive where the line between TCP/UDP exists in the ephemeral range as well.

My bridges and remotes are all on my wireless client subnet. I feel this needs to be mentioned because I did not inspect traffic directly for these, so things like multicast or outbound connections to the internet would not be seen. As such, there may be some external connections that are needed to allow bridges/remotes to work correctly.

This traffic was captured over a few short periods of time, so I know I do not have the full picture here. If you’re looking to lock down firewalls to only the necessary ports and port ranges, then some assumptions will need to be made. Namely on the 9000 range ports. 9330 was in use, 9332 was as well, so what about 9331? Does that range stop at 9332, or does it continue to 9400? How will adding additional remotes and bridges affect the ports in use?

TL;DR
I can think of three general approaches here, each increasing in security over the former.

-The ‘just make it work approach’, where you allow TCP/UDP ports 1024-65535 between everything, as well as access to IGMP and ICMP, and do not restrict outbound internet access.

-The ‘lets reign it in a bit’ approach, where you allow the core/bridge/remote to talk on TCP/UDP ports 9000-9500, and 30000-65535, IGMP/ICMP, and do not restrict outbound internet access.

-The ‘enterprise security’ approach, where specifically you allow:

Source, Destination, Port, Protocol
- Remote, Core, 9300-9400, TCP
- Remote, Core, N/A, ICMP
- Remote, Core, 32768-65535, UDP
- Core, Remote, 9000-9100, UDP
- Core, Remote, 32768-65535, TCP / UDP
- Bridge, Core, 9300-9400, TCP
- Bridge, Core, 32768-65535, TCP / UDP
- Core, Bridge, 9100-9300, TCP
- Core, Bridge, 32768-65535, TCP / UDP
- Core, Multicast, N/A, IGMP
- Core, Multicast, 9000-9100, UDP
- Core, Broadcast, 9000-9100,UDP
- Core, External Sites(*), 80/443, TCP

External Sites(*):
- api.roonlabs.net
- bits.roonlabs.net
- discovery.roonlabs.net
- push-connector-v2-0.prd-roonlabs-1.prd.roonlabs.net

I’m assuming with the enterprise security approach youre already accounting for DNS/DHCP where needed, as well as any other internal services you need to allow.

[ipeverywhere]

Good summary. Been a while since I looked at it.

Two things you should note in your write up.

You’re assuming L3 connectivity for your firewall. You won’t even get that far without allowing for multicast and mdns. EDIT: I write that too quickly. What I mean is you’re assuming unicast in your firewall setup. Need a firewall config that understands broadcast / multicast. Not usually a consumer thing.

When I looked at this a long time ago Roon was pinging the entire subnet. I didn’t see that in your write up so hope they stopped doing that.

@iso

oes that range stop at 9332, or does it continue to

It keeps incrementing by one. Not sure it has an upper bound. Resets on server restart.

Remotes seem easier to get working and stay working across subnets than endpoints. If you want to expand your doc maybe break it out by Remote and Endpoint.

Nice work

[iso]

@ipeverywhere

You’re assuming L3 connectivity for your firewall. You won’t even get that far without allowing for multicast and mdns.

Correct. This was implied when following the flows, but you’re right, this needs to be called out because the write up is meant to also help users that don’t happen to be network engineers.

@ipeverywhere

Need a firewall config that understands broadcast / multicast. Not usually a consumer thing.

This write-up isn’t really meant for consumer equipment. Although someone running WRT firmware might have access to the feature-set needed to segment with VLANs, enable multi-cast, and support MDNS, most consumer grade networks are typically a single segment with maybe a wireless repeater or two tossed in there. That’s not to say that there are not people out there with multiple WRT routers segmenting their network, but I think its a fair assumption that the likelihood (and number) of users doing it this way is smaller than the crowd using pro-sumer, SOHO, professional/enterprise, or opensource.

@ipeverywhere

When I looked at this a long time ago Roon was pinging the entire subnet. I didn’t see that in your write up so hope they stopped doing that.

I’m not seeing ICMP to the whole subnet, but theres definitely traffic being sent by the core to the subnet broadcast IP the core is in. I didnt grab packet captures looking at the remote/bridge either, so I can’t say if thats occuring from them.

@ipeverywhere

If you want to expand your doc maybe break it out by Remote and Endpoint.

I’m rather new to Roon so forgive the question, but what do you mean by endpoint? Is that the device that sends the sound to the speakers? If this is the case, then that is in the core traffic flow listed as the bridge (along with the remote), and broken out at the TL;DR. Let me know if that needs further clarification.

[Rugby (aka Daniel or Big Dan)]

@iso

also help users that don’t happen to be network engineers.

@iso

his write-up isn’t really meant for consumer equipment.

I suspect most users follow Roon’s direct Networking Best Practices advice which warn them not to use managed network equipment. Have you reviewed that document? Here is a link to the
# Advanced Networking section:

[ipeverywhere]

@iso

but what do you mean by endpoint

Yes, endpoint is the network devices that receive the audio streams. Used to be called zones. Roon supports its own protocol caller RAAT and publishes software called Roon Bridge. Other protocols are already documented (Airplay, Cast, Sonos, etc.).

Remotes are the devices used to interact with Roon; the GUI.

@iso

likelihood (and number) of users doing it this way is smaller than the crowd using pro-sumer

There is a surprising number of “pro-sumer” gear that’s flat out broken regarding some of these features and, if you browse the ARC section where people are trying to make that work, you’ll find a surprising high percentage of Roon users with this kind of gear. But, yes, all good points. Keep documenting what you find.

[iso]

@Rugby

I suspect most users follow Roon’s direct Networking Best Practices advice which warn them not to use managed network equipment.

I’d say the vast majority plug in consumer equipment and call it a day. Likely 90-95% of the total user base would never need the BPA, nor what I’ve posted in the thread. Of that 5-10%, some might have bought equipment they dont know how to support, some have enthusiast level knowledge, and some have professional level knowledge. I’m trying to get info out that benefits everyone, albeit some more benefit more directly than others. I’m not advocating that users actively pursue upgrades from consumer to enterprise equipment.

@Rugby

Have you reviewed that document?

Link isn’t working for me but I did review that when deploying Roon within my network . I skimmed through initially looking for a table listing ports/protocols and when I didn’t spot anything, read through the best practices doc in its entirety. I saw mention of IGMP, and knew during the initial packet captures to watch for multicast. Multicast was not enabled between my client and server subnets until Roon came along, and the mention of it alone was enough to save me time when deploying.

To quote the doc directly: “…we may ask you to temporarily simplify your network to help us rule out common stumbling blocks.”
I think this is an acceptable stance from a troubleshooting perspective. We can’t expect roon to support every vendor’s advanced gear. However, if you’re not going to support every router under the sun, then providing the details on networking requirements is a must. This lessens the burden on support, and enables end users to properly deploy the product.
I certainly know of people who have what Roon would call an advanced network setup, but these individuals do not know how to read (or perform) a packet capture. What those people do know how to do, is take a network port list and plug the values into their firewalls/network equipment.
Having official documentation on this shouldn’t take long to create and benefits multiple parties.

[iso]

Gotcha. I called the endpoints ‘bridges’ based on the service that was running on them. Looking at the effort that already went into this, I may as well do pcaps on the endpoints and remote. I don’t expect to see something different, as I suspect the roon server is responsible for advertising its existence and everything else is likely just listening and waiting for those advertisements.

@ipeverywhere

There is a surprising number of “pro-sumer” gear that’s flat out broken regarding some of these features

Interesting, I wonder if its misconfiguration or if its an issue with the device’s feature-set.

Personally, ARC isn’t for me. Security concerns aside, I can just VPN into my home network and use the Roon remote app. When out and about I’d rather just use Tidal though, but that’s because my home internet is slooooow.

[Forsaked]

@iso the enterprise approach worked like charm for me, thank you!