Jaa


NAT-T Overcomes NAT and IPsec Problems

====================== DISCLAIMER ====================
This posting is provided "AS IS" with no warranties, and confers no rights.
====================================================

The last post talked about how NAT and IPsec don’t work well together. There is a solution, however, in NAT Traversal or NAT-T. Basically, NAT-T (IETF RFC 3947 and 3948) detects the presence of any NAT devices between two hosts, uses a non-IPsec port and encapsulates the IPsec traffic in UDP. NAT-T does this by inserting an additional header between the IP header and the ESP header. This header contains the original source and destination ports.

About NAT
Network Address Translation (NAT) was developed to answer the impending problems of the dwindling supply of IPv4 addresses (there can be “only” 4 billion of them, plus some spare change) and the nightmare of having to centrally distribute and manage off of these IP addresses. This must be done centrally so that everyone has an absolutely unique address. These two problems make using all unique IPv4 addresses impossible.

So certain IP address ranges were set aside (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16) for “private” addresses that companies could use freely inside their domains. These private addresses were then used behind a “public” and unique IP address (centrally managed). This public IP addresses is the one you register with InterNIT or some other IP address distribution organization or company.

NAT was developed as a way of solving the problem that Bob inside company A would have the same private address as Alice inside company B. NAT also is a way of mapping the internal / private addresses with the public / unique address so that Bob and Alice can communicate across the Internet, even though they have the same IP addresses. How NAT does this is beyond the scope of this post.

How NAT-T Solves the Problems Between IPsec and NAT
In the same way that NAT was a solution to the IP addresses problems of IPv4, NAT-T is a solution for the problems between IPsec and NAT mentioned earlier. In this ever-dynamic game of technological cat-n-mouse, the IETF has come up with RFCs that define how NAT-T does this.

The heart and soul of NAT-T is UDP Encapsulation, or the encapsulation of the IPsec part of the IP packet in yet another UDP header between the ESP portion of the packet and the (copied and subsequently changed) original IP header. That way the NAT device can access and change the IP address and port number information.

NAT-T also allows two additional benefits. To quote form the OSR Online article:

After IKE peers initiate negotiation on port 500, detect support for NAT-traversal, and detect a NAT or NAPT along the path, they can negotiate to "float" IKE and UDP-ESP traffic to port 4500…Floating to port 4500 for NAT traversal provides the following benefits: It bypasses "IPSec-aware" NATs or NAPTs that break UDP-ESP encapsulation on port 500 [and] It improves performance. The UDP encapsulation of ESP data packets is more efficient on port 4500 than on port 500.”

Sources For This Post
I want to acknowledge the following Web sites/Organizations for the information I stole gleaned form their sites:

OSR Online, strangely enough, a Web site about Windows Driver development, (www.osronline.com). the information about NAT-T was well written and concise. The article I read was “Traversing NATs and NAPTs with UDP-Encapsulated ESP Packets” - https://www.osronline.com/ddkx/network/209offl_4tev.htm

ISP Planet (www.isp-planet.com). The articles I read were:
“Slipping IPsec Past NAT” - https://isp-planet.com/technology/2001/ipsec_nat.html
“IP Security and NAT: Oil and Water?” - https://www.isp-planet.com/technology/nat_ipsec.html

Comments