“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.
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.
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
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.