F5 Customer Edge IP Address and Domain Reference for Firewall or Proxy Settings

Objective

For F5 Distributed Cloud Customer Edge (CE) to function accurately in your environment, it is crucial to configure your firewall and/or proxy to allow connections to/from the IP addresses and/or domains provided below.

This reference document lists the public IP addresses and domains associated with the F5 Distributed Cloud that must be permitted in your firewall and/or proxy settings. In addition, it provides the firewall rules that are required for nodes within a CE site, Site Mesh Group (SMG) as well as DC Cluster Group (DC-CG) between sites, and finally the rules required for an external connector.

For automation purposes, you can download the IP addresses and domains plain text file.

Important: If your application remains stuck in the "connecting" mode or encounters network errors, ensure that you review your firewall or proxy settings and update the allowlist configuration to permit these IP addresses/domain connections and associated locations, such as Docker Registry.

---

Firewall Rule Overview

Rules	Requirement	Notes
Egress IP Address Rules	Mandatory	See Egress IP Address Rules for SMSv2 or Egress IP Address Rules for Legacy Sites.
Egress Domain Rules	Mandatory	See Egress Domain Rules or Egress Domain Rules Legacy.
DNS	Mandatory	Required if you are using the default DNS provided by F5 Distributed Cloud. See Default DNS for Site Registration and Updates.
NTP	Mandatory	Required if you are using the default NTP provided by F5 Distributed Cloud. Default NTP for Site Registration and Updates.
Multi-Node Site Rules	Optional	Required only if you are using a CE Site with three or more nodes. Required only if you are using a Secure Mesh Site v2 with High Availability (HA) enabled.
Site-to-Site Connectivity	Optional	Required if you are using an SMG or DC-CG to create a network mesh across multiple CE sites.

---

Firewall Requirements for Secure Mesh v2 CE Sites

Egress IP-Address Rules

The IP addresses below must be allowed in your firewall for registration/updates for CE sites.

Public IPv4 Addresses for Site Registration and Updates

Geography	Protocol	Port	IP Address
All Geographies	TCP	443	159.60.141.140

Public IPv4 Addresses for connecting to F5 Distributed Cloud Regional Edges

For public apps advertised to Distributed Cloud Regional Edges (REs), configure your network firewall to allow connections from the IP address ranges specified in the table below.

Geography	Protocol	Ports	IP Address	Notes
Americas	TCP	80, 443	5.182.215.0/25 84.54.61.0/25 23.158.32.0/25 84.54.62.0/25 185.94.142.0/25 185.94.143.0/25 159.60.190.0/24 159.60.168.0/24 159.60.180.0/24 159.60.174.0/24 159.60.176.0/24
	UDP	4500, 123	5.182.215.0/25 84.54.61.0/25 23.158.32.0/25 84.54.62.0/25 185.94.142.0/25 185.94.143.0/25 159.60.190.0/24 159.60.168.0/24 159.60.180.0/24 159.60.174.0/24 159.60.176.0/24	IPSec/UDP 4500 is optional as SSL for tunneling to global network is supported. Port 123 is for NTP service of RE.
Europe	TCP	80, 443	5.182.213.0/25 5.182.212.0/25 5.182.213.128/25 5.182.214.0/25 84.54.60.0/25 185.56.154.0/25 159.60.160.0/24 159.60.162.0/24 159.60.188.0/24 159.60.182.0/24 159.60.178.0/24
	UDP	4500, 123	5.182.213.0/25 5.182.212.0/25 5.182.213.128/25 5.182.214.0/25 84.54.60.0/25 185.56.154.0/25 159.60.160.0/24 159.60.162.0/24 159.60.188.0/24 159.60.182.0/24 159.60.178.0/24	IPSec/UDP 4500 is optional as SSL for tunneling to global network is supported. Port 123 is for NTP service of RE.
Asia	TCP	80, 443	103.135.56.0/25 103.135.57.0/25 103.135.56.128/25 103.135.59.0/25 103.135.58.128/25 103.135.58.0/25 159.60.189.0/24 159.60.166.0/24 159.60.164.0/24 159.60.170.0/24 159.60.172.0/24 159.60.191.0/24 159.60.184.0/24 159.60.186.0/24
	UDP	4500, 123	103.135.56.0/25 103.135.57.0/25 103.135.56.128/25 103.135.59.0/25 103.135.58.128/25 103.135.58.0/25 159.60.189.0/24 159.60.166.0/24 159.60.164.0/24 159.60.170.0/24 159.60.172.0/24 159.60.184.0/24 159.60.186.0/24	IPSec/UDP 4500 is optional as SSL for tunneling to global network is supported. Port 123 is for NTP service of RE.

Note: If the prefix list has CIDR with /28 subnet mask and response cache parameters has subnet mask as /24, then the response cache would be used even if the source prefix does not match the rule. You might need to adjust the response cache parameters according to the prefix set mask.

Egress Domain Rules

In addition to IP address-based egress rules, if you want to configure domain filtering in your proxy/firewall settings, the domains below must be allowed for registration/updates.

For provisioning of F5 Distributed Cloud CE sites using the new Secure Mesh Site v2 workflow, configure your network firewall/proxy to allow connections to the public domains specified in the table below:

Service	Protocol	Port	Domain Address	Notes
F5 Distributed Cloud	TCP	443	Use a single wildcard domain (recommended): *.volterra.io or Use FQDNs: Domains for Connecting to F5 Distributed Cloud Regional Edges tr2-tor-nodes.re.ves.volterra.io ty8-tky-nodes.re.ves.volterra.io dc12-ash-nodes.re.ves.volterra.io sy5-syd-nodes.re.ves.volterra.io sg3-sin-nodes.re.ves.volterra.io os1-osa-nodes.re.ves.volterra.io sif-che-nodes.re.ves.volterra.io sds3-tel-nodes.re.ves.volterra.io ams9-ams-nodes.re.ves.volterra.io mb2-mum-nodes.re.ves.volterra.io pa4-par-nodes.re.ves.volterra.io dx1-dxb-nodes.re.ves.volterra.io mtl7-mon-nodes.re.ves.volterra.io ls1-lis-nodes.re.ves.volterra.io me1-mel-nodes.re.ves.volterra.io sto6-sto-nodes.re.ves.volterra.io fr4-fra-nodes.re.ves.volterra.io dal3-dal-nodes.re.ves.volterra.io tn2-lon-nodes.re.ves.volterra.io pa2-par-nodes.re.ves.volterra.io sp4-sao-nodes.re.ves.volterra.io ny8-nyc-nodes.re.ves.volterra.io md2-mad-nodes.re.ves.volterra.io hk2-hkg-nodes.re.ves.volterra.io jk1-jkt-nodes.re.ves.volterra.io sv10-sjc-nodes.re.ves.volterra.io wes-sea-nodes.re.ves.volterra.io Domains required for registration with F5 Distributed Cloud SaaS services register.ves.volterra.io register-tls.ves.volterra.io myip.volterra.io downloads.volterra.io gcr.download.volterra.io blindfold.ves.volterra.io identityauthority.ves.volterra.io Domains required to support IP address reputation feed waferdatasetsprod.download.volterra.io cc-whitelist.download.volterra.io api.bcti.download.volterra.io api.bcss.download.volterra.io api-dualstack.download.volterra.io	These domains specify the F5 Distributed Cloud domains. The FQDN list is provided in case your egress firewall does not support wildcard domains.
Webroot URL Classification Database	TCP	443	localdb-url-daily.brightcloud.com localdb-url-rtu.brightcloud.com localdb-ip-daily.brightcloud.com localdb-ipv6-daily.brightcloud.com localdb-ip-rtu.brightcloud.com	These specify the domains for the Webroot URL classification database.

Important: We have removed all third-party wildcard domains. The only wildcard domain is a domain owned by F5.

---

Firewall Requirements for Legacy CE Sites

Egress IP-Address Rules (Legacy)

The IP addresses below must be allowed in your firewall for registration/updates for CE sites.

Public IPv4 Addresses for Site Registration and Updates (Legacy)

To provision legacy CE sites, you must allow the public IPv4 address ranges below, especially if your firewall does not support domain-based permissions.

Additionally, note that port 65500 is reserved for local UI and API access, so you may want to consider blocking or allowing this port as needed.

Important: IP addresses have the potential to change without F5 being aware of it. For this reason, using domain-based permissions is the preferred method rather than using this list.

Configure your network firewall to allow connections to the public IPv4 address ranges specified in the table below:

Geography	IP Address Range
All Geographies	20.33.0.0/16
All Geographies	74.125.0.0/16
All Geographies	18.64.0.0/10
All Geographies	52.223.128.0/18
All Geographies	20.152.0.0/15
All Geographies	13.107.238.0/24
All Geographies	142.250.0.0/15
All Geographies	20.34.0.0/15
All Geographies	52.192.0.0/12
All Geographies	52.208.0.0/13
All Geographies	52.223.0.0/17
All Geographies	18.32.0.0/11
All Geographies	3.208.0.0/12
All Geographies	13.107.237.0/24
All Geographies	20.36.0.0/14
All Geographies	52.222.0.0/16
All Geographies	52.220.0.0/15
All Geographies	3.0.0.0/9
All Geographies	100.64.0.0/10
All Geographies	54.88.0.0/16
All Geographies	52.216.0.0/14
All Geographies	108.177.0.0/17
All Geographies	20.40.0.0/13
All Geographies	54.64.0.0/11
All Geographies	172.253.0.0/16
All Geographies	20.64.0.0/10
All Geographies	20.128.0.0/16
All Geographies	172.217.0.0/16
All Geographies	173.194.0.0/16
All Geographies	20.150.0.0/15
All Geographies	20.48.0.0/12
All Geographies	72.19.3.0/24
All Geographies	18.128.0.0/9
All Geographies	23.20.0.0/14
All Geographies	13.104.0.0/14
All Geographies	13.96.0.0/13
All Geographies	13.64.0.0/11
All Geographies	13.249.0.0/16
All Geographies	34.192.0.0/10
All Geographies	3.224.0.0/12
All Geographies	54.208.0.0/13
All Geographies	54.216.0.0/14
All Geographies	108.156.0.0/14
All Geographies	54.144.0.0/12
All Geographies	54.220.0.0/15
All Geographies	54.192.0.0/12
All Geographies	54.160.0.0/11
All Geographies	3.143.6.187/32

Public IPv4 Addresses for Connecting to F5 Distributed Cloud Regional Edges (Legacy)

For public apps advertised to Distributed Cloud Regional Edges (REs), configure your network firewall to allow connections to the IP address ranges specified in the table below. Note that these IP address ranges also apply to apps connecting via Distributed Cloud Customer Edges (CEs).

Geography	Protocol	Ports	IP Address	Notes
Americas	TCP	80, 443	5.182.215.0/25 84.54.61.0/25 23.158.32.0/25 84.54.62.0/25 185.94.142.0/25 185.94.143.0/25 159.60.190.0/24 159.60.168.0/24 159.60.180.0/24 159.60.174.0/24 159.60.176.0/24
	UDP	4500, 123	5.182.215.0/25 84.54.61.0/25 23.158.32.0/25 84.54.62.0/25 185.94.142.0/25 185.94.143.0/25 159.60.190.0/24 159.60.168.0/24 159.60.180.0/24 159.60.174.0/24 159.60.176.0/24	IPSec/UDP 4500 is optional as SSL for tunneling to global network is supported. Port 123 is for NTP service of RE.
Europe	TCP	80, 443	5.182.213.0/25 5.182.212.0/25 5.182.213.128/25 5.182.214.0/25 84.54.60.0/25 185.56.154.0/25 159.60.160.0/24 159.60.162.0/24 159.60.188.0/24 159.60.182.0/24 159.60.178.0/24
	UDP	4500, 123	5.182.213.0/25 5.182.212.0/25 5.182.213.128/25 5.182.214.0/25 84.54.60.0/25 185.56.154.0/25 159.60.160.0/24 159.60.162.0/24 159.60.188.0/24 159.60.182.0/24 159.60.178.0/24	IPSec/UDP 4500 is optional as SSL for tunneling to global network is supported. Port 123 is for NTP service of RE.
Asia	TCP	80, 443	103.135.56.0/25 103.135.57.0/25 103.135.56.128/25 103.135.59.0/25 103.135.58.128/25 103.135.58.0/25 159.60.189.0/24 159.60.166.0/24 159.60.164.0/24 159.60.170.0/24 159.60.172.0/24 159.60.191.0/24 159.60.184.0/24 159.60.186.0/24
	UDP	4500, 123	103.135.56.0/25 103.135.57.0/25 103.135.56.128/25 103.135.59.0/25 103.135.58.128/25 103.135.58.0/25 159.60.189.0/24 159.60.166.0/24 159.60.164.0/24 159.60.170.0/24 159.60.172.0/24 159.60.184.0/24 159.60.186.0/24	IPSec/UDP 4500 is optional as SSL for tunneling to global network is supported. Port 123 is for NTP service of RE.

Note: If the prefix list has CIDR with /28 subnet mask and response cache parameters has subnet mask as /24, then the response cache would be used even if the source prefix does not match the rule. You might need to adjust the response cache parameters according to the prefix set mask.

Egress Domain Rules (Legacy)

In addition to IP address-based egress rules, if you want to configure domain filtering in your proxy/firewall settings, the domains below must be allowed for registration/updates.

Location	Protocol	Port	Address	Notes
F5 Distributed Cloud	TCP	80, 443	*.ves.volterra.io downloads.volterra.io	These specify the F5 Distributed Cloud domains.
F5 Distributed Cloud AI Model Updates	TCP	80, 443	*.blob.core.windows.net	This specifies the domains for obtaining the AI model updates.
Azure Registry	TCP	80, 443	volterra.azurecr.io vesio.azureedge.net *.azure.com	These specify the domains for the Azure Registry.
Microsoft	TCP	80, 443	*.microsoftonline.com	This specifies the Microsoft domains.
AWS	TCP	80, 443	*.amazonaws.com	This specifies the AWS domains.
Docker Registry	TCP	80, 443	docker.io docker.com	These specify the domains for the Docker Registry.
Google Registry	TCP	80, 443	*.gcr.io gcr.io storage.googleapis.com	This specifies the domains for the Google Registry.
Red Hat Registry	TCP	80, 443	update.release.core.os.net quay.io	These specify the domains for the Red Hat Registry.
Webroot URL Classification Database	TCP	80, 443	api.bcti.brightcloud.com cc-whitelist.s3.amazonaws.com api.bcss.brightcloud.com api-dualstack.bcti.brightcloud.com localdb-url-daily.brightcloud.com localdb-url-rtu.brightcloud.com localdb-ip-daily.brightcloud.com localdb-ipv6-daily.brightcloud.com localdb-ip-rtu.brightcloud.com	These specify the domains for the Webroot URL classification database.
Content Delivery Network (CDN) Domains	UDP	53	traffic-router-0.cdn-gc.ves.volterra.io traffic-router-1.cdn-gc.ves.volterra.io cdn.ves.volterra.io	These specify the domains for the F5 Distributed Cloud Content Delivery Network.

To allow the Distributed Cloud Services CEs to use various container registries, configure your network firewall to allow connections to the IP address ranges specified in the table below.

Geography	IP Address Range
All Geographies	23.158.32.48/29
All Geographies	84.54.60.0/29
All Geographies	84.54.61.48/29
All Geographies	84.54.62.48/29
All Geographies	103.135.56.48/29
All Geographies	103.135.56.176/29
All Geographies	103.135.57.48/29
All Geographies	103.135.58.0/29
All Geographies	103.135.58.128/29
All Geographies	103.135.59.0/29
All Geographies	159.60.164.0/29
All Geographies	159.60.166.0/29
All Geographies	185.56.154.0/29
All Geographies	185.94.142.0/29
All Geographies	185.94.143.0/29
All Geographies	185.160.8.152/29
All Geographies	185.160.8.160/29
All Geographies	185.160.8.168/29
All Geographies	185.160.8.176/29
All Geographies	193.16.236.64/29
All Geographies	193.16.236.88/29
All Geographies	193.16.236.104/29

Additional Firewall Requirements

Default DNS for Site Registration and Updates

For provisioning of F5 Distributed Cloud CE sites using the new Secure Mesh (v2) workflow, configure your network firewall to allow connections to the Google DNS IP addresses specified in the table below.

Important: You can use custom DNS servers while creating a CE Site. Refer to the Create Secure Mesh Site v2 guide for instructions. If you use custom DNS servers, then these firewall requirements are not required.

IP Address	Protocol	Port
8.8.8.8	TCP/UDP	53
8.8.4.4	TCP/UDP	53

Default NTP for Site Registration and Updates

For provisioning of F5 Distributed Cloud CE sites using the new Secure Mesh (v2) workflow, configure your network firewall to allow connections to the Google NTP IP addresses specified in the table below.

Important: You can use custom NTP servers while creating a CE Site. Refer to the Create Secure Mesh Site v2 guide for instructions. If you use custom NTP servers, then these firewall requirements are not required.

IP Address	Protocol	Port
216.239.35.4	UDP	123
216.239.35.8	UDP	123
216.239.35.12	UDP	123
216.239.35.0	UDP	123

Multi-Node Communication within a CE Site Cluster

For clusters with three or more nodes, always ensure that any firewall between the nodes allows all traffic between them. This communication occurs over the SLO network, so the firewall rules only need to permit traffic between the nodes' SLO interfaces.

This table provides the required rules:

Source IP Address	Destination IP Addresses	Action	Description
Source: 172.16.1.10	172.16.2.10 and 172.16.3.10	Allow	Allow Traffic from Node 1 to Nodes 2 and 3.
Source: 172.16.2.10	172.16.1.10 and 172.16.3.10	Allow	Allow Traffic from Node 2 to Nodes 1 and 3.
Source: 172.16.3.10	172.16.1.10 and 172.16.2.10	Allow	Allow Traffic from Node 3 to Nodes 1 and 2.

In a typical cloud environment, each network interface (NIC) of a node is protected by an individual, per-NIC firewall. These firewalls control both egress and ingress traffic on a per-interface basis and are critical in managing communication flows within and outside the cluster.

The diagram below represents a simplified example involving two nodes, although production sites generally consist of at least three control nodes. As always, the focus here is on the SLO (Site Local Overlay) network, which facilitates communication between nodes.

It is important to note that this setup introduces additional complexity, as each node has its own independent firewall. For example:

• NIC1 on Node 1 is governed by Firewall 1
• NIC2 on Node 2 is governed by Firewall 2

This independence means that bidirectional communication between nodes must be explicitly allowed on both firewalls.

This table provides the NIC FW1 rules:

Direction	Prefix	Action	Description
Egress	172.16.2.10/32	Allow	Red Arrow NIC FW1
Ingress	172.16.2.10/32	Allow	Blue Arrow NIC FW1

This table provides the NIC FW2 rules:

Direction	Prefix	Action	Description
Egress	172.16.1.10/32	Allow	Blue Arrow NIC FW2
Ingress	172.16.1.10/32	Allow	Red Arrow NIC FW2

CE-to-CE Connectivity

Note that the CE-to-CE required communication, in terms of firewall rules, applies for both SMSv2 and legacy CE sites.

Site Mesh Group

The SMG establishes an IPsec tunnel between CEs. Note that in an SMG any of the two CEs might be the initiator. Therefore, it is best practice to ensure traffic is allowed in both directions.

Source IP Address	Destination IP Address	Protocol	Port	Action	Description
1.1.1.1/32	2.2.2.2/32	UDP	500	Allow	IKE (Internet Key Exchange) for establishing VPN tunnels (Phase 1).
1.1.1.1/32	2.2.2.2/32	UDP	4500	Allow	NAT Traversal (NAT-T) — used when devices are behind NAT.
1.1.1.1/32	2.2.2.2/32	IP	50	Allow	ESP (Encapsulating Security Payload) encrypts and protects actual data.
2.2.2.2/32	1.1.1.1/32	UDP	500	Allow	IKE (Internet Key Exchange) for establishing VPN tunnels (Phase 1).
2.2.2.2/32	1.1.1.1/32	UDP	4500	Allow	NAT Traversal (NAT-T) — used when devices are behind NAT.
2.2.2.2/32	1.1.1.1/32	IP	50	Allow	ESP (Encapsulating Security Payload) encrypts and protects actual data.

For three-node sites (as shown in the figure below), a key challenge arises: you cannot pre-determine which node in Site-1 will establish a tunnel with which node in Site-2. Therefore, you must follow the same logic outlined in the table above, but with an important addition - firewall rules must allow traffic between any node in Site-1 and any node in Site-2.

Furthermore, since either Site can initiate the tunnel, firewall rules must be configured to allow bidirectional traffic between all nodes across the two sites. This ensures seamless mesh connectivity regardless of which node or Site initiates the connection.

DC Cluster Group

DC Cluster Group leverages an IP-in-IP tunnel between CEs and is generally used when the connectivity between the sites is private.

DC-CG uses UDP port 6080. Therefore, for a DC-CG to operate, you need to ensure that UDP port 6080 is allowed. As with the Site Mesh Group case, we allow the traffic in both directions.

Source IP Address	Destination IP Address	Source Port	Destination Port	Protocol	Action	Description
10.1.1.2/32	172.16.1.9/32	Any	6080	UDP	Allow	IP-in-IP traffic
172.16.1.9/32	10.1.1.2/32	Any	6080	UDP	Allow	IP-in-IP traffic

For three-node sites, ensure you allow the rules from any node in Site-1 to any node in Site-2 and vice-versa, and allow both directions similar to the logic followed for a Site Mesh Group.

Cloud Connect

Cloud Connect is an orchestration framework that extends network segmentation on the CE to include spoke VPCs and VNets in AWS and Azure. Currently, this capability is supported only for AWS Transit Gateway (TGW) sites and Azure VNet sites.

AWS

Cloud Connect in AWS automates the provisioning of a GRE tunnel between the AWS TGW and the CE’s Service-Link Interface (SLI). In an orchestrated AWS TGW Site, two interfaces are created on the CE: one in the SLO (Service-Link Outbound) VRF and another in the SLI (Service-Link Inbound) VRF. The GRE tunnel terminates on the CE’s SLI interface, so any security group or firewall rule required to allow tunnel establishment must be applied to the ENI associated with the CE’s SLI interface.

It is important to note that the tunnel is initiated from the CE, which means the associated security group must allow outbound traffic for the appropriate protocol.

In AWS terminology, this setup aligns with TGW Connect Attachments and Peerings. More information can be found in the official AWS documentation.

When it comes to configuring security groups or firewall rules, there are generally two approaches:

• Least Privilege (Highly Restrictive): Allows only the specific protocol, ports, and source/destination IP addresses required for the GRE tunnel.
• Less Restrictive: Provides broader allowances for quicker setup or troubleshooting but is not recommended for production environments.

Configuring a Restrictive Firewall Rule for Cloud Connect

To ensure Cloud Connect functions properly while following a least privilege (restrictive) security approach, the firewall or security group must be configured to explicitly allow GRE traffic between the CE and the Transit Gateway GRE addresses. As discussed before, GRE termination happens on the SLI interface and thus the security group rule or firewall rule would be applied to the SLI in the outbound direction.

The firewall rule (restrictive) to ensure a Cloud Connect works should be configured as follows:

Interface	Direction	Protocol	Destination
SLI	Outbound	GRE/IP Protocol 47	TGW GRE Address

For three-node CE sites, you must repeat the process of identifying the Transit Gateway GRE address for each Connect peer associated with the site. Each GRE tunnel terminates on a specific CE node’s SLI interface, so it is essential to retrieve the GRE address for every peer and ensure the corresponding firewall or security group rule is configured on the correct node.

In other words, each CE node participating in the Cloud Connect topology must allow GRE traffic to and from its respective Transit Gateway GRE address, following the restrictive approach outlined earlier.

Less Restrictive Firewall Rule for Cloud Connect

If a less restrictive security posture is acceptable, you can simplify the configuration by allowing GRE traffic from all CE nodes toward the Transit Gateway (TGW) CIDR block, rather than specifying individual GRE peer addresses.

To find the TGW CIDR block:

1. Open the Amazon VPC Console.
2. In the navigation pane, select Transit Gateways.
3. Choose your specific Transit Gateway.
4. In the details pane, locate the CIDR block information assigned to the TGW.

Interface	Direction	Protocol	Destination
SLI	Outbound	GRE/IP Protocol 47	TGW CIDR Block

Azure

In Azure the approach is simpler, as it depends on VNet peering and there are no overlay tunnels that need to be established. The only requirement is to ensure the firewall in the path allows all traffic from the spoke VNets (VNET-PROD) in the below example in the inbound direction (in other words, traffic toward the CE interface).

Interface	Direction	Protocol	Source
SLI	Inbound	All Traffic	VNET-PROD (10.1.0.0/16)

---