WindowsNetworking.com Monthly Newsletter of November 2008 Sponsored by: GFI
Welcome to the WindowsNetworking.com newsletter by Thomas W Shinder MD, MVP. Each month we will bring you interesting and helpful information on the world of Windows Networking. We want to know what all *you* are interested in hearing about. Please send your suggestions for future newsletter content to: email@example.com
The Network Address Translation (NAT) routing protocol allows multiple internal network clients to access the Internet through a NAT server that only has one or a handful of IP addresses. There are actually several types of NAT. The networking purist would maintain that the term NAT only applies when you map an IP address on the external interface of the NAT server to an IP address on the internal network. This type of NAT is more commonly known as "static NAT'. All packets to and from a particular IP address on the external interface of the NAT server are associated with a specific host on the internal network.
The type of NAT we normally work with is sometimes called "PNAT" (Port and Network Address Translation). This allows multiple clients on the internal network to use the same IP address on the external interface of the NAT server as their source address when communicating with Internet servers. The NAT server replaces the original source IP address and TCP/UDP port number (which together represent the original "socket" if you are working with a socket based application) with a valid public IP address and port number on its own external interface. The NAT server keeps track of the changes it made in its "NAT table" so that it can properly return packets to the internal network clients after the NAT server receives responses from the Internet servers.
NAT works because it can change network and transport layer header information. When the NAT server changes the source IP address on a packet, it changes the network layer header information. When the NAT server changes the UDP or TCP source port number, it changes the transport layer header information. There usually are no problems with changing this header information because the NAT server keeps track of the original packet configurations in its NAT table.
How IPSec Breaks NAT
You run into problems when you want to use IPSec based VPN technology to connect a VPN client behind a NAT server to an IPSec VPN server on the Internet. The reason for this is the IPSec protocols are designed to authenticate and/or encrypt information in the packet. When a NAT server tries to change the information in the packet, it will either cause the packet to be considered invalid by an IPSec protocol, or it will be unable to perform the translation because information the NAT protocol needs to access is encrypted.
The two IPSec protocols causing problems for NAT are the Authentication Header protocol (AH) and the Encapsulating Security Payload protocol (ESP). AH is used to authenticate packets while ESP can authenticate and/or encrypt packets. Both these protocols can work in transport or tunnel mode. Transport mode is used when you want to create a host to host connection. A host to host connection creates a tunnel used only by the machines representing the tunnel endpoints. On the other hand, Tunnel mode allows a tunnel client to connect to a tunnel server to access resources on the tunnel server and the network or networks behind the tunnel server.
AH in Transport Mode authenticates the entire packet from IP header to the end of the application layer data and trailers. AH in Tunnel Mode also authentications all headers from the IP tunnel header to the application layer data and trailers. ESP in Transport Mode authenticates from the ESP header to the ESP trailer and it encrypts the TCP/UDP header and application data, while leaving the IP header and ESP authentication trailer in the clear (no authentication or encryption).
What do you think a NAT server would do to AH in either transport or tunnel mode? AH has authenticated the entire packet from IP header to trailers. When the NAT routing protocol tries to change the IP and UDP/TCP header information, the AH protocol will balk, flag the packet as having its integrity violated, and drop it. This is the case with both AH transport and tunnel mode.
Now what do you think would happen with ESP packets? When using ESP in Transport mode, the IP header is in the clear, so the NAT routing protocol can change that without causing any problems. However, TCP/UDP header is encrypted! The translation will fail because the transport layer header is encrypted, and the NAT server that performs PNAT must be able to access and change this information. ESP in Tunnel Mode is possible for the packet header standpoint, but there are other issues related to IKE security negotiations that make IPSec through NAT fall apart.
NAT Traversal to the Rescue
It is clear that something has to change if you want to use an IPSec based protocol through a NAT server. The change proposed by the IETF is to encapsulate IPSec traffic in a UDP header which is not exposed to ESP (we would not even worry about AH because of its proclivity to authenticate the entire packet). UDP encapsulation allows the ESP protected packet to "traverse" the NAT server.
This type of UDP tunneling allows the source port and IP address to change because the tunnel headers are not affected by ESP. When the UDP packet arrives at the IPSec VPN server, the UDP header is removed and the VPN server can make an assessment regarding whether the packet is normal IPSec packet or an IPSec NAT Traversal packet. The entire process is referred to as "IPSec NAT Traversal".
IPSec NAT Traversal actually involves a negotiation of the NAT Traversal protocol between the VPN client and server, as described by the following steps:
While IPSec NAT Traversal does solve most of the major problems with passing IPSec packets through the NAT device, it can not solve all of them. The major problem lies in the fact that poorly designed protocols such as FTP, the H.323 protocol suite, LDAP and many others embed the actual source IP address in the application layer data.
A NAT device can usually get around this problem by using NAT editors to change the information in the application layer data so that the appropriate public IP address and ports numbers are used instead of the actual client. The NAT editor approach can not work with IPSec NAT Traversal because the application layer data is encrypted by ESP while it passes through the NAT device.
NAT is a useful routing protocol that allows us to continue using the venerable IPv4 addressing scheme for hopefully another decade or two. While NAT can easily translate both the source IP address and port number, the translation process strikes at the heart of both the AH and ESP protocols. While there is not much hope for AH, the IPSec NAT Traversal Protocol will allow you to use ESP in tunnel mode to connect your VPN clients behind a NAT server to an IPSec VPN server on the Internet. Of course, if you want to make your life easier and almost equally secure, you can use PPTP and take advantage of the NAT editor that comes with the Windows 2000 RRAS to pass PPTP through the NAT and to the PPTP VPN server on the Internet.
3. WindowsNetworking.com Articles of Interest
Have you noticed that some of your Vista machines lose their DHCP assigned IP addressing information even though they have a valid lease? This happens when the Vista client cannot communicate with a DHCP server. DHCP clients with unexpired leases should be able to keep their IP addressing information, even when there is no DHCP server. What's up with that?
You can add a Registry value to fix this problem. Try this out:
I noticed that when I ran the disk cleanup tool that my hibernation does not work anymore on my Vista computer. To make things worse, I can not find how to enable hibernation again! Can you help a guy out? Thanks! - Woody.
This problem happens when the disk cleanup tool disables the hibernation file on your hark disk. The reason why you can not find an interface for configuring hibernation on your Vista computer is that it doesn't exist! Yes, they took that out. Why? I don’t know, I was not at that meeting :)
However, there is a fix. Try this out:
Your computer will now be able to take advantage of hibernation again.
Got a question for Dr. Tom? Send it to firstname.lastname@example.org.