||This article needs additional citations for verification. (April 2010)|
NAT traversal is a general term for techniques that establish and maintain Internet protocol connections traversing network address translation (NAT) gateways. Network address translation breaks end-to-end connectivity. Intercepting and modifying traffic can only be performed transparently in the absence of secure encryption and authentication. NAT traversal techniques are typically required for client-to-client networking applications, especially peer-to-peer and Voice over IP (VoIP) deployments. Many techniques exist, but no single method works in every situation since NAT behavior is not standardized. Many NAT traversal techniques require assistance from a server at a publicly routable IP address. Some methods use the server only when establishing the connection, while others are based on relaying all data through it, which adds bandwidth costs and increases latency, detrimental to real-time voice and video communications.
Most NAT behavior-based techniques bypass enterprise security policies. Enterprise security experts prefer techniques that explicitly cooperate with NAT and firewalls, allowing NAT traversal while still enabling marshalling at the NAT to enforce enterprise security policies. From this point of view, the most promising IETF standards are Realm-Specific IP (RSIP) and Middlebox Communications (MIDCOM).
SOCKS, the oldest NAT traversal protocol, is still widely available. In home or small office settings, Universal Plug and Play (UPnP) is supported by most small NAT gateways. NAT-T is commonly used by IPsec virtual private network clients in order to have Encapsulating Security Payload packets traverse NAT.
The NAT traversal problem 
NAT devices are commonly used to alleviate IPv4 address exhaustion by allowing the use of private IP addresses on home and corporate networks behind routers with a single public IP address facing the public Internet. The internal network devices communicate with hosts on the external network by changing the source address of outgoing requests to that of the NAT device and relaying replies back to the originating device. This leaves the internal network ill-suited to host servers, as the NAT device has no automatic method of determining the internal host for which incoming packets are destined. This is not a problem for home users behind NAT devices doing general web access and e-mail. However, applications such as peer-to-peer file sharing, VoIP services and the online services of current generation video game consoles require clients to be servers as well, thereby posing a problem for users behind NAT devices, as incoming requests cannot be easily correlated to the proper internal host. Furthermore many of these types of services carry IP address and port number information in the application data, potentially requiring substitution or special traversal techniques for NAT traversal.
NAT traversal and IPsec 
||This article may be too technical for most readers to understand. (March 2011)|
In order for IPsec to work through a NAT, the following protocols need to be allowed through the NAT interface(s), e.g. the LAN router:
- Internet Key Exchange (IKE) - User Datagram Protocol (UDP) port 500
- Encapsulating Security Payload (ESP) - IP protocol number 50
- Authentication Header (AH) - IP protocol number 51
or, in case of NAT-T:
- IKE - UDP port 500
- IPsec NAT-T - UDP port 4500
Often this is accomplished on home routers by enabling "IPsec Passthrough".
In Windows XP, NAT-T is enabled by default, but in XP with SP2, has been disabled by default for the case when the VPN server is also behind a NAT device, because of a rare and controversial security issue. IPsec NAT-T patches are also available for Windows 2000, Windows NT and Windows 98.
One usage of NAT-T and IPsec is to enable opportunistic encryption between systems. NAT-T allows systems behind NATs to request and establish secure connections on demand.
IETF references 
- RFC 1579 - Firewall Friendly FTP
- RFC 2663 - IP Network Address Translator (NAT) Terminology and Considerations
- RFC 2709 - Security Model with Tunnel-mode IPsec for NAT Domains
- RFC 2993 - Architectural Implications of NAT
- RFC 3022 - Traditional IP Network Address Translator (Traditional NAT)
- RFC 3027 - Protocol Complications with the IP Network Address Translator (NAT)
- RFC 3235 - Network Address Translator (NAT)-Friendly Application Design Guidelines
- RFC 3715 - IPsec-Network Address Translation (NAT) Compatibility
- RFC 3947 - Negotiation of NAT-Traversal in the IKE
- RFC 5128 - State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)
See also 
NAT traversal protocols and techniques based on NAT behavior 
- Session Traversal Utilities for NAT (STUN)
- Traversal Using Relay NAT (TURN)
- NAT-T Negotiation of NAT-Traversal in the IKE
- Teredo tunneling uses NAT traversal to provide IPv6 connectivity.
- Session Border Controller (SBC)
- UDP hole punching
- TCP hole punching
- ICMP hole punching
NAT traversal based on NAT control 
- Realm-Specific IP (RSIP)
- Middlebox Communications (MIDCOM)
- NAT Port Mapping Protocol (NAT PMP)
- Internet Gateway Device (IGD) Protocol, defined by the Universal Plug and Play (UPnP) Forum.
- Application Layer Gateway (ALG)
NAT traversal combining several techniques 
University research papers 
- Autonomous NAT Traversal - NAT to NAT communication without a third party
- Cornell University - Characterization and Measurement of TCP Traversal through NATs and Firewalls
- Columbia University - An Analysis of the Skype Peer-to-Peer Internet Telephony
- Peer to peer communication across Network Address Translators (UDP Hole Punching)
- Internet By All Means - An article on how to maximize your chances to get around firewalls
- "IPSec NAT-T is not recommended for Windows Server 2003 computers that are behind network address translators". Microsoft knowledge base #885348.