NAT Traversal connects

THE FAST-GROWING use of the Internet led to a shortage of IP addresses. To deal with this problem, the Internet Engineering Task Force (IETF) defined NAT (Network Address Translation), which is a way to convert private IP addresses to publicly routable Internet addresses, allowing organizations to minimize the number of Internet IP addresses they need. Thanks to NAT, companies can now connect thousands of systems to the Internet behind one public IP address.

NAT works in two ways. Static NAT maps each private address to a public address. With NAPT (Network Address Port Translation), both IP address and port are translated, allowing many systems to share a single public IP address. Although NAT provides many benefits, some applications, such as IPsec VPNs, peer-to-peer communications, and video streaming, do not work well through NAT.

With IPsec VPNs, the problem involves ensuring packet integrity. When a packet passes through a NAT device, the original IP address is modified. This is a no-no for IPsec, because any modification of the packet will result in a failed integrity check and prevent the VPN tunnel from being created. Therefore, IPsec and NAT can function together only when NAT occurs before the packet is encrypted. And while this typically works fine in gateway-to-gateway communications, remote access solutions are problematic because the IPsec VPN client on a remote laptop will encrypt the packet before it travels to the NAT device, subsequently breaking the IPsec VPN connection.

To enable IPsec VPNs to work with NAT devices, some of the leading technology companies created a solution coined NAT Traversal, which is currently an IETF draft standard. Two approaches to NAT Traversal were developed, one by SSH Communications and the other by F-Secure, Cisco Systems, Nortel Networks, and Microsoft. In March 2001, these two solutions were combined into one (see www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-t-ike-01.txt ). The main technology behind this solution is UDP (User Datagram Protocol) encapsulation, wherein the IPsec packet is wrapped inside a UDP/IP header, allowing NAT devices to change IP or port addresses without modifying the IPsec packet.

Negotiating NAT

For NAT Traversal to work properly, two things must occur. First, the communicating VPN devices must support the same method of UDP encapsulation. Second, all NAT devices along the communication path must be identified.

According to the IETF draft standard, IPsec devices will exchange a specific, known value to determine whether or not they both support NAT Traversal. (Currently, this value is draft-ietf-ipsec-nat-t-ike-00.) If the two VPN devices agree on NAT Traversal, they next determine whether or not NAT or NAPT occurs anywhere on the communications path between them. NAT devices are determined by sending NAT-D (NAT Discovery) packets. Both end points send hashes of the source and destination IP addresses and ports they are aware of. If these hashes do not match, indicating that the IP address and ports are not the same, then the VPN devices know a NAT device exists somewhere in between.

Usually, NAT assignments last for a short period of time and are then released. For IPsec to work properly, the same NAT assignment needs to remain intact for the duration of the VPN tunnel. NAT Traversal accomplishes this by requiring any end point communicating through a NAT device to send a “keepalive” packet, which is a one-byte UDP packet sent periodically to prevent NAT end points from being remapped midsession.

All NAT Traversal communications occur over UDP port 500. This works great because port 500 is already open for IKE (Internet Key Exchange) communications in IPsec VPNs, so new holes do not need to be opened in the corporate firewall. This solution does add a bit of overhead to IPsec communications; namely, 200 bytes is added for the Phase 1 IKE negotiation and each IPsec packet has about an additional 20 bytes.

Testing Traversal

We attempted to use NAT Traversal to connect a remote access system running SafeNet’s latest VPN client software and sitting behind a Linksys SOHO (Small Office/Home Office) firewall performing NAT and a Netscreen VPN gateway with NAT Traversal support built-in. No configuration changes were required on the client side, and configuration on the Netscreen device was minimal. When configuring the VPN gateway, all we had to do was check one box to enable NAT Traversal. We established a VPN tunnel with absolutely no problems. Reviewing the logs on both the client and gateway, we noted the exchanges establishing NAT Traversal support and discovering a NAT device in the communications path.

NAT Traversal is the long-awaited solution to one of the major issues with IPsec VPNs, but it does not solve everyone’s problems. For example, private address space can overlap and create routing issues, and NAT Traversal is not supported with AH (Authenticated Header) IPsec connections. Nevertheless, by enabling IPsec VPNs to work with NAT, NAT Traversal allows companies to improve the security of remote connections.