In tunnel mode ESP, the TCP/UDP headers are not visible and can't be used to translate between inside and outside. In this discussion, we are assuming that there is only one NAT device in the network. If there are more, they all need to be IPsec-aware to pass traffic properly. Static NAT and ESP IPsec will work just fine, because only the IP addresses are translated, regardless of upper-layer protocols.
Cisco Systems' Cisco 3060 and its VPN client support remote users through NAT by encapsulating the IP packet into UDP before hitting the network. Because the outer UDP and associated IP header aren't protected in any way, they pass through NAT devices of all kinds without a problem. The receiving Cisco 3060 must de-encapsulate the incoming packet and process it. This works only with the Cisco 3000 line.
There are other proposals in the IETF to standardize the encapsulation of IPsec in UDP, notably IPsec NAT-Traversal in the Network Working Group and RSIP (Realm-Specific IP) for end-to-end IPsec in the Network Address Translators Group. SSH Communications Security is making its NAT Traversal Toolkit available later this quarter.
What's Left?
So that leaves us with one situation: ESP IPsec with NAPT. There are two ways that vendors are solving this problem. The simplest way, which allows only one IPsec VPN to pass through the NAPT, is to associate a single workstation that is running IKE with all IPsec packets.
(see image)
