equinux VPN Tracker 8.1.1 - Manual (Page 72)

NAT-Traversal
Network Address Translation used to be a problem for VPN connections: Once
the VPN is established, the actual communication over the VPN uses a net-
work protocol called ESP. Unlike the TCP and UDP network protocols you may
be familiar with, ESP does not use network ports. Since NAT depends on being
able to use network ports to identify the recipient of an incoming response, it
cannot work with ESP out of the box. Two methods have been developed to
deal with NAT-Traversal:
IPSec Passthrough
For IPsec Passthrough, the local router needs to know about IPsec VPN and
the ESP protocol. In its most basic form, the router simply sends all ESP traffic
to the last host on its network that talked to the VPN gateway. Most NAT rout-
ers have some limitation on their IPsec Passthrough capability, for example it
often cannot support more than a single computer connecting to the VPN.
Since the local router takes care of everything, no special support is required
on the VPN gateway or the VPN client.
NAT-Traversal
With NAT-Traversal, VPN Tracker wraps ESP into regular UDP packets (which
have port numbers and can easily be handled by NAT routers). On the other
end, the VPN gateway needs to remove the UDP “wrapper” before it can de-
crypt the VPN communication.
There are several versions of NAT Traversal. Some VPN gateways support only
one form of NAT-Traversal, and some, particularly older or low-end VPN gate-
ways, support none.
VPN Tracker and the VPN gateway automatically nego-
tiate which form of NAT-Traversal, if any, to use.
Since VPN Tracker and the VPN gateway take care of everything, no special
support for NAT-Traversal is required from the local router, though firewall
rules or firmware issues could prevent NAT-Traversal from working.
If you are buying a new VPN gateway, make sure it supports all
forms of NAT-Traversal – it is very likely that you will encounter
Internet connections that require NAT-Traversal to work.
The following diagram shows how a VPN is established using different NAT-
Traversal mechanisms:
NAT-Traversal: Earlier Draft Versions vs. RFC
The early NAT-Traversal draft versions sent UDP packets on network port
500, the same port also used for the initial connection process of the VPN.
This sometimes caused trouble with NAT routers that simply discarded UDP
packets on network port 500.
To deal with this problem, the final NAT-Traversal standard (RFC) changed
the network port for performing NAT-Traversal to the (non-privileged) UDP
network port 4500.
Phase 1
Phase 2
Established
XAUTH,
Mode Config,
EasyVPN
(optional)
DHCP over VPN
SonicWALL
(optional)
ESP is being used (no ports)
NAT-Traversal encapsulates
ESP in UDP (port 4500 for RFC,
port 500 for early drafts)
The VPN gateway and VPN
Tracker negotiate which NAT-
Traversal mechanism to use
later. Phase 1 always uses
UDP port 500.
NAT-Traversal (RFC) switches
to UDP port 4500, all others
continue on UDP port 500
72