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.
Important concepts
First, here are four basic concepts you need to understand:
VPN protocols
Now we need to look at a few of the important differences between the two VPN tunneling methods:
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.
Final word
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:
We look forward to getting your input and hearing about your experiences regarding this topic. Post a comment or a question about this article.