NAT Transparency

The previous section described how the VPN Concentrator performs NAT and PAT services for IP networks connecting to the concentrator. Performing NAT in the VPN Concentrator or IPSec gateway is not problematic because NAT can occur prior to any encryption or authentication services for the IP packet. It is common, however, to have an existing firewall or router on the concentrator or client's network providing these NAT or PAT services. When this is the case, IKE and ESP may not work because the device's NAT or PAT translations manipulate data payloads and offset any data authentication because significant bits are changed in the original IP header. Additionally, if the tunnel endpoints are using ESP in tunnel mode, the packet's original IP header is encrypted and cannot be translated by a intermediary device because it cannot perform the necessary decryption to see the original IP header. What's more, depending on the authentication method used, certain IKE authentication methods use the peer's IP address for authentication identity data. Because this IP would be translated by a NAT-capable gateway, authentication fails for IKE negotiations and the tunnel is never established. A work-around for this predicament is to encapsulate IPSec and IKE messages in UDP or TCP packets that can be passed by those translating devices. Cisco supports IPSec over TCP and UDP NAT Transparency for remote access software and hardware clients.

Starting with version 3.6, Cisco also supports the ratified UDP encapsulation standard of NAT Traversal (NAT-T), which uses the default UDP port of 4500. NAT-T can be applied to hardware and software clients' remote access sessions, as well as LAN-to-LAN tunnels between IPSec gateways. NAT Traversal enables the clients or concentrator to detect automatically a NAT- or PAT-capable device along the tunnel's path by sending a hash of their IP addresses and ports during IKE phase 1. If a receiving device performs the same hash on the IKE peer's IP address and they do not match, the devices assume that a translation has occurred in transit. When a connecting client supports a NAT Transparency feature, the VPN 3000 Concentrator prefers IPSec over TCP first, then NAT-T, followed by IPSec over UDP.

NAT Transparency does not work behind proxy server devices performing NAT and PAT translations.

To configure IPSec over UDP for remote access hardware and software clients, enable IPSec over UDP and specify a UDP port number (default is 10,000) for individual groups or the base group in the Client Config tab of the User Management screen (see Chapter 4). IPSec over TCP and NAT-T configurations differ from IPSec over UDP because these configuration are applied system-wide to the concentrator, as opposed to a group-by-group basis. In the Configuration | System | Tunneling Protocols | IPSec | NAT Transparency screen in Figure 6.17, you are given the options to configure these two functions. Check the appropriate boxes for the desired functionality. Additionally, TCP encapsulation enables you to support up to 10 ports. Be careful not to use any common well-known application ports such as 20, 21, 23, 25, 80, 443, and so on.

Figure 6.17. NAT Transparency configuration screen.

TCP over UDP and NAT-T is applied as a system-wide configuration, as opposed to IPSec over UDP's group-by-group configuration.