When setting up VPNs with IPSec, it’s critical to understand how Network Address Translation (NAT) can interfere with tunnel stability and security, especially when using routers. Router flexibility comes with complexity, particularly when NAT or PAT is introduced between tunnel peers.

The Problem with NAT and ESP Packets

A common issue arises when Port Address Translation (PAT) exists between two routers configured for IPSec. The tunnel may appear functional, as it comes up normally and displays valid output with the ‘show crypto ipsec sa‘ command. But deeper inspection (e.g., checking EIGRP neighbors or routing functionality) reveals something’s wrong. The tunnel drops, and traffic fails to pass.

This is because ESP (Encapsulating Security Payload) packets, which are part of the IPSec protocol suite, are being altered by Network Address Translation (NAT). The ESP header is authenticated, and any modification, such as a PAT address change, invalidates the packet, causing the tunnel to silently break.

NAT-T: Fixing IPSec Tunnel Failures Behind NAT

To solve this, NAT Traversal (NAT-T) comes into play. NAT-T encapsulates ESP inside UDP on port 4500, which can traverse NAT devices without packet corruption. This feature is integrated into ISAKMP (IKE Phase 1) negotiation. When NAT-T detects a NAT device between peers, it automatically switches from ESP (protocol 50) to UDP/4500, ensuring seamless communication.

Here’s what happens during this process:

  • Initially, a packet may look like this:
    10.10.1.2 | ESP | 192.168.1.1 | DATA
  • After NAT/PAT, it becomes:
    192.0.2.1 | ESP | 192.168.1.1 | DATA

Since the receiving router expects the original address (10.10.1.2), the tunnel fails.

Diagnosing the Issue

Running the show crypto ipsec sa command can reveal mismatches in encrypted and decrypted packet counts. For example:

#pkts encrypt: 255, #pkts decrypt: 169

This discrepancy indicates broken tunnel communication.

Similarly, show crypto isakmp sa might show multiple attempts to negotiate with no success:

10.10.1.2 MM_SA_SETUP 0 ACTIVE
192.0.2.2 MM_NO_STATE 0 ACTIVE

The fix? Update the crypto key and tunnel destination to the NATed address:

crypto isakmp key key address 192.0.2.1
interface tunnel0
tunnel destination 192.0.2.1

Once applied, your show crypto isakmp sa should display a stable tunnel:

10.10.1.2 QM_IDLE 1010 ACTIVE

And traffic should now flow both directions, restoring EIGRP neighbor relationships and full tunnel functionality.

To verify the traffic is flowing and NAT-T is working correctly, use:

show crypto ipsec sa | inc ident|encr|decry

NAT-T Behavior and Debugging

You can confirm NAT-T detection using debug crypto isakmp. As the tunnel forms, the output will confirm:

NAT found, both nodes inside NAT
My hash no match — this node inside NAT

This indicates that NAT-T successfully negotiated the tunnel using UDP/4500. Additionally, the initiator will now use a non-standard port (not UDP/500), which is expected behavior when NAT is involved.

IPsec, NAT, and Firewalls

NAT-T is especially useful when dealing with firewalls. Here’s a quick rule of thumb:

  • No NAT? Open UDP 500 (ISAKMP) and protocol 50 (ESP).
  • With NAT? Just open UDP 4500 – ESP is encapsulated within it.

If you’re setting up routers like this:

R1 — [PAT Device] — R2

And the initiator sits behind the PAT device, ensure NAT-T is enabled and consider static NAT if you need deterministic behavior. Otherwise, NAT-T handles the encapsulation dynamically.

Conclusion

NAT Traversal (NAT-T) is essential in modern IPSec VPNs, especially when NAT or PAT is involved between peers. By encapsulating ESP in UDP packets, NAT-T ensures tunnel reliability, even when public addresses are being translated. Understanding how to troubleshoot and configure NAT-T can save hours of frustration and restore full routing and VPN functionality across your IPSec deployment.