Calculation of Authentication Header AH hash includes the whole IP header

• NAT breaks packet authentication/integrity Encapsulation Security Payload (ESP):

• Transport mode: Outer IP header is not protected, but encrypted payload might break NAT with NAT- unfriendly applications

• Tunnel mode: Outer IP header is not protected, addressing is hidden inside tunnel—no problems with NAT

© 2003, Cisco Systems, Inc. All rights reserved.

NAT and IPSec

IPSec supports two types of headers: the authentication header (AH) and the Encapsulated Security Payload (ESP) header. AH only supports authentication, ESP supports authentication and, optionally, encryption. Both the AH and the ESP support transport mode and tunnel mode.

Using NAT in the path of an AH-protected packet will break IPSec, because the AH encapsulation (transport or tunnel mode) uses the whole IP packet as an input to calculate the authentication hash. This causes the authentication check to fail due to hash mismatches when NAT is used.

Using NAT in the path of an ESP-protected packet can generally work with the following caveats

■ The ESP encapsulation always excludes the outer IP header for the authentication hash calculation. Therefore, NAT can change the addresses in the outer header (the original IP header in transport mode, the tunnel header in tunnel mode) without breaking IPSec authentication. If tunnel mode is used, the only addresses of IPSec peers are translated -such a setup should always work.

If ESP transport mode is used, NAT unfriendly applications will embed IP addresses on the application layer, and the NAT device will have no insight into the application stream, as all payloads are encrypted. Therefore, NAT-unfriendly applications will break when protected inside the ESP transport mode encapsulation.

Therefore, the simplest and best solution is to use ESP tunnel mode, if NAT needs to be performed somewhere in the packet path. Because the outer IP header is neither encrypted not authenticated, the use of NAT causes no problems.


The Internet Key Exchange (IKE) protocol is a simple UDP session with a source and destination port of 500. It is NAT friendly, and works over classic one-to-one NAT translation with no problems.

If pre-shared keys are used for authentication, the keys must be based on the global, not the local address of the peer behind the NAT device.

Implement NAT "Outside" IPSec_




Not Recommended:


© 2003, Cisco Systems, Inc. All rights reserved. DPP 1.0-2-1-30

Was this article helpful?

0 0

Post a comment