How to Demystify NAT Traversal In IPSEC VPN With Simple Packet Capture

One of the biggest concept in VPN Technologies is NAT Traversal, like NAT Traversal in VOIP deployment with SIP Protocol, the history is always inside the payload to solve the Incompatibility between NAT and IPSEC like the Incompatibility between SIP protocol and NAT.

This interesting concept is discussed in many vendors courses, blogs and forums and this additional article I wrote is to demystify it with packet captures and simple words.

See below interesting details about NAT Traversal In IPSEC VPN.

IPsec uses ESP to encrypt all packet, encapsulating the L3/L4 headers within an ESP header. ESP is an IP pro

tocol but there is no port number (Layer 4). This is a difference from ISAKMP which uses UDP port 500 as its UDP layer 4.
Because ESP is a protocol without ports and at the other side the L4 information the , The NAT device can not change these encrypted headers and cannot perform PAT translation at the L4 level.

Below the telnet packet captured from PC-1 to PC-2, the Source port 30206 and the Destination Port 23 are encapsulated by ESP and both are encrypted. (I decrypted the packet to see how it looks the packet inside ESP after decryption at the RTR-Site2.

Without NAT Traversal and new UDP Encapsulation of ESP packets with source port 4500 and destination 4500, the NAT Device cannot do anything.
It is clear NAT and IPSec are incompatible with each other, and to resolve this NAT Traversal was developed. NAT Traversal adds a UDP header which encapsulates the IPSec ESP header. As this new UDP header is NOT encrypted and is treated as just like a normal UDP packet, the NAT device can make the required changes and process the message,

NAT Traversal performs two tasks:

Step-1: Detects if both VPN Devices RTR-Site1 and RTR-Site2 support NAT-T
Step-2: Detects if there is a NAT device along the path. It’s called NAT-Discovery.

Step-1 is performed in ISAKMP phase 1 ( Main Mode ) through the messages one and two as shown below between RTR-Site1 172.16.1.1 and RTR-Site-2 200.1.1.1.

If both devices support NAT-T, then NAT-Discovery is performed in ISKAMP Phase 1 through messages three and four as shown below.

How the VPN Devices RTR-Site1 and RTR-Site2 detect that there is a NAT device?

The answer is NAT-D payload, the RTR-Site1 device sent a NAD-ID payload, inside the NAT-ID payload there are a hash of the Source IP address and port (172.16.1.1 and 500) and a hash of the Destination IP address and port (200.1.1.1 and 500).

The RTR-Site1 device (172.16.1.1) sends the following:
A HASH of Source IP address and port (172.16.1.1 and 500): ab18C4efb950c61f568a636561764e6f
A HASH of Destination IP address and port (200.1.1.1 and 500): 8b44b859631968ceeb26b61430014fc6

The RTR-Site2 (200.1.1.1) device responds the following:

A HASH of Source IP address and port (200.1.1.1 and 500): 8b44b859631968ceeb26b61430014fc6
A HASH of Destination IP address and port (100.1.1.1 and 500): 66718a3d26322b74c7de2c87fb1ff4c9

The result is that the receiving device RTR-Site2 recalculates the hash based on the Destination Peer IP Address 100.1.1.1 and Port 500 which is 66718a3d26322b74c7de2c87fb1ff4c9 and compares it with the hash it received from RTR-Site1 which is ab18C4efb950c61f568a636561764e6f.
If they don’t match a NAT device exists. This is the case in our scenario, the values are different.

Now RTR-Site1 and RTR-Site2 agree that a NAT Device exists along the path.

Now the NAT Device is discovered, still in the IKE 1 phase 1, RTR-Site1 will change the UDP port 500 to UDP port 4500 as shown below in messages five and six.

Because the NAT-T, in IKE Phase 2 (IPsec Quick Mode) encapsulates the Quick Mode (IPsec Phase 2) inside UDP 4500 . After Quick Mode negociation is completed, the Phase 2 is now ready to encrypt the data and ESP Packets are encapsulated inside UDP port 4500 as well, thus providing a port to be used in the NAT device to perform port address translation.

UDP encapsulation is used to hide the ESP packet behind the UDP header. So that the NAT Device processes the ESP packet as a normal UDP packet.

In other words, RTR-Site1 encapsulates ESP packets inside UDP/4500 for Source and Destination Ports. After this encapsulation, now NAT device can translate the ESP packets. It will change the source port from 4500 to a random port and the source IP address from 172.16.1.1 to 100.1.1.1, and kept the destination port 4500
When a packet with source and destination port of 4500 is sent through a PAT device (from inside to outside), the PAT device will change the source port from 4500 to a random high port, while keeping the destination port of 4500.

Published by:

Redouane MEDDANE

Redouane MEDDANE is Cisco Instructor CCSI #35458, 3xCCNP Collaboration, Security and Enterprise and he a published author of some of the most important OSPF Protocol, Security and Collaboration books in the world titled OSPF Demystified With RFC, Network Security All-in-one, and Dial Plan and Call Routing Demystified on CUCM. He is also a blogger at ipdemystify.com and writes articles about collaboration and security to demystify the most complex topics. His books are known for their technical depth and accuracy especially the OSPF Demystified With RFC book, which is considered as the best OSPF book in the world and named "One of the best OSPF ebooks of all time" by BookAuthority It gives you a hint at the ability to explain complex topics with remarkable ease. He worked as a Cisco Instructor and consultant indifferent Cisco Learning Partner and awarded twice as Cisco Distinguished Instructor Award and Cisco Security Instructor Excellence Award on 2018 and 2019, and Cisco Collaboration Instructor Excellence Award on 2020. The Distinguished Instructor Award recognizes the top 5% of Cisco's most influential CCSI's who provide the highest quality training experience and demonstrate the best overall instructor performance across multiple Cisco technologie and Instructor Excellence Award recognizes the top 25% of elite CCSIs being recognized for delivering top quality training and maintaining high customer satisfaction in their field of expertise.

Categories Security2 Comments

2 thoughts on “How to Demystify NAT Traversal In IPSEC VPN With Simple Packet Capture”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s