L2TP over IPSec and NAT -- NAT Traversal

This excerpt from e-book "The tips and tricks guide to securing Windows Server 2003" discusses the issues with IPSec and VPS using L2TP over IPSec.

The tips and tricks guide to securing Windows Server 2003 The following excerpt is from Chapter 7 of the free e-book "The tips and tricks guide to securing Windows Server 2003" written by Roberta Bragg and available at Realtimepublishers.com. Click for the complete book excerpt series.

L2TP over IPSec and NAT -- NAT Traversal

One of the issues with IPSec and hence VPNs using L2TP over IPSec is the inability to use them in natted environments. In a typical scenario, a VPN tunnel is used to provide access from outside the firewall to inside by opening the ports on the firewall used by the VPN. Both PPTP and L2TP over IPSec VPNs can be configured this way -- unless the firewall, router or other remote access device, which sits between the VPN client and the VPN server, uses NAT. The current IPSec standard does not address this issue, in fact, an implementation -- such as Win2K -- written to the standard, sees the NAT manipulation of the addressing as tampering and drops the packets.

The problem with NAT comes about because the NAT device must translates the source address, and might assign a new source port to maintain a table to be used in routing replies back to the originating host. Here's what's happening: The NAT device modifies an outgoing packet by changing the real source address, the address of the sending client, to that of the Internet routable address provided to the NAT device. When packets from the Internet return to the NAT device, it is able to modify the destination address (which arrives using the Internet routable address assigned as the source address of the outgoing packet). How does it know the new source address to use? It knows because it keeps a table of sources addresses and ports mapped to the assigned source address and ports it replaced in outgoing packets. It is able to match the incoming packets and modify the destination address and port. However, because of the built-in security mechanisms of IPSec such tampering with the address is not allowed, hence the packets are dropped. This is why a Win2K to Win2K VPN that must pass through a NAT device can only use PPTP.

Legacy clients, Windows 95, Windows 98 and Windows NT do not have native L2TP/IPSec ability to participate as VPN clients. However, Microsoft has recently released an L2TP/IPsec client for Windows 98, Windows ME and Windows NT 4.0 Workstation that can be downloaded at Microsoft's site. The client is just that, a client. It will not enable any of these clients to become a server and will not install on Window NT Server. It also will not install on Win2K or Windows .NET. The new client also supports NAT Traversal.

Before any NAT Traversal can occur, the client must be capable of recognizing the use of NAT, and the server must be NAT Traversal enabled. To fully understand the process, you should know something of how IPSec works. The following text explains, in simplified form, how NAT Traversal works. The client detects the NAT Traversal capability of the server by an exchange of strings (in the draft an MD5 hash of the draft title) during the first messages of IPSec, Phase I negotiation. (Phase I negotiation of IPSec includes establishment of IKE communications and generation of master key that is used in Phase II to generate encryption keys.) If the server does not return a message that includes the hash, it is not considered to be NAT Traversal enabled.

Next, the presence and location of a NAT device is detected by using the NAT-D payload message. To discover if NAT is being used, each side looks to see whether the IP address of the message has been modified. This is done by including a hash of the original source address and port. When received, a new hash of the existing source address and port is made. If the new hash matches the original (included in the payload), there is no NAT device in-between and processing continues per the IPSec standard. If the hash does not match, NAT is being used.

Although port 500 is the standard port for IKE traffic, IPSec-aware NAT devices may respond in a different way than standard NAT when they detect IKE traffic. Because NAT Traversal does not include the ability to determine exactly what an IPSec-aware NAT device is doing, moving or floating, the IKE traffic to port 4500 avoids the problems that the non-standard IPSec-aware NAT device may pose. Additional modifications such as the inclusion of a non-ESP marker may also be necessary. After the initial NAT Traversal communication is established, subsequent negotiations must start on port 4500. An illustration of the IKE floating can be found in Figure 7.27.

Figure 7.27: IKE floating.

Finally, negotiation of NAT Traversal encapsulation occurs. Normal IPSec negotiations include the use of either Tunnel or Transport modes. NAT Traversal requires the use of either of two new modes: UDP-Encapsulated-Tunnel and UDP-Encapsulated-Transport. Either of the modes allows NAT manipulation of the source IP and port information as this information is now available in a header designed for this purpose. Figure 7.28 is an example rendering of the UDP-Encapsulated-Transport mode.

Figure 7.28: UDP-Encapsulated-Transport mode.

Click for the book excerpt series or visit Realtimepublishers.com to obtain the complete book.

Read more on Antivirus, firewall and IDS products