10.7 Integrating Network Address Translation (NAT) and IPSec

10.7 Integrating Network Address Translation (NAT) and IPSec

A common issue that must be considered when considering a VPN solution is the integration of IPSec with network address translation (NAT). While many purists feel that NAT disrupts end-to-end connections on the Internet and thus breaks one of the primary intents of the Internet standards, the fact is that NAT is here to stay. It is useful as part of a firewall and it allows organizations to number their internal networks as they desire and use a minimum of IP addresses. In the United States, blessed from the beginning with an abundance of IPv4 addresses, the eventual transition to IPv6 has been somewhat forestalled by the prevalence of NAT. For most network administrators, NAT is a proven technology that has minimum impact on the configuration of their networks, unlike IPv6.

As a quick refresher, NAT is the process of changing a packet sent from the inside of a company network to the Internet. The source of the packet is changed from the original private address to a public address that allows the remote Internet host to respond back to the original client. Unfortunately, the process of changing the IP header will break certain modes of IPSec.

NAT's problems with IPSec can sometimes be difficult to diagnose if you are not familiar with the IPSec process. Remember that IPSec needs two separate processes to occur before a connection can be established. The first of these is the key exchange process with IKE. Then the actual data is sent using AH or ESP. It is common for the IKE process to succeed; but because NAT is attempting to modify information protected by the AH or encrypted by the ESP, the packets containing data fail. This presents itself as a situation where an IPSec SA has been established but traffic between the two hosts fails. This problem is normally due to one of several circumstances that depend on the operation of IPSec that is being attempted. The first major issue is that of using either the AH or the ESP. The second issue is the decision to use transport mode or tunnel mode.

To begin with, NAT and the IPSec AH will not interoperate. This is because the entire purpose of AH is to make sure that the entire packet, including the IP header, has not been altered in transit. Because this is exactly what NAT does, any attempt to authenticate the header by the remote side will fail. Tunnel mode and transport mode will both fail equally. Thus, if your security policy dictates that authentication of packets must be done, yet your network requirements suggest the use of NAT, then some other method of authentication must be performed. ESP with the authentication options enabled is a good place to start.

With ESP, the possibilities of proper NAT operation allow the use of tunnel mode or transport mode. Recall from our earlier discussion the operation of the TCP/UDP headers and the operation of NAT. TCP and UDP packets contain a checksum that is not only a check of the TCP data, but also the pseudo-header. The pseudo-header contains information found in the IP header, including the IP addresses. When NAT changes the IP header, it must also reach into the transport layer header and change the checksum; otherwise, the receiving host will discard the packet as an error because the checksums do not add up. If ESP encrypts the transport information, however, the checksums cannot be changed. Likewise, if the ESP authentication option is used, and the checksum could be changed, authentication of the packet at the IPSec level would fail due to the packet having been altered after being sent.

With the above options eliminated, really the only hope we have for NAT and IPSec working together remains the use of ESP and tunnel mode. Because tunnel mode completely encapsulates the original packet, NAT only needs to work on the outermost IP header, which of course does not affect the original packet that has been encrypted by the ESP.

Alas, if only it were that easy. Even using our one best hope for IPSec and NAT to work together, we will see that there are a number of places where things can go wrong. First, the common NAT implementation of port address translation (PAT) will not work. Remember that the protocol headers for tunnel mode ESP are as shown in Exhibit 18.

Exhibit 18: NAT Cannot Operate Correctly When Port Information Is Encrypted

This means that the port information that NAT relies on for one to many translations between public and private IP addresses will fail. Recall from our NAT discussion that NAT really affects the ability of traffic to return to the original sender more than it affects the ability of traffic to be sent over the Internet. When there are ten hosts internal to the company that are being NAT'ed by a single gateway to a single IP address, the NAT device needs some way to associate return traffic with the original sender. Normally done with transport layer ports, when these ports are encrypted, this technique is not available.

If we examine this problem a bit more closely, we see that using ESP in tunnel mode with NAT would allow at least one VPN connection. After all, if one internal host is using IPSec through the NAT device, the NAT device only needs to associate a single incoming connection with a single internal host. That is straightforward enough to do, especially because IPSec has its own IP protocol numbers.

Although a "one IPSec connection only" rule would work to solve our NAT/IPSec interoperability problems, this solution is not going to be attractive to many. Most will want multiple VPN connections through the NAT device. For this to work, we are going to have to find something that will allow the NAT device to keep track of packets returning from the Internet and be able to associate them with internal hosts. But what would we use?

Looking at the packet structure, we see that any useful information to be used for telling one packet from another, other than the SPI and the sequence number of the ESP header, is encrypted. The sequence numbers are going to be changing constantly, so it may not be a good candidate for distinguishing packets. The SPI, however, is a possibility. The SPI is a unidirectional identifier for each IPSec SA. This seems to fit the bill perfectly.

To make this work, we would simply need to get the NAT device to use the SPI value as the unique identifier for each connection instead of a transport layer protocol identifier. Because this is just a programming issue, that is not a problem. While the main hurdle has been overcome, there are still some minor issues that remain with using the SPI of an ESP packet.

The first issue is that the SPI is a unidirectional identifier. The SPI that Host A uses to send packets to Host B is not the same SPI that appears at the NAT gateway when Host B returns traffic to Host A. To overcome this, some guesswork will be necessary. The NAT gateway must also be programmed to take a look at the IKE exchange when the initial phase one, unencrypted SAs are being exchanged. This tips off the NAT device that these two hosts are creating an IPSec session and to pay attention to any packets that start to flow between these two devices. The NAT device is going to guess that, because it saw an IKE exchange between Host A and Host B, the first IP packets that show up with the ESP protocol coming from Host B on the Internet are the ones with the incoming SPI to associate to internal Host A.

This process is not always perfect and sometimes is incorrect. Let us expand the scenario a bit and say that Host C is also internal to the NAT domain and it wishes to create an IPSec connection to Host B on the Internet at the same time that Host A wishes to. The NAT device will see both Host A's and Host C's IKE requests be sent and start to pay attention; but when Host B sends the first encrypted packet, how is the NAT device going to know with which internal host to associate it? It is not. The NAT device will have to "guess" correctly or the process will fail. Typically, this guessing is limited to the first packet seen in response being associated with the first host to send the request or the NAT device simply refusing to make the association due to the ambiguity.

Although a stumbling block, this process is not as failure prone as it might seem. Consider the most common application of NAT that needs to employ this solution. A remote user or SOHO user is connecting through a shared home LAN connection to a work VPN. The router that the home user has is almost always a NAT device and the IPSec client software is on the home user's PC. Unless there are extenuating circumstances, most of the time there will not be multiple users on the SOHO network attempting VPN connections at exactly the same time. This, however, cannot be said for a large office with dozens of users utilizing a VPN connection to a corporate office at once. As a benefit, most cheap home routers already support SPI mapping, but be sure to check before purchasing 50 of them for SOHO users.

While a workable solution, SPI mapping is not perfect and can make mistakes. Ideally, what we would like is a fool-proof solution. Reexamining the problem, we see that it is the encryption of the transport layer protocols that prevents us from distinguishing one packet from another. What if we were to simply insert another transport layer header between the IP packet header and the ESP header, like that in Exhibit 19?

Exhibit 19: UDP Wrapping Adds Extra Port Information for Proper NAT Operation

With this solution, any NAT device can operate normally because the transport layer header is the furthest they ever look into a packet. UDP is the preferred header in this case because all we need are port numbers and none of the overhead associated with TCP connections.

While clever, this solution clearly is not part of the original IPSec protocol suite. In fact, for it to work at all, both hosts that are participating in the IPSec session must be aware that it is happening. It would not do to have Host A wrapping an ESP tunnel in UDP, only to have Host B receive the packet and say, "What is going on here?" Currently, these solutions are vendor proprietary. If your vendor does support this option, however, other than the extra eight octets of packet overhead, this solution is fairly straightforward.

Fortunately for most of our VPN implementations, when deploying a host to gateway or gateway-to-gateway VPN, tunnel mode is normally the mode deployed. Because most are interested in encryption of sent data, ESP is also deployed in preference to the AH.

The easiest way of making sure that NAT and IPSec do not step on each other's toes is to simply make sure that any address translation of IP packets is done before any IPSec encryption occurs. Examine Exhibit 20. If the NAT device is placed before the VPN device relative to the outbound flow of packets, the addresses can be translated and then the IPSec encryption applied.

Exhibit 20: NAT before Encrypting for Best Results

Because no changes need to occur to the packet after the IPSec encryption takes place for outbound packets, authentication of the packet by the receiver does not fail. NAT does not need to worry about identifying encrypted packets because either outbound or inbound traffic is not encrypted when it reaches the NAT gateway. Alternately, the IPSec/NAT function can occur on a single device such as a combination VPN/firewall or VPN gateway. Presumably, the manufacturers of such a device will apply the proper encryption/translation order internally to the device itself.

This solution only works when a gateway is being employed, however. For SOHO/remote users who have VPN client software on their host PCs, they often do not have the choice to be able to apply NAT before the IPSec encryption. In this case, the solutions discussed above must be taken into consideration or another alternative to IPSec considered.