NAT Traversal (NAT-T) Security Issues (2024)

Network Address Translation (NAT) is a technology that has, in a small way, revolutionized Internet communications. NAT allows multiple computers on a LAN to share a single public IP address for accessing the Internet. Without it, the IPv4 protocol's limited number of available addresses would be pushed to its limits.

NAT also provides some measure of "cloaking" of internal computers, since they are "hidden" from external (Internet) computers that can only "see" the NAT device through which they connect.

NAT, however, has traditionally suffered from a big shortcoming. It's incompatible with Internet Protocol Security (IPSec), which is an increasingly popular way to protect the confidentiality and integrity of data while it's in transit over an IP network. The solution is NAT Traversal, or NAT-T. However, there are security problems related to NAT-T – or are there? Microsoft is recommending that IPSec/NAT-T not be used to connect a Windows XP client to Windows VPN servers that are behind NAT devices, and XP Service Pack 2 changes the default behavior to prevent IPSec/NAT-T security associations to servers behind a NAT. However, some security experts are saying this is overly cautious and the threat is more theoretical than real.

The problem with NAT and IPSec

Why doesn't NAT work with IPSec? Remember that the point of IPSec is not just to protect the confidentiality of the data, but also to assure the authenticity of the sender and the integrity of the data (that it hasn't been changed in transit). The problem with NAT is obvious: NAT must change information in the packet headers in order to do its job.

The first problem is that NAT changes the IP address of the internal computer to that of the NAT device. The Internet Key Exchange (IKE) protocol used by IPSec embeds the sending computer's IP address in its payload, and this embedded address doesn't match the source address of the IKE packet (which is that of the NAT device). When these addresses don't match, the receiving computer will drop the packet.

Another problem is that TCP checksums (and optionally, UDP checksums) are used to verify the packets. The checksum is in the TCP header and it contains the IP addresses of the sending and receiving computers and the port numbers used for the communications.

With normal NAT communications, this isn't a problem because the NAT device updates the headers to show its own IP address and port in place of the sending computer's. However, IPSec encrypts the headers with the Encapsulating Security Payload (ESP) protocol. Since the header is encrypted, NAT can't change it. This means the checksum is invalid, so the receiving computer rejects the packet.

In addition, NAT isn't able to use the port numbers in TCP and UDP headers to multiplex packets to multiple internal computers when those headers have been encrypted by ESP.

NAT-T: How it works

The IPSec working group of the IETF has created standards for NAT-T that are defined in RFCs 3947 and 3948. NAT-T is designed to solve the problems inherent in using IPSec with NAT.

NAT-T adds a UDP header that encapsulates the ESP header (it sits between the ESP header and the outer IP header). This gives the NAT device a UDP header containing UDP ports that can be used for multiplexing IPSec data streams. NAT-T also puts the sending computer's original IP address into a NAT-OA (Original Address) payload. This gives the receiving computer access to that information so that the source and destination IP addresses and ports can be checked and the checksum validated. This also solves the problem of the embedded source IP address not matching the source address on the packet.

Note:

This is a very simplified account of how NAT-T makes it possible for IPSec and NAT to work together. For more detailed information, see RFC 3947 and RFC 3948.

IPSec/NAT-T Security Issues

IPSec is a security protocol. When you circumvent its normal behavior, for example by making the header information that it normally encrypts available, it makes sense that the level of security that it provides may be compromised.

Microsoft recently revealed that the way IPSec and NAT-T work can cause a security threat wherein IPSec traffic intended for one computer may be routed to the wrong computer, if certain criteria exist. For more details, see KB article 885348 .

To prevent this problem, Microsoft recommends in the above referenced KB article that you not use IPSec/NAT-T when you have Windows Server 2003 VPN servers behind a NAT device. And to go further to prevent it, Windows XP SP2's default behavior will not allow an XP computer to establish an IPSec/NAT-T security association with a server that's behind a NAT.

Is this overkill? The KB article itself states that the situation described is an uncommon one, and several security experts have reported being unable to reproduce the problem. They also point out that by killing XP's ability to connect to servers behind a NAT, you force XP clients to use PPTP instead of L2TP for VPN connections to such servers, thus sacrificing the security advantages of L2TP.

Changing XP SP2 to allow IPSec/NAT-T

It's up to you to evaluate your own network infrastructure and security needs and decide whether the security threat posed by IPSec/NAT-T connections outweighs the security threat of using PPTP instead of L2TP.

If you decide you need L2TP, you have two choices. Microsoft's recommendation is that you give your VPN servers public IP addresses so clients can connect to them directly rather than through NAT. Of course, that involves its own security issues. Alternatively, you can edit the registry in Windows XP to restore the ability to connect to servers behind a NAT with IPSec/NAT-T. Here's how:

1. Navigate to the following registry key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IPsec.
2. Create a DWORD value named: AssumeUDPEncapsulationContextOnSendRule.
3. Set the value data to 2 to allow clients (whether they themselves have public IP addresses or are going through a NAT) to connect to a server that's behind a NAT.

Note:

You can allow only clients with public IP addresses to connect to servers behind a NAT by setting the value to 1. You can restore the SP2 default behavior (prevent all clients from connecting to servers behind a NAT) by setting the value to 0.

Summary

There is some controversy over whether the security risk of using Windows XP clients to connect to servers behind a NAT via IPSec/NAT-T is significant, and whether the default behavior introduced by XP SP2, which prevents this, creates more problems than it solves. If, after assessing the information available and your own network's security needs, you want to allow such connections, you can do so with a simple registry edit on the XP client computers.

Debra Littlejohn Shinder, MCSE, MVP (Security) is a technology consultant, trainer and writer who has authored a number of books on computer operating systems, networking, and security. She is also a tech editor, developmental editor and contributor to more than 20 additional books. Her articles are regularly published on TechRepublic's TechProGuild Web site and Windowsecurity.com, and have appeared in print magazines such as Windows IT Pro (formerly Windows & .NET) Magazine. She has authored training material, corporate whitepapers, marketing material, and product documentation for Microsoft Corp., Hewlett-Packard, DigitalThink, GFI Software, Sunbelt Software, CNET and other technology companies. She lives and works in the Dallas-Fort Worth area and can be reached at deb@shinder.net or at www.shinder.net.

Related:

• Security
• Networking
• Enterprise Applications
• Windows
• Small and Medium Business

It’s time to break the ChatGPT habit