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 188.8.131.52.
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 (184.108.40.206 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 (220.127.116.11 and 500): 8b44b859631968ceeb26b61430014fc6
The RTR-Site2 (18.104.22.168) device responds the following:
A HASH of Source IP address and port (22.214.171.124 and 500): 8b44b859631968ceeb26b61430014fc6 A HASH of Destination IP address and port (126.96.36.199 and 500): 66718a3d26322b74c7de2c87fb1ff4c9
The result is that the receiving device RTR-Site2 recalculates the hash based on the Destination Peer IP Address 188.8.131.52 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 184.108.40.206, 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.
Hello everyone, May i ask if there is a way to configure a dual wan load balancing with a 50%/50% ratio on both outside interface using FMC. Right now my current config is just basic failover. I have a FTD 5508X v220.127.116.11 and FMC v18.104.22.168&nb...
I am currently having issues establishing a IPSec Tunnel between a FTD and a IOS Router. It looks as if they get past Phase 1 but then perhaps fail on establishing the IPSec Tunnel. I have posted the IOS Configurations as well as my debug messages ...
Hi, we recently added Azure vNET's and infrastructure across an Azure Express Route. We have also deployed Azure File Shares and integrated them into Active Directory and created Private Endpoints. We have successfully setup the DNS both at our datacenter...
I've configured FMC to send Connection Events to an external syslog but not everything is being sent. I've taken some tcpdumps and only the events with some relevant impact are sent. I'm interested in sending every event, even the allowed ones. ...