Most outbound "NATs" actually translate both IP addresses and ports to let many users share a public single IP address. Many VPN users run into trouble sending IPsec through a NAT-ing device like a firewall because (a) NAT changes IP and TCP/UDP headers carried inside packets, invalidating IPsec's integrity check, and (b) the TCP/UDP header in an IPsec ESP packet is encrypted, preventing NAT from mapping ports.
VPN Passthroughs usually fix (b) by NAT-ing encrypted packets without mapping ports inside the TCP/IP payload. An IPsec VPN Passthrough translates an IPsec ESP packet's source IP to the firewall's external interface while ignoring encrypted payload. A PPTP VPN Passthrough NATs PPTP GRE packets in a similar fashion. Some Passthroughs are limited to one VPN tunnel at a time; other implementations use fields like IPsec SPI to multiplex several tunnels through one NAT-ing device. VPN Passthrough isn't a standard and behavior varies by product.
NAT Traversal refers to a series of IETF Internet Drafts that fix (a) by wrapping encrypted IPsec packets inside a cleartext UDP wrapper. Any NAT-ing device can translate both the source IP address and source UDP port of the cleartext wrapper without changing any part of the encrypted IPsec packet carried inside. The challenge is that both ends of the IPsec tunnel must support the same version of NAT Traversal, be able to detect when to use NAT Traversal, keep the NAT mapping alive for the lifetime of the tunnel, etc. Many VPN vendors implement NAT Traversal drafts, and NAT Traversal works well today in single-vendor VPNs. Multi-vendor VPN NAT Traversal should improve when everyone aligns with the final IETF standard.
This was first published in May 2004