NOTE
This feature is currently in Beta. For more information, contact your AppGate representative.
This article provides a structured overview of NAT traversal, outlining its purpose, architecture, security model, prerequisites, configuration, and operational behavior. It also includes troubleshooting guidance, known limitations, and improvements.
Introduction
NAT Traversal makes connectivity more flexible. This feature lets clients connect to Gateways behind a NAT, simplifies setup when Gateways switch IP addresses, and removes the requirement for a public IP on each Gateway.
Connecting to a Gateway behind NAT. No firewall rules changes are required to allow incoming traffic. This is useful for a proof-of-concept or when you need to onboard a new Site quickly.
Handle Gateways with changing IP addresses. Gateways connected through Starlink change their public IP continuously. With NAT traversal, clients reconnect automatically when this happens..
Require only one public IP. When public IPs are scarce, only the Connection Broker needs to be reachable by clients.
Architecture
NAT traversal in AppGate ZTNA relies on a new appliance function called the Connection Broker. The Connection Broker establishes the connection between the client and the Gateway when the Gateway is behind a NAT and cannot be reached directly.
A Connection Broker can serve one or more Sites. You can also deploy one or more Connection Brokers per Site.
Security
All communications with the Connection Broker are protected by SPA when SPA-UDP-TCP is enabled. This keeps the Connection Broker invisible even though it is exposed to the internet. See Known issues for current limitations.
Prerequisites
The following are required before configuring NAT traversal:
A public IP address for the Connection Broker that is reachable by clients and Gateways on UDP/53, UDP/443, and TCP/443.
QUIC or TLS as the tunnel protocol for Sites with NAT traversal. DTLS is not supported for Sites with NAT traversal.
The Connection Broker as a standalone appliance. The Connection Broker function can be combined only with the Controller, LogServer, or LogForwarder functions. Combine the Connection Broker with other appliance functions for testing purposes only. In production environments, run it standalone—a lot of relayed sessions can significantly impact performance on a shared appliance.
Configuration
For more information about configuring the fields for a Connection Broker, see the Broker Configuration section.
To configure NAT traversal, enable the Connection Broker function on your appliance:
Go to Appliances (System > Appliances).
Select +Add to configure a new appliance.
Configure the necessary fields in the System Settings tab.
In the Functions tab, select the Connection Broker checkbox.
In the Broker Configuration section, select the Site or Sites that will use the Connection Broker for log collection and metrics aggregation.
When you have finished configuring the rest of the Connection Broker appliance, click Save.
NOTE
The Appliance Site field at the top of the page is used only for log collection and metrics aggregation. It does not control which Sites use NAT traversal.
Operation
After configuration, Gateways connect to the Connection Broker(s) and establish a TLS signaling channel.
When a client connects to a Gateway on a Site configured to use the Connection Broker, the system attempts connection in three steps:
Direct. The client first tries to connect directly to the Gateway using the Site tunnel protocol.
Direct via NAT Traversal. If the connection cannot be established within 500 milliseconds, the client starts trying STUN. The Connection Broker attempts to help the client and Gateway establish a direct connection through the NAT using hole punching over QUIC.
Relay. If the connection is not established within 2.5 seconds, the system attempts a relay connection over the Site tunnel protocol. In this case, all traffic between the client and Gateway passes through the Connection Broker. This adds latency and may incur traffic costs. Avoid this traffic mode where possible.
Whichever step succeeds first establishes the connection.
Operational feedback
Appliance
Statistics on relay traffic passing through a specific appliance are available under Appliance Health Details. To view the health of your Connection Brokers from Appliance Health Details:
Go to Appliances (System > Appliances).
Locate the Connection Broker and click on its health status in the Status column. This will open the Appliance Health Details window.
In the Appliance Health Details window, you will see a row for Connection Broker Health, which includes the appliance’s health status, relayed sessions, and the relayed data throughput.
Site
To view the information about your Connection Brokers from Site Health Details:
Go to Sites (System > Sites).
Select the status in the Health column to open the Site Health Details window.
In the Site Health Details window, you will see the following information related to your Connection Brokers:
Sessions. Depending on the Site, the number of Relayed Sessions, Direct Sessions, or Direct Sessions via NAT Traversal are displayed. Select View relayed sessions to see which specific sessions are being relayed. This is helpful in troubleshooting scenarios.
Connection Brokers. Connection Brokers associated with all Sites and their health status. You will also see the number of relayed sessions and the relayed data throughput for each Connection Broker.
You can also see statistics on the number of sessions and the volume of traffic relayed per appliance connected to the Site. These figures are totals for the appliance and not specific to the Site.
Active sessions
You can also view the connection type for a user in the Session Stats tab for an active session:
Go to Active Sessions (Usage > Active Sessions) and select the session.
Select the Session Stats tab.
The Traffic Mode row displays the connection type as Direct, Direct via NAT Traversal, or Relay.
Connection type is also visible in the Site details in the client.
Expected behavior based on NAT type
NAT type | Behavior (UDP mappings) | Expected NAT traversal result |
|---|---|---|
Full cone (endpoint independent) | One public IP:port per internal socket; any remote can send to that mapping. | High chance of Direct via NAT Traversal. Relay is almost never used. |
Restricted cone | Mapping is fixed but only hosts you’ve sent to can reply. | Hole punching works in most cases. Direct paths succeed most of the time. |
Port-restricted cone | Like restricted, but filtering depends on the remote port. | Hole punching usually works, but occasionally falls back to Relay when filters are tight. |
Symmetric NAT | Public mapping may vary per destination; aggressive port rewriting. | This is the hardest case. There are many attempts at Direct paths, but Relay is used more often. |
CGNAT/carrier NAT | Extra NAT layer at ISP; usually symmetric or port‑restricted. | Direct can be used if one side has a friendlier NAT; otherwise, Relay is common. |
Practical expectations
On friendly NATs—full cone or port‑restricted cone with endpoint independent behavior—most connections use Direct via NAT Traversal, with normal performance and latency.
On hostile NATs—symmetric NAT, strict enterprise firewalls, some CGNAT setups—connections still succeed but fall back to Relay more often, resulting in higher latency and lower throughput due to extra network hops.
Troubleshooting
Troubleshooting scenario | Resolution |
|---|---|
Gateway shows an appliance error stating STUN client initialization failed or STUN Binding Request failed |
|
No connection can be established from the client to the Site |
|
Traffic is always relayed | Depending on the NAT type, this may be expected. Symmetric or very restrictive NATs can force relay usage. See Expected behavior based on NAT type for details.
|
Contacting support
If none of the above steps resolve the issue, contact AppGate support. Include the following, captured while the client is attempting to connect:
Client log bundle
Appliance log bundle from all Connection Brokers and Gateways in the Site
Packet dumps from the client, Connection Brokers, and Gateways
Advanced Configuration
You can view and set NAT traversal options on the Connection Broker appliance using cz-config get/set <key>. The following keys are available:
Key | Default value | Description |
|---|---|---|
| 1,000 | The maximum number of sessions the Connection Broker handles before sending a warning to the admin UI. When this threshold is exceeded, the Connection Broker is considered overloaded. Provision an additional Connection Broker appliance. |
| 8,000,000,000 | The average bits-per-second rate over a 10-minute window above which the Connection Broker is considered overloaded. When this threshold is exceeded, a warning appears in the admin UI. Provision an additional Connection Broker appliance. |
| 15 | The number of seconds between keepalive communications on the underlying socket. When the Connection Broker or Gateway configurations initialize, multiple STUN clients spin up using the UDP definitions in the configuration file. This value controls how frequently those clients send keepalives. |
Scaling
vCPUs. Relay throughput scales with Connection Broker vCPU count up to approximately 16 vCPUs. Scaling beyond that provides diminishing returns. For relay-heavy deployments, 8–16 vCPUs is recommended.
RAM. The Connection Broker function uses relatively little memory. Plan for 8–16 GB RAM depending on appliance size and expected relay load. TLS relay requires approximately 60 KB of buffer per session; QUIC relay requires less.
CPU impact. In relay mode, the Connection Broker CPU is continuously loaded because all traffic passes through it. In Direct and Direct via NAT traversal modes, the Connection Broker CPU returns to near-idle after session establishment—only the Gateway CPU is loaded during data transfer.
The maximum number of concurrent relay sessions per Connection Broker depends on the tunnel protocol:
NAT mode | Tunnel protocol | Approx. max concurrent users |
|---|---|---|
Direct (for reference) | QUIC or TLS | ~5,000 |
Direct via NAT Traversal | QUIC | ~4,000 |
Relay | TLS | ~3,000* |
Relay | QUIC | ~1,000 |
These figures are from performance testing on dedicated hardware: Intel Xeon Gold 6526Y CPU with 32 cores, 64 GB RAM, and 25 Gbps NICs. Real-world capacity varies by hardware.
For relay-heavy deployments, plan for approximately one Connection Broker per 1,000 users in the worst case (all users on Relay QUIC), or one per 3,000 users if TLS Relay is used.
*The maximum concurrent Relay sessions per Connection Broker is limited to 1,000. See Advanced Configuration for information on how to update this threshold.
Known issues
The following limitations are addressed in later versions:
NAT traversal signaling is always over TCP, which can cause UDP-TCP SPA checks to fail when the ISP routes UDP and TCP through different paths. The workaround is to use TCP-only SPA mode, but this removes Connection Broker cloaking. Will be fixed in 6.7.2.