how-to · Reviewed 2026-11-02 GA

Firewall administration

The Rescale Compute Network Application Firewall (CNAF) is a Rescale-hosted firewall service that sits around the compute regions where your jobs and workstations run. It is intended for organizations that have strict network restrictions on outbound traffic from HPC workloads. By default, a CNAF blocks any network traffic leaving the compute boundary, except the traffic the Rescale control plane needs to run jobs and access Rescale-managed services like storage and license proxies. Organization administrators use the CNAF administration page to manage IP and domain allowlists across all of their CNAFs.

How a CNAF fits into your environment

A CNAF is deployed per CSP region (for example AWS/us-east-1 or Azure/southcentralus). Traffic between the Rescale control plane and the compute region is always allowed, so jobs run and can reach Rescale-managed services such as storage, Company License Proxies (CLPs), and License Hosts (LH). If you use Rescale VPN services, internal private routes continue to work behind the CNAF, because a CNAF only affects traffic taking the default route to the public internet.

Anything else is blocked unless you add it to the CNAF allowlists. That includes:

• Outbound traffic from a job cluster or workstation to the public internet.
• Traffic from a cluster or workstation back to a user's on-prem desktop.

The control plane reaches compute through the CNAF. Everything leaving the compute boundary is blocked until you allowlist it.

If a job needs to pull something from the internet (for example a Python package mirror), add an IP or domain entry to the allowlist for that CNAF. Allowlist changes are synchronized across every CNAF in your organization, so you do not update each deployment individually.

Because a CNAF is attached to the Company Private Network, everything launched in that network routes through it, workstations as well as jobs. One consequence is worth knowing in advance: outbound traffic arrives at its destination carrying the CNAF's IP address rather than the compute node's, which matters for anything on the far side that allowlists by source IP.

Where CNAF is available

CNAFs run on the commercial platforms and on ITAR. They are not available on FedRAMP, because the underlying firewall technology is not FedRAMP approved, nor on IL5. If you have a FedRAMP organization that needs compute egress control, raise it with your account team rather than planning around a CNAF.

Provisioning a new CNAF

CNAF is an optional, separately priced feature. You cannot create a CNAF from the administration portal. Contact Rescale to request and purchase one. When you request a new CNAF, have the following ready:

• Any known internet downloads your jobs and workstations need (for example Python libraries or Linux utilities).
• Whether a Company Private Network (CPN) already exists in your Rescale environment. A CPN is the Rescale equivalent of a CSP private network like an AWS VPC or Azure VNet.
• The regional platform hosting your Rescale organization (Americas, Europe, Japan, Korea, or ITAR).
• How many compute regions require CNAF coverage, with the CSP provider and region name for each (for example AWS/us-east-1).
• The list of IP addresses and domains that outbound traffic from jobs or workstations should be allowed to reach.
• Whether your organization uses a NAT gateway.
• The Rescale licensing services you have in use (CLPs, License Hosts, and so on).

Once one or more CNAFs are provisioned, they appear on the firewall administration page.

Opening the firewall administration page

The firewall administration page lives in the Organization Administration portal. You need Organization Administrator access; Workspace Administrator is not sufficient.

1. Open the Organization Administration portal.
2. Go to the Integrations menu.
3. Select Firewalls.

The page has four sections: firewall deployment details, the IP allowlist, the domain allowlist, and a recent updates log.

Reviewing deployment details

The first section lists every CNAF deployed for your organization. For each CNAF you see:

• The compute region it covers.
• The current enablement status (enabled or disabled).
• A total count of deployed CNAFs.

You can temporarily disable a CNAF from this page. Disabling does not remove or terminate the firewall; it suspends blocking, so all network traffic in that compute region passes through until you re-enable it. You can cancel a pending disable request from the Recent Updates section at the bottom of the page.

To create a new CNAF, contact Rescale. New CNAFs cannot be created from the administration page.

Managing the IP allowlist

The IP allowlist is a table of CIDR ranges that compute traffic is allowed to reach. Entries are synchronized across every CNAF in your organization.

Adding an IP entry

1. Click Add Entry in the IP Allowlist table.
2. Enter the value in CIDR notation. For a single IP, append /32 (for example 162.194.16.4/32).
3. Provide a short description so other administrators know why the entry exists.
4. Repeat for additional entries. You can cancel any unsubmitted addition with Cancel Add.
5. When you are done, click Request IP Allowlist Update to submit the changes for review.

Removing an IP entry

1. Click Delete next to the entry.
2. If you change your mind before submitting, click Cancel Delete.
3. Click Request IP Allowlist Update to submit the deletion.

Once you submit, the entries show status values of Pending Add or Pending Delete until Rescale approves and applies the change, and everything already in force reads Active. You can cancel a pending request at any time before it is applied. While a request is pending, you cannot queue additional changes to the IP allowlist; cancel the pending request if you need to change course.

Classic UIA submitted request in progress. Active entries are in force; the Pending rows are waiting on Rescale's review, and Cancel Update Request withdraws them.

Allowlist updates do not interrupt running work

Applying an IP or domain allowlist change causes no downtime for the CNAF, so jobs and workstations already running behind it keep running while the update goes in. You do not need a maintenance window to add an entry.

Managing the domain allowlist

The domain allowlist is a table of fully qualified domain names that compute traffic is allowed to reach. Like the IP allowlist, entries are synchronized across every CNAF in your organization and require Rescale review before they take effect.

Domain entries cover HTTP and HTTPS only, on ports 80 and 443. Traffic to a domain on any other port is dropped however the domain is written, so a service reached over a non-web port cannot be allowlisted by name at all. The only way to permit it is an IP entry covering the host or its range, which is a trade you should make deliberately, since an IP range is broader than a hostname.

Acceptable values include:

• Fully qualified domain names (for example pypi.org).
• Basic regex patterns combined with a domain to match multiple subdomains.

Direct URL values that begin with https:// are not supported. The entry must be the domain itself, not the URL.

A path in an entry does not narrow it

Writing company.io/libraries/folder does not restrict access to that folder. A firewall decides whether traffic may reach a host, and it never sees the path, so the entry behaves as though you had written company.io and permits everything served from that domain.

If you need access limited below the domain, that is a file-system or object-store permissions question on the far side, not something a CNAF can express.

Rescale also maintains a default allowlist of hosts and IPs applied to every CNAF, covering what the platform itself needs so that your firewall cannot accidentally block the product. You do not manage those entries and they do not appear in your lists, so some destinations will work without your having allowlisted them.

Regex and wildcard examples

Regex patterns let you cover multiple subdomains with a single entry:

abcdefg-[0-9]*.blob.core.windows.net

A wildcard on a second-level domain matches many subdomains at once. For example:

*.orgname.org

matches mirror.orgname.org, mirrors.orgname.org, and mirrorlist.orgname.org.

Adding and removing domain entries

The add, delete, and submit workflow matches the IP allowlist. Click Add Entry or Delete, enter your change, then click Request Domain Allowlist Update to submit. While a request is pending, you cannot queue additional changes to the domain allowlist. The IP and domain allowlists can be updated independently of each other.

Reviewing recent changes

The Recent Updates section at the bottom of the page lists up to the 10 most recent CNAF changes, including pending submissions. Each entry shows:

• The date of the change.
• The administrator who requested it.
• The current status (Pending, Applied, Canceled).

Use this section to confirm that a request has been approved. When Rescale applies the change, the status moves from Pending to Applied.

What to expect from the review process

For security, all CNAF allowlist updates are reviewed by Rescale before they are applied. During North America business hours, expect a response within one to two hours; if a change is urgent, contact support and ask for it to be expedited rather than waiting. You can cancel a pending request at any time before it is applied, and canceling resets the allowlist entries to their previous state.

What a CNAF does not cover

A CNAF controls egress from compute. It is not a general data-loss control, and the gap matters if you adopted it for exfiltration reasons.

Once a job writes its results back to Rescale storage, those files sit in the control plane rather than behind the firewall, and a member can download them to their own machine without the CNAF being involved at all. If your concern is data leaving the organization rather than data leaving the compute region, the control you want is download restrictions, which caps how much a workspace member can pull out of the platform. Use both: the CNAF stops a running job reaching the internet, download restrictions govern what people take out afterwards.

Licensing behind a CNAF

Because outbound traffic leaves with the CNAF's IP address, license services that recognize your compute nodes by IP can stop recognizing them. What you need to do depends on where the license service sits.

Nothing changes while everything stays private. Nodes in the same virtual network as the CNAF reach each other over private addresses without routing through it, and VPN routes to an on-prem license server are private too, so neither is affected.

It changes when traffic crosses the network boundary. Traffic between CSP regions travels over the internet, so a Company License Proxy in one provider's region and a CNAF in another will be blocked by default. For Rescale On-Demand Licenses, add the on-demand license proxy's public IP to the CNAF IP allowlist so nodes connect to it directly and it sees their own addresses. For a CLP or License Host outside the CNAF's virtual network, add its public IP for the same reason, and note that these do not use fixed addresses by default, so the allowlist entry has to be refreshed whenever the CLP or License Host is rebuilt.

Known restrictions

• Creating new CNAFs is not automated. Submit new CNAF requests directly to Rescale.
• Domain list entries must be fully qualified domain names. URLs and paths are not accepted.
• Domain entries cover HTTP and HTTPS only, on ports 80 and 443. Other ports require an IP entry.
• Submitted CNAF allowlist updates are not applied automatically. They are first reviewed and approved by Rescale.
• The administration page can occasionally be slow to refresh after a change request is submitted.
• CNAFs are available on the commercial platforms and ITAR, but not on FedRAMP or IL5.

Workstation sessions can bypass the CNAF, with a caveat

If NiceDCV traffic to a workstation needs to avoid the firewall, an IP allowlist entry for the connecting address will do it, but only if that address is static. Allowlisting a dynamic address breaks the moment the user's IP changes, which makes it a support ticket waiting to happen. Where no static address exists, route the session over a VPN into your Company Private Network instead.

Related

• Access Restrictions — restrict who can access the platform by IP
• Control Plane IP Addresses — allowlist Rescale Control Plane IPs for BYOC/BYOS