IP Connectivity Requirements for ROCK and Qobuz (ref#SFLS81)

Hi! What’s not quite right with Roon?

· None of the above quite fits

None of the above quite fits

· None of these quite match

Tell us what's going on

· What IP connectivity requirements are needed to connect ROCK with Qobuz

Tell us about your home network

· Nokia XS-2426G-B router (ISP) -> Check Point 1535 Firewall/Switch -> Netgear GS105e Switch -> ROCK

ROCK needs to have internet access. What, specifically, is the question?

“ROCK needs to have internet access.” is to generic in my case. I truly wish for a list of needed TCP/UDP connections

You didn’t write that in the first post, hence why I asked:

I doubt you will get this info. Qobuz may change their IPs and Roon can’t control that

Hmm Title ???

The URLs will do

“IP connectivity requirement” is not a specific question. This is a low-level technical thing that requires precision in what the question is, to be able to answer it.

And now official support can answer this or not, when they come back to the office and the question reaches the top of their queue.

Hi @Jan_de_Ruijter,

Thanks for the clarification — that helps.

Roon (including ROCK) and Qobuz are not designed to operate in restricted or whitelisted networks. Both services rely heavily on dynamic cloud infrastructure and CDNs, so static IP allow-listing is not supported and will not work reliably. Only domain (FQDN) based allow-listing is possible.

That said, below is the best-effort list of domains and ports that must be allowed outbound from ROCK for Roon and Qobuz to function. Please note this list is not guaranteed to be complete and may change without notice.

Required ports

TCP 80
TCP 443
UDP 123 (NTP time sync)

Roon cloud services (must be reachable)

*.roonlabs.com
account.roon.app
api.roonlabs.net
cdn.roonlabs.net
updates.roonlabs.net
discovery.roonlabs.net

Qobuz uses multiple CDNs and regional endpoints. At minimum:

*.qobuz.com
*.qobuz.net
*.qobuz.fr

Plus CDN infrastructure used by Qobuz (dynamic and required):

*.cloudfront.net
*.akamai.net
*.akamaized.net
*.fastly.net

Even with all of the above allowed, enterprise firewalls (like Check Point) that perform TLS inspection, packet filtering, or aggressive connection tracking can still break Roon and Qobuz, because:

  • endpoints are dynamic
  • certificates are pinned
  • connections are long-lived
  • and traffic is optimized for consumer internet models, not corporate networks

If ROCK is behind a restricted or inspected firewall, intermittent or partial failures are expected.

If you need Roon to work in a locked-down environment, the only supported approach is:

  • allow unrestricted outbound HTTPS
  • or place ROCK in a less restricted network segment

Thanks for your answer

Hi @Jan_de_Ruijter,

Another consideration is how a blanket whitelist approach might compromise the intended function of your enterprise security switch.

The Check Point 1535 is designed for fine-grained traffic control like application inspection, URL filtering, port-based policies, and threat prevention. If you over-whitelist, you’re effectively widening the attack surface and risk exposing your network to the exact brute force and malware attacks that Check Point’s security features are designed to prevent.

If this switch firmware supports Application Control and/or Identity Awareness, we recommend you use these features to allow Roon traffic based on its application signature or the authenticated user/device, rather than by URL/IP ranges.

Hopefully, this helps. We’ll keep this thread open for a few more days in case you have further questions.

Perhaps the following is “to deep” or “to much detail” but I’ll add a “ROCK allow all” rule at the top of my rule base and analyze the results using FW MONITOR (Check Point implementation of TCPDUMP) and WIRESHARK. Afterwards I’ll be able to a more “fine grained” aproach.

Thanks for your toughts (Connor), apreciated.

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.