Discussion on IPSec NAT issues: Compatibility issues between IPSEC and NAT

1. Port compatibility issues

The source and destination ports used by IKE are both UDP 500. If there is port translation, the source port of IKE may be changed. If the responder judges that the port is not UDP 500, there may be a problem that the first phase of IPSEC negotiation fails. .

2. Address compatibility issues

When the IP address is encapsulated inside the message for some address information negotiation, if the message is transmitted in plain text, you can enable ALG on the NAT device to check and modify the content of these messages, such as FTP and H.323 protocols. However, once IPSEC is enabled, the NAT gateway cannot detect the passing message after the message is encrypted by ESP, so the internal address of the message cannot be modified, which means that there is a coexistence problem.

3. Checksum and NAT compatibility issues

Since the calculation of the checksum in TCP and UDP depends on the source and destination addresses in the IP packet, if the checksum of TCP or UDP is not modified at the NAT gateway, the checksum will fail. In the absence of IPSEC, NAT devices can modify TCP and UDP checksums. However, after IPSEC is enabled, the data packets are encrypted by ESP and the contents cannot be seen, so they cannot be modified.

In IPv4 packets, UDP checksum is optional, but TCP is required. However, in IPv6 packets, both TCP and UDP packet checksums are required. Therefore, the checksum is also problematic for IPSEC across NAT.

Introduction to IPSEC NAT Traversal (NAT-T) in IKE

I. Overview

IPSec provides end-to-end IP communication security, but in the NAT environment, the support for IPSec is limited, and the AH protocol is definitely not able to perform NAT, which is contrary to the concept of AH design; now it is encapsulated into UDP through ESP In the packet, multiple hosts can establish IPSEC tunnels with external peers.

2. IKE negotiation uses UDP encapsulation

RFC3947 mainly describes how to detect the presence of a NAT device and how to negotiate the use of UDP in IKE to encapsulate IPSec packets.

1. Ability testing

The function is to detect whether there is a NAT device in the communication and whether the other party supports NAT-T. NAT-T capability detection occurs in the first phase of IKE negotiation. And it is completed in the two message messages of 1 and 2 in the first stage, by adding a vendor ID payload to the message guarantee, which is defined in RFC3947, and the value is a hexadecimal number after passing the hash algorithm: vendor_id= 0x4a 0x13 0x1c 0x81 0x7 0x3 0x58 0x45 0x5c 0x57 0x28 0xf2 0xe 0x95 0x45 0x2f, this value is consistent in the first and second packets, and is used to detect whether the peer supports NAT-T. When the received IKE packet carries this value, it indicates that the peer device supports NAT-T.

The main function of the 3 and 4 messages in the first phase is to negotiate and confirm whether a NAT transfer has occurred during the transmission process. In the negotiation message, both parties must send at least two NAT-D payloads. The first payload is the HASH of the address and port of the other party, and the latter payload is its own address and port. If there are multiple addresses locally, multiple NAT-D payloads must be sent. After receiving the load, the other party calculates the HASH value according to the actual address and port of the received packet and compares it to know whether there is a NAT device and which party is behind the NAT device. If the hash value negotiated between IPSEC peers is the same as the hash value received, it means there is no NAT between them. Otherwise, the address and port are translated during transmission.

The negotiation mechanism is shown in the figure below:

2. UDP encapsulation negotiation

There are two UDP encapsulation methods, one is UDP channel mode encapsulation and the other is UDP transmission mode encapsulation, respectively expressed as follows:

UDP-Encapsulated-Tunnel

UDP-Encapsulated-Transport

UDP encapsulation IPSEC ESP traversal NAT analysis

1. Message encapsulation process

First, the original message is encapsulated by ESP according to the ordinary ESP message encapsulation process, and then a UDP message header is inserted into the red part as shown in the figure below, and finally a new IP message header is inserted to calculate the IP header of the final message Variable fields, such as total length, protocol ID, checksum, etc.

2. Message decapsulation process

First, remove the UDP header in the above figure, recalculate the variable fields in the IP vote, and then perform the ordinary ESP decapsulation process.

Ruijie Networks - Discussion on IPSec NAT issues: compatibility issues between IPSEC and NAT