IPsec NAT Traversal

The NAT technology is mainly used to address the IPv4 address shortage issue. The NAT is widely applied on the network, especially on egress gateways of enterprise networks. IPsec ensures end-to-end IP communication security and achieves low-cost secure interconnection between different branch networks of an enterprise. However, IPsec and NAT have some incompatibility problems.

The NAT modifies IP addresses in IP packet headers to implement address translation.
IPsec encrypts and checks data to ensure data security. AH is mainly used to ensure the message integrity, including the IP packet header carried in a message. Because the IP packet headers are modified by NAT, the IP packet header verification by AH fails. Therefore, an IPsec tunnel protected by AH cannot traverse the NAT gateway. Packets encrypted by ESP do not encounter this problem because the integrity verification by ESP does not include IP packet headers (outer IP packet header in tunnel mode).

However, a new incompatibility problem arises. When the NAT changes the IP address and (or) port number in a packet, the NAT generally updates the TCP or UDP checksum. If the TCP or UDP checksum is encrypted by ESP, the NAT cannot update the checksum.

Transport mode of ESP encapsulation: In this mode, a TCP or a UDP packet header is encrypted by ESP. The checksum cannot be changed. Because the IP address or port number is modified by the NAT, the checksum check at the destination end fails. As a result, the ESP-encapsulated transmission mode cannot coexist with the NAT.
Tunnel mode of ESP encapsulation: In this mode, the entire original IP packet is encrypted, and an outer IP header is added to the ESP header. Therefore, if the NAT changes only the IP address in the outer IP header, subsequent operations are not affected. Therefore, the tunnel mode of ESP for encapsulating IPsec packets can coexist with the NAT.

Processing of IPsec NAT Traversal

The IPsec NAT traversal process is as follows:

NAT-Traversal (NAT-T) capability detection: Both ends of an IPsec tunnel need to negotiate the NAT traversal capability, using a group of data identified by the Vendor ID payload, in the first two IKE negotiation messages.
NAT gateway discovery: The NAT-Discovery (NAT-D) payload is used to discover the NAT gateway between IKE peers and determine the NAT device position. The peer whose IP address needs to be translated serves as the initiator and periodically sends NAT-Keepalive packets so that the NAT gateway can ensure the active state of security tunnels.
ESP packets normally traversing the NAT gateway: When an IPsec packet traverses the NAT gateway, a standard UDP packet header is added between the original IP header and the ESP header (AH is not applied). When the ESP packet traverses the NAT gateway, the NAT translates the address and port number in the outer IP header and added UDP header. When the translated packet reaches the peer end of the IPsec tunnel, it is processed as a common packet. However, in a response packet, a UDP header also needs to be added between the IP header and ESP header. In this mode, ESP-encapsulated packets can traverse the NAT gateway in both transport mode and tunnel mode. Figure 1 shows the format of a packet added with the UDP header transmitted in transport mode and tunnel mode.
Figure 1 Format of a packet added with the UDP header transmitted in transport mode and tunnel mode.

IKEv2 and NAT Traversal

NAT-T Capability Detection

The NAT-T capability detection is performed by inserting a Vendor ID payload that identifies the NAT-T capability in the first two IKE negotiation messages. If both parties insert the payload in the messages sent to the peer party, both parties support the NAT-T. Other negotiations can be performed only when both parties support the NAT-T.

NAT Gateway Discovery

When NAT devices exist, data must be transmitted by using UDP. Therefore, at the first phase of IKEv2 negotiation, NAT devices must be detected.

The popular method for detecting NAT devices is to send the NAT-D payload.

In the IKE protocol, the NAT-D payload is contained in the third and fourth messages in main mode and the second and the third messages in aggressive mode. For the parties that create the VPN connection, a message generally contains two consecutive NAT-D payloads. The first NAT-D payload contains the destination IP address and the second contains the source IP address. The sender has several interfaces and the application program does not know through which interface the data packets go out. If the sender does not know its exact IP address, more NAT-D payloads are needed. Except the first payload, each of the payloads contains an IP address of the sender. After receiving the NAT-D payloads, the two parties compute and compare the hash values based on the actual IP addresses and port numbers to decide whether there is a NAT device and which party is behind the NAT device. This method can detect whether NAT devices exist between two IKE parties, but it has obvious defects. In main mode and aggressive mode, the NAT-D payloads are not authenticated. Therefore, attackers can delete, change, or add payloads to launch DoS attacks. By changing the NAT-D payloads, the attackers can induce the two parties to adopt the UDP encapsulation mode rather than the normal mode. As a result, bandwidths may be wasted.

To correct the preceding defects, two Notify payloads can be added for IKE of both negotiation parties. One Notify payload contains NAT_DETECTION_SOURCE_IP, which identifies the IP address of the sender. The other Notify payload contains NAT_DETECTION_DESTINATION_IP, which identifies the IP address of the receiver. The two Notify payloads mainly help to detect NAT devices and decide which party is behind NAT devices.

This is accomplished during the first message exchange of IKEv2 negotiation. The specific process is as follows:

In IKEv2, the number of NAT_DETECTION_SOURCE_IP is 16388 and the number of NAT_DETECTION_DESTINATION_IP is 16389 in the Notify messages. The payloads use the generic ISAKMP payload header. The values of the payloads are the hash values (IKEv2 uses SHA-1) of SPIs, IP addresses, and numbers of the ports for sending data packets. The hash value is computed as follows: hash = SHA-1 (SPIs|IP|Port).

SPI: the security parameter index in the HDR payload
IP: the IP address of the sender or receiver of data packets
Port: the port number of the sender or receiver of data packets

When the receiver receives a data packet, it computes the hash value with the SPIs, IP address, and port number in the packet. Then it compares the hash value with that of the Notify payload. If the hash values do not match, it indicates that a NAT device exists in the communications link. If the hash value does not match that of NAT_DETECTION_SOURCE_IP, it indicates that the sender is behind the NAT device. If the hash value does not match that of NAT_DETECTION_DESTINATION_IP, it indicates that the receiver is behind the NAT device.

Enabling the NAT Traversal

After the phase-1 negotiation is complete, both parties are clear about whether a NAT device exists between them and the NAT device position. The quick negotiation mode determines whether to enable the NAT traversal.

The negotiation enabling for NAT traversal is performed using the SA payload in quick mode. In transport mode, both parties send the original address of the IPsec packet during the negotiation, so that the peer party can check and rectify the TCP or IP header if the NAT is performed.

NAT-keepalive

A NAT session has a certain survival period on the NAT gateway. After a tunnel is established, if no packet traverses the gateway for a long period of time, the NAT session is deleted. As a result, data cannot be transmitted over the tunnel. A NAT-keepalive message can be sent to the peer party before the NAT session expires to maintain the NAT session and address the preceding issue.