NAT and IPSEC Interoperability

After close to three weeks of silence... Here is the post I promised in my last post.

I have decided to avoid configurations in this post. The theory is boring enough :-)

We are going to examine two scenarios;

Scenario 1: The VPN device also performs NAT.

If the edge router/ASA does NAT and VPN, there are two basic options available;
1. Exclude the interesting traffic from the NAT pool
On a router, a route-map can be used to reference an access-list which excludes the VPN traffic from being 'NATTED'

On the ASA, the nat 0 command is used for nat exemption

2. If NAT is enabled for the VPN traffic. The order of operation must be understood.

The Cisco IOS order of operations performs NAT Translation before the crypto map is matched. The access-list specified on the crypto map must match the GLOBAL (Translated) address. Encryption occurs after translation.

The return traffic, decryption occurs before, before NAT Translation is performed.

Scenario 2: There is a NAT device on the path.
Remote Access VPN clients might have to establish a tunnel through a router (might be the local gateway) performing NAT. The inherent problems with this are described in RFC 3715.

The solution to this problems are described in RFCs 3947 and 3948. From a configuring standpoint, there's little to be done. The peers automagically detect a NAT detects a NAT device in between and switches to UDP encapsulation for NAT by default. The new UDP packets must be allowed by any access-lists for this to work.

Since NAT configuration is common in many network environments, It is required for network engineers to have a thorough understanding of the concept.

For Further Reading:

NAT Order of Operation

IPSec NAT Transparency

RFC 3715 IPsec-NAT Compatibility Requirements

RFC 3947 Negotiation of NAT-Traversal in the IKE

RFC 3945 UDP Encapsulation of IPsec ESP Packets