Limitations when using the NAT-T function with IKEv2

Endpoints behind network address conversion (NAT) devices must protect their traffic that uses the Encapsulating Security Payload (ESP) protocol.

The ESP protocol is the main header that is selected by AIX IP Security (IPsec), and the ESP protocol is used by most of the applications. The ESP protocol includes hashing of the user data, but does not include hashing of the IP header. The integrity checking in the Authentication Header (AH) protocol incorporates the IP source and destination addresses in the message integrity check that uses a key. The NAT devices change the IP address fields of the packets that are sent by the initiator node or responder node and invalidates the message integrity check. Therefore, if only the AH protocol is defined in the Phase 2 exchange for a tunnel, and the NAT device is detected in a Phase 1 exchange, a Notify payload packet that states NO_PROPOSAL_CHOSEN is sent to the responder node.

AIX IP Security (IPsec) can support signature mode authentication only in the Phase 1 exchange. You must not define a pre-shared key for the tunnel that is behind a NAT device.

The AIX device can be an initiator node only if the AIX device is behind a NAT device. If the AIX device is a responder node, it can detect the presence of a NAT device along the path of the tunnel and can send or receive UDP encapsulated packets. An AIX device can be an initiator node or a responder node. However, the responder node must be on a public static IP address.

Additionally, a connection using a NAT device must select tunnel mode so that the original IP address is encapsulated in the packet. Transport mode and corresponding addresses are not compatible with the NAT traversal. If a NAT device is detected and only transport mode is proposed in phase 2, a Notify Payload saying NO_PROPOSAL_CHOSEN is sent.