NOTE
This feature is currently in Beta. For more information, contact your AppGate representative.
Network address translation (NAT) traversal in AppGate ZTNA enables AppGate clients to connect to Gateways behind network address translation, or a NAT. It simplifies setup when Gateways are hard to reach, such as when they change IP addresses, and removes the requirement for a public IP on Gateways.
NAT traversal in AppGate relies on a Connection Broker appliance. When a Gateway is behind a NAT and cannot be reached by the client, the Connection Broker establishes the connection between the client and the Gateway. 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 when exposed to the internet.
Prerequisites for NAT traversal
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. 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 should run as a standalone appliance in production environments as a lot of relayed sessions can impact performance. If you want to combine Connection Broker with other appliance functions, it should be for testing purposes only. The Connection Broker function can be combined with Controllers, LogServers, or LogForwarders.
Configuring NAT traversal
For more information about configuring the fields for a Connection Broker, see the Broker Configuration section.
To configure NAT traversal, you will first enable the Connection Broker function on your appliance:
Navigate 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.
When the system is configured, Gateways connect to the Connection Broker(s) and establish a TLS signaling channel.
In a Site configured to use a Connection Broker, the client attempts to connect to a Gateway 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 tries to connect using STUN. The Connection Broker will then 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 tries to establish a relay connection over QUIC. In this case, all traffic between the client and Gateway will go through the Connection Broker. This adds a small latency and might incur traffic costs, so we advise avoiding this traffic mode.
Operational feedback for NAT traversal
You can view information about your Connection Brokers in the Appliances, Sites, or Active Sessions pages.
Appliance Health
To view the health of your Connection Brokers from Appliance Health Details:
Navigate 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 Health
To view the information about your Connection Brokers from Site Health Details:
Navigate 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 will be displayed for that Site.
Connection Brokers. Connection Brokers associated with the Site and their health status. You will also see the number of relayed sessions and the relayed data throughput for each Connection Broker.
Active Sessions
You can also view the connection type for a user in the Session Stats tab for an active session:
Navigate 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.
Troubleshooting NAT traversal
This section includes troubleshooting procedures for NAT traversal:
The Gateway has an appliance error stating that STUN Client initialization failed or a STUN Binding Request failed | Verify that traffic from UDP/53, UDP/443, and TCP/443 to the Connection Broker is allowed. |
The Gateway has an appliance warning stating that the NAT IP matches one of the Gateway’s IPs | This warning means that the Gateway is not behind NAT and NAT traversal will not be possible. This scenario will be supported in version 6.6.1. If you want to do this in version 6.6.0, SSH in to the Gateway and run the following command:
|
No connection can be established from the Client to the Site | Ensure that traffic is allowed up to all UDP ports on the Connection Broker (6.6.0-specific). Then SSH in to the Gateway and run the following command to confirm that the Gateway sends NAT sockets correctly:
|
Traffic is always being relayed | Check that UDP/443 is permitted bi-directionally between the AppGate client public NAT and the Gateway public NAT; symmetric or very restrictive NATs may force relay usage. |