This article provides a structured overview of NAT traversal in version 6.6.1, outlining its purpose, architecture, security model, prerequisites, configuration, and operational behavior. It also details troubleshooting guidance, known limitations, and expected improvements in 6.6.2, presenting the feature’s technical requirements and operational caveats in a clear, version‑specific context.
Introduction
NAT Traversal makes connectivity more flexible. This feature enables Clients to connect to Gateways behind a NAT, simplifies setup when Gateways switch IP address and removes the requirement for a public IP on Gateways.
Connect to GW behind NAT
No need to change firewall rules to allow the incoming traffic. This is especially useful when you do a PoC or quickly need to onboard a new site.
Handle GW changing IP
Gateways connected using Starlink will change it’s public IP continuously. With NAT traversal, the clients will be able to reconnect.
Only one public IP needed
In cases where public IPs are scarce, there will only be a need for the Connection Broker to be reachable by the Clients.
Architecture
NAT traversal in AppGate relies on a new Appliance function called “Connection Broker”. The Connection Broker is responsible for establishing the connection between the Client and the Gateway in case the Gateway is behind a NAT and cannot be reached directly by the Client.
The Connection Broker can serve one or multiple Sites. There can also be one or multiple Connection Brokers per site.
Security
All communications with the Connection Broker are protected by SPA when SPA-UDP-TCP is enabled. This ensures that the Connection Broker is invisible even though it’s exposed to the Internet.
Prerequisites
The Appliances needs to be version 6.6.1 and the clients needs to be version 6.6.2.
The Connection Broker appliance needs to have a public IP address and be reachable by both the Clients and Gateways on UDP/53 (SPA-DNS), UDP/443 and TCP/443.
DTLS is not supported as Site tunnel protocol with NAT traversal. Select QUIC (or TLS) as the tunnel protocol for Sites that should have NAT traversal.
The Connection Broker Appliance function can be combined only with Controller, LogServer or LogForwarder. We recommend running the Connection Broker combined with other Appliance functions for testing purposes only. It should run standalone in production environments as a lot of relayed sessions can impact performance.
Configuration
Enable the Connection Broker Appliance function on the Appliance. Then select the Sites that will use it under Broker configuration: one, multiple or all. Note that “Appliance Site” at the top of the form is just for log collection and metrics aggregation. It’s not configuring which sites to use with NAT traversal.
Operation
When the system is configured, the Gateways connect to the Connection Broker(s) and establish a TLS signaling channel.
The Client connection to a Gateway, in a Site configured to use the Connection Broker, happens 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 300 milliseconds, it starts trying STUN. The Connection Broker will then try to help the Client and Gateway establish a direct connection through the NAT using hole punching over QUIC.
Relay - If the connection cannot be established within 2.5 seconds, it starts trying to establish a relay connection over the site tunnel protocol. In this case, all the traffic between the Client and Gateway will be going through the Connection Broker. This adds a small latency and might incur traffic costs. We advise trying to avoid this traffic mode.
Whichever of the three steps above succeeds in establishing the connection first wins.
Operational feedback
Appliance
Statistics on relay traffic going through a specific Appliance can be seen under Appliance health. This is an aggregation of the traffic for all sites that the Connection Broker is serving.
Site
It’s possible to see how many sessions are being relayed for a specific Site. This is done by opening the Site Health Details and clicking “View relayed sessions”.
It is also possible to see statistics on how much traffic is being relayed and how many sessions have been established using hole punching (Direct via NAT Traversal).
Active sessions
It is possible to see the Connection type for each active session under the “Session Stats” tab. The different traffic modes are listed as:
Direct
Direct via NAT Traversal
Relay
This can also be seen 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. | Very high chance of “Direct via NAT Traversal”, relay almost never used. |
Restricted cone | Mapping 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 also depends on remote port. | Hole punching usually works; occasionally fallback to relay when filters are tight. |
Symmetric NAT | Public mapping may vary per destination; aggressive port rewriting. | Hardest case: many attempts at direct paths, but relay used more often. |
CGNAT / carrier NAT | Extra NAT layer at ISP; usually symmetric or port‑restricted. | Often can do direct if one side has friendlier NAT; otherwise, relay is common. |
Practical expectations
On “friendly” NATs (full/port‑restricted cone, endpoint independent behavior), most connections end up in “Direct via NAT Traversal”, with normal performance and latency.
On “hostile” NATs (symmetric, strict enterprise firewalls, some CGNAT setups), connections still succeed but fall back to using relay more often, with higher latency and lower throughput - due extra network hops.
Troubleshooting
Gateway has an Appliance error saying that STUN client initialization failed or STUN Binding Request failed
If there is an ISP which routes UDP and TCP individually between the Connection Broker and the Gateways, “UDP (and TCP) SPA” isn’t going to work as the UDP and TCP packets will have different IP addresses. In these cases, the Connection Broker Appliance needs to be set to override the SPA Mode with “TCP SPA”.
Verify that traffic to UDP/53 (SPA-DNS), UDP/443 and TCP/443 to the Connection Broker is allowed.
No connection can be established from the Client to the site
If there is an ISP which routes UDP and TCP individually between the Connection Broker and the Clients, “UDP (and TCP) SPA” isn’t going to work as the UDP and TCP packets will have different IP addresses. In these cases, the Connection Broker Appliance needs to be set to override the SPA Mode with “TCP SPA”.
Verify that traffic to UDP/53, UDP/443 and TCP/443 from the Client to the Connection Broker is allowed.
SSH into the Gateway and run the following command: sudo cz-console -d cz-proxyd -p to see that the Gateway sends NAT sockets correctly.
Traffic is always being relayed
Check that communication over the Tunnel protocol on port 443 is permitted bidirectionally between Client public NAT and Gateway public NAT; symmetric or very restrictive NATs may force relay usage (see Expected behavior based on NAT type section).
Make sure that the Connection Broker and Gateway aren’t on the same NAT. If they are, STUN will not be possible, as the Connection Broker won’t be able to know the public address of the Gateway.
Advanced Configuration
Any options related to NAT traversal can be elaborated using cz-config get/set <key> on the Connection Broker Appliance. The following keys are available:
Key | Description |
|---|---|
natt/relaySessionsThreshold | Sets an arbitrary number of sessions that the connection broker can handle before it emits a warning to the Admin UI. Once this watermark has been surpassed it is expected the Connection Broker will be overwhelmed and an additional connection broker appliance should be provisioned. |
natt/relayThroughputBitsPerSecondThreshold | Sets an arbitrary rate of bits per second on average over a default of a 10-minute window in which a connection broker is considered healthy if it is lower than this watermark. If this threshold is exceeded, it will display a warning on the Admin UI, and it is expected the Connection Broker will be overwhelmed and an additional connection broker appliance should be provisioned. |
natt/stunKeepaliveInterval | On initializing the Connection Broker or Gateway configurations it spins up multiple STUN clients using the UDP definitions defined in the configuration file. This value determines the length of time between keep alive communications to the underlying socket. This value is defined as the number of seconds between communications. |
Limitations/known issues
The following limitations/problems are addressed in later versions:
Mobile and Lite Clients do not support NAT traversal.
Only 1000 concurrent relay sessions are possible for each Connection Broker.
NAT traversal won’t work if SPA mode is UDP (and TCP) and the site has QUIC as the tunnel protocol.
If the Gateway uses an IP address in the Client Hostname/IP field, the Connection Broker will not work. The SAN IP of the Connection Broker must be added to Extra hostnames in the Gateway certificate, or ensure that the Gateway uses a hostname.