IPSec NAT traversal Overview

Due to historical reasons, one of the problems with deploying L2 Tunneling Protocol (L2TP/IPSec) with Internet Protocol Security is that the IPsec dialogs after Network Address Translation (NAT) cannot be located. Internet service providers and small office/Home Office (SOHO) networks usually use NAT to share a single public IP address. Although Nat helps to save the remaining IP address space, it also brings problems to end-to-end protocols such as IPSec.

A new technology called IPSec NAT traversal (NAT-T) is being standardized by the IPSec network workgroup of the Internet Engineering Task Group. The IPSec NAT-T is described in the Internet Draft titled "uosec package's UDP envelope (draft-ietf-ipsec-udp-encaps-02.txt) and" nat in Ike gets through the Consortium (draft-ietf-ipsec-nat-t-ike-02.txt. The IPSec NAT-T modifies the negotiation process and defines different methods for sending IPSec-protected data.

During the IPsec negotiation, both parties supporting the IPsec NAT-T will automatically determine:

• Whether the Peer (usually a client computer) that initiates the IPsec conversation can execute IPSec nat-T with the peer (usually a server) that responds to the IPsec conversation.

• Whether any Nat exists in the path between them.

If both conditions are true, both parties will use the IPsec NAT-T to send IPSec-protected traffic through NAT. If one of them does not support the IPsec NAT-T, perform regular IPSec negotiation (after the first two messages) and IPSec protection. If both parties support the IPsec NAT-T but there is no Nat between them, perform regular IPSec protection.

IPSec NAT-T by Windows Server 2003, Microsoft L2TP/IPSec VPN Client (a free web download component that supports running Windows 98, Windows Millennium Edition, and Windows NT 4.0
Workstation computers create L2TP/IPSec connections) and L2TP/IPSec NAT-T Update for Windows XP and Windows 2000 (a free web download component, it supports creating L2TP/IPSec connections on Windows 2000 and Windows XP computers.

This topic studies issues associated with using IPsec through NAT, how these issues are addressed through an IPsec NAT-T, and Internet Key Exchange (IKE) for both fast and master Modes) changes in the negotiation results.

Note:The IPSec NAT-T is defined only for ESP traffic.

Content on this page

Problems related to using IPsec through NAT
Overview of NAT-T changes to IPSec
An IPsec NAT-T solution to an IPsec problem using NAT
Ike negotiation example of active mode and fast mode SA using IPsec NAT-T
More information

Problems related to using IPsec through NAT

Problems related to using IPsec through NAT are as follows:

• Nat cannot update upper-layer checksum.

  The TCP and UDP headers contain a Checksum, which integrates the source and target IP addresses and port numbers. When Nat changes the IP address and port number of a packet, it usually needs to update the TCP or UDP checksum. When the TCP or UDP checksum is encrypted using ESP, it cannot update this checksum. Because the address or port has been changed by Nat, the checksum of the destination fails. Although UDP checksum is optional, TCP checksum is required.

• Nat cannot transmit multiple IPSec data streams.

  The IPSec traffic protected by ESP does not contain visible TCP or UDP headers. The ESP header is located between the IP header and the encrypted TCP or UDP header, and uses IP protocol number 50. Therefore, TCP or UDP port numbers cannot transmit traffic to different dedicated network hosts. The ESP header contains a field named security parameters index (security parameter index, SPI. SPI is used in combination with the target IP address in the plaintext IP header and the IPSec Security Protocol (ESP or AH) to identify the IPSec Security Association (SA ).

  For incoming traffic to Nat, the target IP address must be mapped to a dedicated IP address. For multiple IPSec dialogs on the NAT private end, the destination IP address of the incoming traffic of multiple IPSec ESP data streams is the same address. In order to separate an IPSec ESP data stream from the other, the destination IP address and SPI must be tracked and mapped to a specific destination IP address and SPI.

  Because SPI is a 32-bit number, the probability that multiple private network clients use the same SPI value is very low. The problem is that it is difficult to determine which outgoing SPI value corresponds to which incoming SPI value.

  Nat cannot map SPI because the end of ESP contains a hashed message authentication code (HMAC), which verifies the ESP Protocol Data Unit (PDU) (esp PDU contains the ESP header, esp payload, and ESP tail). SPI cannot be changed before the HMAC value expires.

• The Ike UDP port cannot be changed..

  Some IPSec implementations use UDP port 500 as both the source and target UDP port numbers. However, for an IPsec contact after Nat, Nat changes the source address of the original Ike master mode package. According to the specific implementation method, Ike traffic from ports other than 500 may be discarded.

• Nat timeout of Ike UDP port ing may cause problems.

  UDP ing in Nat is usually deleted soon. The Ike traffic of the initiator creates a UDP port ing in Nat, Which is used during Ike negotiation in the initial master mode and quick mode. However, if the responder subsequently sends Ike messages to the initiator but does not provide UDP port ing, the messages will be discarded by Nat.

• Identification Ike payload includes the Embedded IP Address.

  For master mode and quick mode negotiation, each IPSec conversation Party sends an identification Ike payload, including the Embedded IP address of the sender. Because the source address of the sending node has been changed by Nat, the embedded address does not match the IP address in the IKE package. IPSec dialogs that verify the identification Ike payload IP address discard the packet and discard Ike negotiation.

Overview of IPSec NAT-T changes

The NAT-T changes IPSec as follows:

• UDP encapsulation of ESP

  The UDP header is placed between the outer IP header and the ESP header to encapsulate the esp pdu. The port used for UDP-encapsulated ESP traffic is the same as the port used for Ike.

• Modified Ike Header Format

  The IPSec NAT-T Ike header contains a new non-ESP marker field that allows the receiver to differentiate UDP-encapsulated esp pdu and Ike messages. After an intermediate Nat is determined, the dialogs that support the IPsec NAT-T begin to use the new Ike header.

• New nat-keepalive package

  This is a UDP message that uses the same port as Ike traffic. It contains a single byte (0xff ), used to refresh the UDP port ing in Nat for Ike and UDP encapsulated ESP traffic sent to a private network host.

• New vendor ID Ike Payload

  The new payload contains a well-known hash value, which indicates that the dialog party can execute IPSec nat-T.

• New nat-discovery (NAT-D) ike Payload

  The new payload contains a hash value, which integrates an address and a port number. During the master mode negotiation, the IPsec dialogs include two nat-discovery -one for the destination address and port, and the other for the source address and port. The recipient uses the nat-discovery payload to check whether a NAT-converted address or port exists after Nat, based on the changed address and port number, determine whether there is a conversation after Nat.

• New encapsulation modes for UDP-encapsulated ESP transmission mode and tunnel mode

  The two new encapsulation modes are specified during the fast mode negotiation. They are used to notify the IPsec dialogs to use UDP encapsulation for the esp pdu.

• New nat-original address (NAT-OA) ike Payload

  The new payload contains the original (unconverted) Address of the IPsec contact. For UDP-encapsulated ESP transport mode, each dialogs send NAT-OA Ike payload during fast mode negotiation. The receiver stores this address in the parameters used for SA.

Back to Top IPSec NAT-T solution for problems using IPsec through NAT

The IPSec NAT-T addresses the problem of using IPsec through NAT in the following ways:

• Problem:Nat cannot update the upper-layer checksum.

  Solution:By sending the original address in the NAT-OA Ike payload, the receiver has all the information required to verify the decrypted upper-layer checksum (source and target IP addresses and ports.

• Problem:Nat cannot transmit multiple IPSec data streams.

  Solution:By encapsulating the esp pdu using the UDP header, Nat can use the UDP port to transmit multiple IPSec data streams. The SPI in the ESP header is no longer necessary.

• Problem:The Ike UDP port cannot be changed.

  Solution:IPSec NAT-T dialogs can accept Ike messages from ports outside 500. In addition, to prevent Ike-aware from modifying IKE packets through NAT, the IPsec NAT-T dialogs change Ike UDP port 500 to UDP port 4500 During master mode negotiation. To allow Ike traffic to use this new UDP port, you may have to configure a firewall to allow UDP port 4500.

• Problem:The identification Ike payload contains the Embedded IP address.

  Solution:By sending the original address in the NAT-OA Ike payload, the recipient has the original address that can be used to verify the content of the identification Ike payload during fast mode negotiation. Since the NAT-OA Ike payload was not sent before the fast mode negotiation occurred, for the IPsec Implementation of the IP address in the identification Ike payload sent during the master mode, it will either not perform this verification, you can either verify the dialogs by using another mechanism (such as name verification.

• Problem:Nat timeout of Ike UDP port ing may cause problems.

  Solution:The Nat keepalive packet is sent regularly to refresh the UDP port ing of the IKE negotiation and UDP-encapsulated esp pdu in the NAT.

Back to header Ike negotiation examples for master mode and fast mode SA using an IPsec NAT-T

Adding new NAT-D and NAT-OA payload and UDP channel types will modify master mode and quick mode Ike negotiation. For example, the following table shows how a Windows-based IPSec dialogs that are authenticated using Kerberos use the vendor-ID and NAT-D Ike payload during fast mode negotiation. The additional Ike payload and message changes for the IPsec NAT-T are displayed in bold.

Master mode message for Kerberos authentication method

Master mode message	Sender	Payload
1	Initiator	Security Association (including proposal), Vendor ID,Vendor ID (NAT-T feature)
2	Responder	Security Association (including a selected proposal), Vendor ID,Vendor ID (NAT-T feature)
3	Initiator	Key Exchange (including Diffie-Hellman public key), nonce, Kerberos token (initiator ),NAT-D (destination address and port),NAT-D (source address and port)
4	Responder	Key Exchange (including Diffie-Hellman public key), nonce, Kerberos token (responder ),NAT-D (destination address and port),NAT-D (source address and port)
5 (encrypted)	Initiator	Identification, hash (initiator)
6 (encrypted)	Responder	Identification and hash (responder)

If both nodes support the IPsec NAT-T and there is at least one Nat between them, they will use the IPsec NAT-T option during fast mode negotiation. Assume that at least one Nat exists between the two dialogs. The following table shows the result of Quick negotiation.

Fast mode message

Fast mode message	Sender	Payload
1 (encrypted)	Initiator	Security Association (Includes recommendations, including selection of "UDP-encapsulated tunnel" or "UDP-encapsulated Transmission Tunnel" Modes), Identification (including secure traffic description), nonce,NAT-OA
2 (encrypted)	Responder	Security Association (including a Selected Suggestion), identification (including Security Traffic Description), nonce,NAT-OA
3 (encrypted)	Initiator	Hash
4 (encrypted)	Responder	Notification)

At the end of the quick mode negotiation, both IPSec dialogs have their original addresses, send nat-keepalive packets as needed, and use UDP encapsulation for esp pdu.