---
title: "Configuring and troubleshooting NAT Traversal in AppGate"
slug: "nat-traversal-in-appgate-v6-6"
description: "AppGate ZTNA simplifies NAT traversal, enabling secure client connections to Gateways without public IPs, enhancing performance and connectivity."
updated: 2026-05-22T15:02:28Z
published: 2026-05-22T15:02:28Z
canonical: "support.appgate.com/nat-traversal-in-appgate-v6-6"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://support.appgate.com/llms.txt
> Use this file to discover all available pages before exploring further.

# NAT Traversal in AppGate

> [!NOTE]
> 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](/v1/docs/nat-traversal-in-appgate-v6-6#limitationsknown-issues1) for current limitations.

## Prerequisites

The following are required before configuring NAT traversal:

- Appliances must be on version 6.6.1. Clients must be on version 6.6.2.
- ***A public IP address*** for the Connection Broker that is reachable by clients and Gateways on UDP/53, UDP/443, and TCP/443. In case traffic should be relayed, the Connection Broker needs to be reachable on all UDP ports (6.6.0-specific).
- ***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*](/v1/docs/broker-configuration-v6-6) *section.*

To configure NAT traversal, enable the Connection Broker function on your appliance:

1. Go to **Appliances** (System > Appliances).
2. Select **+Add** to configure a new appliance.
3. Configure the necessary fields in the [**System Settings**](/v1/docs/system-settings-v6-6) tab.
4. In the **Functions** tab, select the **Connection Broker** checkbox.
5. In the [***Broker Configuration***](/v1/docs/broker-configuration-v6-6) section, select the Site or Sites that will use the Connection Broker for log collection and metrics aggregation.
6. When you have finished configuring the rest of the Connection Broker appliance, click **Save**.

> [!NOTE]
> 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:

1. **Direct.** The client first tries to connect directly to the Gateway using the Site tunnel protocol.
2. **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.
3. **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:

1. Go to **Appliances** (System > Appliances).
2. Locate the Connection Broker and click on its health status in the ***Status*** column. This will open the **Appliance Health Details** window.
3. 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**:

1. Go to **Sites** (System > Sites).
2. Select the status in the ***Health*** column to open the **Site Health Details** window.
3. 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:

1. Go to **Active Sessions** (Usage > Active Sessions) and select the session.
2. Select the **Session Stats** tab.
3. 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** | - If your ISP routes UDP and TCP traffic through different paths between the Connection Broker and the Gateways, UDP (and TCP) SPA will not work because the UDP and TCP packets arrive from different IP addresses. Set the Connection Broker appliance to override the SPA mode to **TCP SPA**. This will be resolved in the 6.7.2 appliance—after that fix, the solution is to change the site protocol to QUIC. - Verify that traffic to UDP/53 (SPA-DNS), UDP/443, and TCP/443 to the Connection Broker is allowed. - Run packet dumps on the Gateway and the Connection Broker. If SPA packets are missing on the Connection Broker side, the ISP may be blocking them. The workaround is to switch the Connection Broker SPA mode to **TCP only**. |
| **No connection can be established from the client to the Site** | - If your ISP routes UDP and TCP traffic through different paths between the Connection Broker and the clients, UDP (and TCP) SPA will not work because the UDP and TCP packets arrive from different IP addresses. Set the Connection Broker appliance to override the SPA mode to **TCP SPA**. This will be resolved in the 6.7.2 client and appliance—after that fix, the solution is to change the site protocol to QUIC. - Verify that traffic from the client to the Connection Broker on UDP/53, UDP/443, and TCP/443 is allowed. - Run packet dumps on the client and the Connection Broker. If SPA packets are missing on the Connection Broker side, the ISP may be blocking them. The workaround is to switch the Connection Broker SPA mode to **TCP only**. |
| **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](/v1/docs/nat-traversal-in-appgate-v6-6#expected-behavior-based-on-nat-type) for details. - Verify that communication over the tunnel protocol on port 443 is permitted bidirectionally between the client public NAT and the Gateway public NAT. - Confirm that the Connection Broker and Gateway are not behind the same NAT. If they are, STUN is not possible because the Connection Broker cannot determine the Gateway's public address. - Download the Connection Broker appliance log bundle, open `system-info.txt`, and find the `cz-console -d cz-proxyd -p` section. Confirm that the STUN server has at least one address. If it is not running, contact AppGate support. - While connecting, run packet dumps on the client, Gateway, and intermediary points to identify where hole punching is failing. |

#### 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 |
| --- | --- | --- |
| `natt/relaySessionsThreshold` | 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. |
| `natt/relayThroughputBitsPerSecondThreshold` | 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. |
| `natt/stunKeepaliveInterval ` | 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](/v1/docs/nat-traversal-in-appgate-v6-6#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.**
- Mobile and lite clients do not support NAT traversal. **Fixed in 6.7.0 clients.**
- NAT traversal does not work when SPA mode is UDP (and TCP) and the site uses QUIC as the tunnel protocol. **Fixed in 6.6.2 Appliance.**
- If the Gateway uses an IP address in the ***Client Hostname/IP*** field, the Connection Broker will not work. Add the SAN IP of the Connection Broker to ***Extra hostnames*** in the Gateway certificate, or ensure the Gateway uses a hostname instead of an IP address. **Fixed in 6.7.0 Appliance.**
- The UDP/STUN port on the Connection Broker uses the same port number as the configured TCP port instead of the configured Broker port number. **Fixed in 6.6.3 Appliance.**