IP Security and NAT: Oil and Water?

Despite popular wisdom, IPsec and NAT can be employed together—in some configurations. We explore what you can do and what you can't, and the limitations inherent in today's solutions.

Lisa Phifer
VP Core Competence, Inc.
[June 15, 2000]

One question asked frequently by those planning to implement virtual private networks concerns the ability to combine IP security (IPsec) and Network Address Translation (NAT). Many have heard rumors and war stories about incompatibilities between IPsec and NAT. Others have seen blanket denials issued by vendors who successfully combine IPsec and NAT within a single product. As is so often the case, reality lies somewhere between the two extremes: IPsec and NAT can be employed together in some configurations, but not in others. In today's column, we'll explore the issues and limitations associated with combining IPsec and NAT, and take a brief look at recent advances in this area.

Today, NAT is commonly supported by WAN access routers and firewalls — devices situated at the network edge. NAT starts by creating bindings between addresses. A one-to-one mapping may be defined between public and private IP addresses (static NAT). More often, a pool of public IP addresses is shared by an entire private IP subnet (dynamic NAT). Edge devices that run NAT use these bindings to translate addresses carried in IP packet headers and provide transparent packet forwarding between realms. The end systems remain unaware that NAT is taking place.

A variation known as Network Address Port Translation (NAPT) may be used to allow many hosts to share a single IP address by multiplexing streams differentiated by TCP/UDP port numbers as well as IP addresses.

For example, suppose private hosts 10.0.0.1 and 10.0.0.2 both send packets from source port 2000. A NAPT device might translate these to a single public IP address 207.29.194.28 but two different source ports, say 2998 and 2999. Response traffic received for port 2998 is routed to 10.0.0.1 while port 2999 traffic is routed to 10.0.0.2.

Where do ISPs and their customers use NAT?
Outbound (traditional) NAT is commonly employed by multi-host residential users, teleworkers, and small businesses that share a single public IP for outbound traffic while blocking inbound session requests. In other words, small subscriber LANs connected via ISDN, DSL, or cable modem. Bi-directional NAT is typically used by enterprise customers who host their own servers behind a masquerading firewall. Here, the NAT device maps selected destination ports to inside (private) IPs for inbound request routing. NAT can also be employed by enterprise customers wishing to insulate themselves from ISP address changes, or by those wanting to obscure private network topology for security reasons.

Our need to conserve IPv.4 addresses has prompted many to overlook NAT's inherent weaknesses. Protocols like FTP may carry IP addresses in application-level payload; in these cases, an application-level gateway is needed to complete the translation started by NAT. In other cases, translation simply cannot "fix" a packet modified by NAT.

Impact of NAT on IPsec
The IPsec Authentication Header (AH) is a case in point. AH runs the entire IP packet, including invariant header fields like source and destination address, through a message digest algorithm to produce a keyed hash. This hash is used by the recipient to authenticate the packet. If any field in the original IP packet is modified, authentication will fail and the recipient will discard the packet. AH is intended to prevent unauthorized modification, source spoofing, and man-in-the-middle attacks. But NAT, by definition, modifies IP packets. Ergo, AH + NAT cannot work.

The other IPsec protocol, the Encapsulating Security Payload (ESP), also employs a message digest algorithm for packet authentication. But unlike AH, the hash created by ESP does not include the outer packet header fields. This solves one problem, but leaves others.

Go to page 2: IPsec supports two "modes"