Regional support and networking connections
Table of Contents
Expand all | Collapse all
-
- Activate Next-Generation Trust Security
-
-
- Configure AWS connection
- Configure Azure Key Vault connection
-
- Workload Identity Federation authentication
- Workload Identity Federation - Azure Identity Provider authentication
- Next-Gen Trust Security Generated Key authentication
- User permissions
- Workload Identity Federation authentication
- Next-Gen Trust Security Generated Key authentication
- User permissions
- Supported OIDC claims
-
-
-
-
- Create an F5 BIG-IP LTM machine
- Create a Microsoft Azure Private Key Vault machine
- Create a Microsoft IIS machine
- Create a Microsoft Windows (PowerShell) machine
- Create a Microsoft SQL Server machine
- Create a Common KeyStore machine
- Create a Citrix ADC machine
- Create an Imperva WAF machine
- Create a VMware NSX Advanced Load Balancer (AVI) machine
- Create an A10 Thunder ADC machine
- Create a Cloudflare machine
- Create Kemp Virtual LoadMaster machine
- Create a Palo Alto Panorama machine
-
- Provision to an F5 BIG-IP LTM
- Provision to a Microsoft Azure Private Key Vault
- Provision to Microsoft IIS
- Provision to Microsoft Windows (PowerShell)
- Provision to Microsoft SQL Server
- Provision to a Common KeyStore
- Provision to a Citrix ADC
- Provision to an Imperva WAF
- Provision to VMware NSX Advanced Load Balancer (AVI)
- Provision to an A10 Thunder ADC
- Provision to Cloudflare
- Provision to a Kemp Virtual LoadMaster
- Provision to Palo Alto Panorama
-
-
- 47-Day Validity Readiness TLS Certificates dashboard
- About the Certificate Inventory
- Managing certificate lifecycle settings
- Reissuing certificates in Next-Gen Trust Security
- Downloading certificates, certificate chains, and keystores
- Retiring, recovering, and deleting certificates
- Finding certificates in the certificate inventory
- Importing certificates from a CA using EJBCA
- Notification Center overview
- Domain-based validation for external emails
- Managing user accounts
- Troubleshooting
Regional support and networking connections
VSatellite requires connectivity with specific endpoints and ports over HTTPS when running the VSatellite install. The specific endpoints depend on your geographic region. VSatellite supports multiple regions so organizations can comply with local or organizational regulations and requirements to keep data stored in a specific region, and to comply with data privacy laws in various regions.
Required endpoints for all regions
- dl.venafi.cloud:443
- registry.venafi.cloud:443
Region-specific required endpoints
| Region | Code | Endpoint |
|---|---|---|
| United States | n/a | api.venafi.cloud:443 |
| Australia | au | api.au.venafi.cloud:443 |
| Canada | ca | api.ca.venafi.cloud:443 |
| Europe | eu | api.eu.venafi.cloud:443 |
| Singapore | sg | api.sg.venafi.cloud:443 |
| United Kingdom | uk | api.uk.venafi.cloud:443 |
Important (For VSatellites installed before 23 January 2025):Any VSatellites installed before 23 January 2025 will continue to require the following URLs:
- vsat-gw.venafi.cloud:9443
- vsat-gw.venafi.cloud:443
If you installed a VSatellite before this date, do not remove these URLs from your proxy configuration, as doing so will cause older VSatellites to stop functioning.
For new VSatellite installations starting January 23, 2025, use the applicable region-specific endpoint listed above. For example, in Australia, use api.au.venafi.cloud:443.
Optional: To migrate an existing VSatellite to use the updated URL (api.(region.)venafi.cloud), you can use a vsatctl command. For example:
| Region | Code | Command |
|---|---|---|
| United States | n/a | ./vsatctl update config --api-url https://api.venafi.cloud:443 |
| Europe | eu | ./vsatctl update config --api-url https://api.eu.venafi.cloud:443 |
Other regions are not listed because they were not available prior to 23 January 2025.
Verifying connectivity to required endpoints for region support
To verify connectivity to the required endpoints, you could use the cURL utility to request headers from each base URL. For example, for all regions:
curl -I https://dl.venafi.cloud
To also test your region-specific endpoint, use the command for your region from the following table.
| Region | Code | CURL command |
|---|---|---|
| United States | n/a | curl -I https://api.venafi.cloud:443 |
| Australia | au | curl -I https://api.au.venafi.cloud:443 |
| Canada | ca | curl -I https://api.ca.venafi.cloud:443 |
| Europe | eu | curl -I https://api.eu.venafi.cloud:443 |
| Singapore | sg | curl -I https://api.sg.venafi.cloud:443 |
| United Kingdom | uk | curl -I https://api.uk.venafi.cloud:443 |
If your connection is successful, you'll get a 404 error, which confirms that you did connect to the endpoints successfully. This is a rare case in which a 404 error actually means success.
If you don't have cURL, you can install it on Ubuntu using apt-get install curl or on RHEL using yum install curl.
Local server firewall configuration for VSatellite
Certain network ports must be open for VSatellites to function correctly. This is particularly important for enterprise environments where disabling the firewall (firewalld) isn't a viable option.
Necessary ports
Ensure the following TCP ports are open on the server firewall where VSatellite is running:
- 6443: Used by all nodes for communication with the K3s API server
- 10250: Needed for K3s metrics server functionality and to perform other important functions
These ports facilitate various functionalities essential for VSatellite.
Configuring firewall-cmd
To open the required ports, use the firewall-cmd command. Here are the commands for the necessary TCP and UDP ports:
firewall-cmd --permanent --add-port=6443/tcp
firewall-cmd --permanent --add-port=10250/tcp
After adding the ports, reload the firewall to apply the changes:
firewall-cmd --reload
Changing the default VSatellite (10.x.x.x) network CIDR range
To override the default VSatellite network CIDR ranges, you can set the following environment variables before installing VSatellite.
If you are installing VSatellite on the 10.x.x.x network, use the following settings:
export VSATELLITE_CLUSTER_CIDR=192.168.0.0/24 (default: 10.42.0.0/16)
export VSATELLITE_SERVICE_CIDR=192.168.1.0/24 (default: 10.43.0.0/16)
Use CIDR ranges that don't conflict with any of your internal networks.
Related links
- If you're deploying to RHEL, carefully review special considerations here