Proxy for CE Registration and Upgrades Reference

Published April 5, 2023 | Last modified July 1, 2025

Objective

This guide lists the different proxy options for CE registration and upgrades that enterprises can use with the new Secure Mesh Site v2. It also shows example configurations.

Prerequisite

See the Firewall and Proxy Server Allowlist Reference guide for the list of IP addresses and domain names that must be allowed in a customer’s environment.

Option 1: Using a Single F5 IP Endpoint

Using this option, customers use the F5 single anycast IP endpoint as proxy for CE registration and upgrades hosted on the F5 Distributed Cloud Global Network.

As part of Secure Mesh Site v2 deployment workflow, you generate a JWT-based node token that encodes this IP endpoint. You can find the registration endpoint information by entering the generated site token into any JWT decoder, like jwt.io.

Option 2: Using Customer’s Enterprise Forward Proxy

(A) Using Enterprise Proxy Directly

In this case, CE sites built using Secure Mesh Site v2 workflow will use the customer’s enterprise forward proxy to access the domains required for CE registration and upgrades. Therefore, the customer needs to open these required domains as well as the IP addresses required to access these domains.

Customers can pass in the enterprise proxy information during node boot up as shown in the examples below.

Note: In these examples, the enterprise proxy is available at http://10.9.8.1:3128.

When using cloud-init, customers will need to supply the enterprise proxy information via the proxy key as show below:

#cloud-config
write_files:
- path: /etc/vpm/user_data
  permissions: 0644
  owner: root
  content: |
    token: <generated-node-token>
    proxy: http://10.9.8.1:3128

Copied!

In VMware, the CE node OVA file has a vApp property called proxy, which can be used to supply the enterprise proxy information shown below:

Figure: VMware Property

With bare metal sites, the proxy can be defined as part of the admin command-line interface (CLI) configure-network step shown below:

Figure: Admin CLI Configure-Network

(B) Enterprise Proxy Daisy-Chained with F5 Single IP Endpoint

In this case, CE sites built using Secure Mesh Site v2 workflow will use the customer’s enterprise forward proxy to access the domains required for CE registration and upgrades, and the enterprise forward proxy will forward requests for domains required by CEs to the F5 single anycast IP endpoint. Therefore, the customer still needs to open the required domains but needs only to open a single IP address. In other words, you only need to open the F5 single IP address endpoint instead of the entire IP address list that would be required otherwise.

Note: In this reference example, all domains outside the domains that the Customer Edge (CE) requires will not be routed to the F5 single IP address endpoint. The enterprise proxy will handle them as required.

Passing in the enterprise proxy information is the same as when Using Enterprise Proxy Directly.

Below is an example of how to configure squid as an enterprise proxy. The configuration needed on squid is as follows:

$ cat /etc/squid/conf.d/f5xc.conf 
#
# F5XC proxy
#
cache_peer 159.60.141.140 parent 443 0 no-query
acl f5xc_domains dstdomain "/etc/squid/f5xcdomains.txt"
cache_peer_access 159.60.141.140 allow f5xc_domains
never_direct allow f5xc_domains

$ cat /etc/squid/f5xcdomains.txt 
*.volterra.io
docker.io
docker.com
gcr.io
storage.googleapis.com
update.release.core-os.net
quay.io
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
ifconfig.me