IP Security and NAT: Oil and Water? —continued

IPsec supports two "modes"
Transport mode IPsec provides end-to-end security between hosts, while tunnel mode protects encapsulated IP packets between security gateways — for example, between two firewalls or between a roaming host and a remote access server. When TCP or UDP are involved — as they are in transport mode ESP — there is a catch-22. Because NAT modifies the TCP/UDP packet, NAT must also recalculate the checksum used to verify integrity. If NAT updates the checksum, ESP authentication will fail. If NAT does not update the checksum, TCP/UDP verification will fail. If the transport endpoint were under your control, you might be able to turn off checksums. Bottom line: ESP can pass through NAT in tunnel mode, or in transport mode with checksums disabled or ignored by the receiver.

If we stick to ESP in tunnel mode or turn off checksums, there's still one obstacle: the Internet Key Exchange (IKE). IPsec-based VPNs use IKE to automate security association setup and authenticate endpoints. The most basic and common method of authentication in use today is pre-shared key. Unfortunately, this method depends upon the packet's source IP address. If NAT is inserted between endpoints, the source IP address will be that of the NAT device, not the originating security gateway. To avoid this problem, use another IKE authentication method (e.g., public key signature or X.509 digital certificate) or look for a VPN product that doesn't use source IP address for IKE "main mode" identification.

A further problem may occur after a security association has been up for a while. When the association expires, one security gateway will send a rekey request to the well-known IKE port 500 at the other security gateway. If more than one security gateway lies behind a NAPT device, how can the incoming rekey be directed to the right private IP address? Rekeys can be made to work by "floating" the IKE port so that every gateway uses a different port number, allowing requests to be demultiplexed by a NAPT device.

At this point, two things should be clear: (1) it is possible to find a flavor of IPsec that will run through NAT, but (2) one must do so with great care and attention to detail. See RFC 2709 for a security model that covers running tunnel-mode IPsec through NAT.

One Solution: Avoid The Problem
By far the easiest way to combine IPsec and NAT is to completely avoid these problems by locating IPsec endpoints in public address space. That is, NAT before IPsec; don't IPsec before NAT. This can be accomplished in two ways:

1. Perform NAT on a device located behind your IPsec security gateway
2. Use an IPsec device that also performs NAT

Many devices that implement IPsec also support NAT in the same box. These products perform outbound address translation before applying security policies; the order is reversed for inbound packets. A typical "any to any" security policy is easily specified with such a product. Granular policies can be a bit more difficult because filters are often based on IP address, and care must be taken to avoid overlapping filters.

A small sampling of the VPN platforms that support both IPsec and NAT include:

1. Routers from Cisco and Enterasys
   
   
2. Firewalls from WatchGuard and AXENT
   
   
3. Special-purpose security gateways from Radguard
   
   
4. Internet appliances from vendors like FreeGate and
   
   
5. Software solutions like FreeS/WAN combined with Linux VPN Masquerade.

While these products avoid the problem by combining IPsec and NAT in a single box, others prefer to tackle NAT-in-the-middle head-on. For example, NexLand recently announced ISB2LAN, a low-end NAT appliance that employs patent-pending "multi-session pass-thru technology". According to NexLand, ISB2LAN can be inserted transparently in the middle of an ESP tunnel. It supports one public address with up to 2.5 Mbps aggregate throughput. It will be interesting to see if this solution can scale up to a large number of tunnels with frequent, granular IKE exchanges. It is also important to understand the security implications of allowing NAT-in-the-middle: as RFC 2709 succinctly puts it, "If NATs and ALGs are not in a trusted boundary, that is a major security problem."

Parting Thoughts
Providers planning to implement IPsec VPNs should examine current use of NAT, both in-house and at the customer premise. Where both VPN and NAT services are required, consider deploying both on the same device. If you cannot avoid translating IPsec-protected traffic midstream, limit use of IPsec to tunnel mode ESP and design security policies with care.

In next month's column, we'll take a look at future advances in this area like Realm-Specific IP (RSIP)

Back to page 1