equinux VPN Tracker 5.4.4 - Manual (Page 46)

public IP of the router (so all response packets are sent to the
router directly).
If there is more than a single host in the private network
accessing the same host, the router obviously needs to
distinguish the response packets somehow.
This is achieved by mapping the original client’s source port
(and its private IP address) to unique ports by the router. The
router the relation between these addresses in a mapping
table. When the response packet arrives at the router, it checks
the table to find out where to send the data and translates the
IP headers back to the originating private IP and source port.
NAT effectively prevents exposing the internal addresses and
enables hosts with private IP addresses to communicate on the
Internet.
NAT and ESP
How does this affect IPSec tunnels? Remember that IKE uses
UDP packets to negotiate a tunnel, but ESP packets to transfer
the actual data.
The ESP protocol has no ports (unlike UDP or TCP), so the NAT
method cannot be used to translate ESP packets from private
to public addresses and back.
IPSec Passthrough
The simplest solution to this dilemma is called IPSec
Passthrough. Routers supporting this technique will just send
ESP responses back to the last host who contacted the remote
gateway. This obviously does not work if more than a single
host needs to establish a VPN connection.
Traversing the Problem
NAT-Traversal is generally considered a reliable and more
flexible solution: Before sending out an ESP packet, the VPN
participant encapsulates it by adding an additional UDP
header.
This UDP header can be altered by the NAT router. Since the
additional header is removed by the remote peer
before
checking the ESP packet, changing it does not affect the
integrity of the packets.
After removing the UDP header, the enclosed packet is
analyzed. If it is considered to be authentic and unchanged,
the remote peer will also use NAT-T to send its response.
The only issue with NAT-T is that different drafts of the NAT-T
specification recommend different UDP ports to use. Initial
drafts used port 500, which caused some devices (routers)
between the VPN peers and VPN gateway to drop the packets
(as they expected IKE/ISAKMP packets on that port only).
Newer drafts recommend “port-floating”, i.e. a switch from UDP
port 500 to port 4500 while the tunnel is being established. If
the remote VPN gateway supports port floating, this should
work fine (unless the administrator of an intermediate firewall
did not open that port).
46