Why network address translation (NAT) on an Internet router keeps the VPN client from making the connection
Many a network administrator has tried to set up a virtual private network (VPN) client from a workstation with a nonroutable (private) IP address only to find out—amid much frustration—that the network address translation (NAT) on the Internet router keeps the VPN client from making the connection. We’re going to look at the reasons behind this common problem and see what you can do about it.
First, here are four basic concepts you need to understand:
- Encapsulation involves wrapping a header around a data unit, typically an IP packet. Encapsulation can also be referred to as tunneling. For instance, IP packets get encapsulated in a frame-relay header when they traverse a frame-relay WAN.
- Encryption provides a way to secure sensitive data by translating it into private code. It can then be decrypted only by using a secret key or a password.
- A VPN encapsulates and encrypts packets to send a private network’s data over a public network (such as the Internet) to another private network. Point-to-Point Tunneling Protocol (PPTP), Layer 2 Tunneling Protocol (L2TP), and IP Security (IPSec) are the most popular protocols for securing VPN traffic.
- NAT is based on RFC1631 and is typically used to connect a private network to a public network, such as connecting your company network to the Internet. In fact, you are probably using NAT to access this article via the Internet. For more information, you can refer to my article "Setting up NAT using the Cisco IOS" or Cisco’s article "How NAT Works." Keep in mind that to function, NAT doesn’t just swap IP source and destination addresses, but it may also swap TCP source and destination ports, change the IP and TCP header checksums, change the TCP sequence and acknowledgment numbers, and change IP addresses contained in the data payload.
Now we need to look at a few of the important differences between the two VPN tunneling methods:
- IPSec and L2TP
These two open protocols are popular across multiple platforms. However, they usually encapsulate and encrypt the IP datagram, which contains the IP source and destination addresses. This can make them troublesome for NAT. IPSec can work in two different ways: transport and tunnel. Transport mode is between a client and a server. Tunnel mode is between two IPSec tunneling gateways (for instance, two routers or servers). In transport mode, the application headers, TCP/UDP headers, and data are encrypted, leaving the IP headers exposed. The authentication data is calculated based on the values in the IP header (among other things). In tunnel mode, the entire packet (including the IP headers) is encrypted and new IP headers are appended.
This Microsoft propriety protocol does not encapsulate or encrypt the IP datagram, which makes this protocol compatible with NAT, or “NAT friendly.” Windows 2000 RRAS (Routing and Remote Access Services) uses this VPN protocol by default. If you are using NAT, choosing Windows 2000 VPN (RRAS) services with PPTP can greatly simplify your VPN-NAT issues.
NAT and VPN
NAT issupposed to be transparent to whatever applications it works with. Many NAT and VPN dilemmas are created by this assumption. NAT can break a VPN tunnel because NAT changes the Layer 3 network address of a packet (and checksum values), whereas the tunneling, used by an IPSec or L2TP VPN gateway, encapsulates/encrypts the Layer 3 network address of a packet with another Layer 3 network address, stripping it off on the other side.
In other words, after a packet goes through the NAT process, it has a different network address. But after a packet goes through the IPSec or L2TP VPN tunneling process, it has the same network address. This concept is invaluable when setting up and troubleshooting NAT and VPN together.
As I said, choosing PPTP can often eliminate the NAT-VPN issues created with IPSec and/or L2TP. However, if you are trying to create a tunnel through the Internet between two Cisco routers (or other non-Microsoft devices or operating systems), you will likely be using IPSec. If you are using IPSec with NAT on a Cisco router, you can get around the VPN-NAT issues by selecting the traffic that is to be NATed and making sure that that traffic is not NATed but encapsulated and encrypted in the IPSec header.
In other words, you want the traffic bound for true Internet destinations to be NATed, and you want the traffic destined to travel through the IPSec tunnel to be tunneled, not NATed. On Cisco equipment, this is accomplished using an access control list.
Let's return to our original scenario of the troubled network administrator who configures a workstation with a private IP address and tries to use a VPN client to go through a NAT-enabled router. We'll assume that the administrator is using an IPSec-based VPN client (not PPTP). Because this is from a client to a server, this means that the admin is using IPSec in transport mode.
Remember that in transport mode, the IP header is not encrypted but exposed. However, the authentication data is calculated based on the values in the IP header (among other things). When the packets arrive at the NAT router, the IP headers are modified (NATed). Upon arriving at the VPN server, the authentication data in the packet is invalid because the IP header information was modified by NAT. So the VPN server drops the packet, and the VPN client never gets connected.
To deal with this issue, VPN product vendors are beginning to build IPSec NAT traversal capabilities into their products. Different standards and vendor implementations are being used to make this work. Most rely on some kind of IPSec encapsulation into UDP packets. Because the IPSec packet is now encapsulated, NAT devices do not affect the packet’s IP header information, and the IPSec authentication data is still valid. Thus, a connection can be made.
This is a complex topic that should not be taken lightly. Understanding how NAT and the different VPN implementations do what they do is crucial. You should also check with your router and VPN vendors for specific solutions that their products may have for dealing with NAT and VPN interoperability.
Cisco provides the following sample network configurations and scenarios that can help to better understand and manage NAT-VPN issues:
- "Configuring Router to VPN Client, Mode-config, Wild-card Pre-shared Key with NAT"
- "Sample Configuration: IPSec Tunnel through Firewall with NAT"
- "Configuring a Router IPSec Tunnel Private-to-Private Network with NAT and a Static IP Address"
- "Configuring Router-to-Router Dynamic-to-Static IPSec with NAT"
- "Configuring IPSec Router-to-Router, Pre-shared, NAT Overload Between Private Networks"
- "Configuring IPSec Router-to-Router with NAT Overload and CiscoSecure VPN Client"
Have a comment or a question?
We look forward to getting your input and hearing about your experiences regarding this topic. Post a comment or a question about this article.