- Read Me First
- IPsec Anti-Replay Window Expandingand Disabling
- Pre-Fragmentation for IPsec VPNs
- Invalid Security Parameter Index Recovery
- IPsec Dead Peer Detection PeriodicMessage Option
- IPsec NAT Transparency
- DF Bit Override Functionality with IPsec Tunnels
- IPsec Security Association Idle Timers
- IPv6 IPsec Quality of Service
- IPv6 Virtual Tunnel Interface
- Index
- Finding Feature Information
- Restrictions for IPsec NAT Transparency
- Information About IPsec NAT Transparency
- Benefit of IPsec NAT Transparency
- Feature Design of IPsec NAT Traversal
- NAT Keepalives
- How to Configure NAT and IPsec
- Configuration Examples for IPsec and NAT
- Additional References
- Feature Information for IPsec NAT Transparency
- Glossary
IPsec NAT Transparency
The IPsec NAT Transparency feature introduces support for IP Security (IPsec) traffic to travel through Network Address Translation (NAT) or Port Address Translation (PAT) points in the network by addressing many known incompatibilities between NAT and IPsec.
- Finding Feature Information
- Restrictions for IPsec NAT Transparency
- Information About IPsec NAT Transparency
- How to Configure NAT and IPsec
- Configuration Examples for IPsec and NAT
- Additional References
- Feature Information for IPsec NAT Transparency
- Glossary
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Restrictions for IPsec NAT Transparency
Although this feature addresses many incompatibilities between NAT and IPsec, the following problems still exist:
Internet Key Exchange (IKE) IP Address and NAT
This incompatibility applies only when IP addresses are used as a search key to find a preshared key. Modification of the IP source or destination addresses by NAT or reverse NAT results in a mismatch between the IP address and the preshared key.
Embedded IP Addresses and NAT
Because the payload is integrity protected, any IP address enclosed within IPsec packets cannot be translated by NAT. Protocols that use embedded IP addresses include FTP, Internet Relay Chat (IRC), Simple Network Management Protocol (SNMP), Lightweight Directory Access Protocol (LDAP), H.323, and Session Initiation Protocol (SIP).
Information About IPsec NAT Transparency
Benefit of IPsec NAT Transparency
Before the introduction of this feature, a standard IPsec virtual private network (VPN) tunnel would not work if there were one or more NAT or PAT points in the delivery path of the IPsec packet. This feature makes NAT IPsec-aware, thereby, allowing remote access users to build IPsec tunnels to home gateways.
Feature Design of IPsec NAT Traversal
The IPsec NAT Transparency feature introduces support for IPsec traffic to travel through NAT or PAT points in the network by encapsulating IPsec packets in a User Datagram Protocol (UDP) wrapper, which allows the packets to travel across NAT devices. The following sections define the details of NAT traversal:
- IKE Phase 1 Negotiation NAT Detection
- IKE Phase 2 Negotiation NAT Traversal Decision
- UDP Encapsulation of IPsec Packets for NAT Traversal
- UDP Encapsulated Process for Software Engines Transport Mode and Tunnel Mode ESP Encapsulation
IKE Phase 1 Negotiation NAT Detection
During Internet Key Exchange (IKE) phase 1 negotiation, two types of NAT detection occur before IKE Quick Mode begins--NAT support and NAT existence along the network path.
To detect NAT support, you should exchange the vendor identification (ID) string with the remote peer. During Main Mode (MM) 1 and MM 2 of IKE phase 1, the remote peer sends a vendor ID string payload to its peer to indicate that this version supports NAT traversal. Thereafter, NAT existence along the network path can be determined.
Detecting whether NAT exists along the network path allows you to find any NAT device between two peers and the exact location of NAT. A NAT device can translate the private IP address and port to public value (or from public to private). This translation changes the IP address and port if the packet goes through the device. To detect whether a NAT device exists along the network path, the peers should send a payload with hashes of the IP address and port of both the source and destination address from each end. If both ends calculate the hashes and the hashes match, each peer knows that a NAT device does not exist on the network path between them. If the hashes do not match (that is, someone translated the address or port), then each peer needs to perform NAT traversal to get the IPsec packet through the network.
The hashes are sent as a series of NAT discovery (NAT-D) payloads. Each payload contains one hash; if multiple hashes exist, multiple NAT-D payloads are sent. In most environments, there are only two NAT-D payloads--one for the source address and port and one for the destination address and port. The destination NAT-D payload is sent first, followed by the source NAT-D payload, which implies that the receiver should expect to process the local NAT-D payload first and the remote NAT-D payload second. The NAT-D payloads are included in the third and fourth messages in Main Mode and in the second and third messages in Aggressive Mode (AM).
IKE Phase 2 Negotiation NAT Traversal Decision
While IKE phase 1 detects NAT support and NAT existence along the network path, IKE phase 2 decides whether or not the peers at both ends will use NAT traversal. Quick Mode (QM) security association (SA) payload in QM1 and QM2 is used to for NAT traversal negotiation.
Because the NAT device changes the IP address and port number, incompatibilities between NAT and IPsec can be created. Thus, exchanging the original source address bypasses any incompatibilities.
UDP Encapsulation of IPsec Packets for NAT Traversal
In addition to allowing IPsec packets to traverse across NAT devices, UDP encapsulation also addresses many incompatibility issues between IPsec and NAT and PAT. The resolved issues are as follows:
- Incompatibility Between IPsec ESP and PAT Resolved
- Incompatibility Between Checksums and NAT Resolved
- Incompatibility Between Fixed IKE Destination Ports and PAT Resolved
Incompatibility Between IPsec ESP and PAT Resolved
If PAT found a legislative IP address and port, it would drop the Encapsulating Security Payload (ESP) packet. To prevent this scenario, UDP encapsulation is used to hide the ESP packet behind the UDP header. Thus, PAT treats the ESP packet as a UDP packet, processing the ESP packet as a normal UDP packet.
Incompatibility Between Checksums and NAT Resolved
In the new UDP header, the checksum value is always assigned to zero. This value prevents an intermediate device from validating the checksum against the packet checksum, thereby, resolving the TCP UDP checksum issue because NAT changes the IP source and destination addresses.
Incompatibility Between Fixed IKE Destination Ports and PAT Resolved
PAT changes the port address in the new UDP header for translation and leaves the original payload unchanged.
To see how UDP encapsulation helps to send IPSec packets see the figures below.
UDP Encapsulated Process for Software Engines Transport Mode and Tunnel Mode ESP Encapsulation
After the IPsec packet is encrypted by a hardware accelerator or a software crypto engine, a UDP header and a non-IKE marker (which is 8 bytes in length) are inserted between the original IP header and ESP header. The total length, protocol, and checksum fields are changed to match this modification. The first figure below shows an IPsec packet before and after transport mode is applied; the second figure below shows an IPsec packet before and after tunnel mode is applied.
NAT Keepalives
NAT keepalives are enabled to keep the dynamic NAT mapping alive during a connection between two peers. NAT keepalives are UDP packets with an unencrypted payload of 1 byte. Although the current dead peer detection (DPD) implementation is similar to NAT keepalives, there is a slight difference: DPD is used to detect peer status, while NAT keepalives are sent if the IPsec entity did not send or receive the packet at a specified period of time--valid range is between 5 to 3600 seconds.
If NAT keepalives are enabled (via the crypto isakmp nat keepalive command), users should ensure that the idle value is shorter than the NAT mapping expiration time, which is 20 seconds.
How to Configure NAT and IPsec
- Configuring NAT Traversal
- Disabling NAT Traversal
- Configuring NAT Keepalives
- Verifying IPsec Configuration
Configuring NAT Traversal
NAT Traversal is a feature that is auto detected by VPN devices. There are no configuration steps for a router running Cisco IOS XE Release 2.1. If both VPN devices are NAT-T capable, NAT Traversal is auto detected and auto negotiated.
Disabling NAT Traversal
You may wish to disable NAT traversal if you already know that your network uses IPsec-awareness NAT (spi-matching scheme). To disable NAT traversal, use the following commands:
1.
enable
2.
configure
terminal
3.
no
crypto
ipsec
nat-transparency
udp-encapsulation
DETAILED STEPS
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable
Example: Router> enable |
Enables higher privilege levels, such as privileged EXEC mode. Enter your password if prompted. |
Step 2 |
configure
terminal
Example: Router# configure terminal |
Enters global configuration mode. |
Step 3 |
no
crypto
ipsec
nat-transparency
udp-encapsulation
Example: Router(config)# no crypto ipsec nat-transparency udp-encapsulation |
Disables NAT traversal. |
Configuring NAT Keepalives
To configure your router to send NAT keepalives, use the following commands:
1.
enable
2.
configure
terminal
3.
crypto
isakmp
nat
keepalive
seconds
DETAILED STEPS
Verifying IPsec Configuration
To verify your configuration, perform the following optional steps:
1.
enable
2.
show
crypto
ipsec
sa
[map map-name | address | identity] [detail
DETAILED STEPS
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable
Example: Router> enable |
Enables higher privilege levels, such as privileged EXEC mode. Enter your password if prompted. |
Step 2 |
show
crypto
ipsec
sa
[map map-name | address | identity] [detail Example: Router# show crypto ipsec sa |
Displays the settings used by current SAs. |
Configuration Examples for IPsec and NAT
NAT Keepalives Configuration Example
The following example shows how to enable NAT keepalives to be sent every 20 seconds:
crypto isakmp policy 1 authentication pre-share crypto isakmp key 1234 address 10.0.0.1 crypto isakmp nat keepalive 20 ! ! crypto ipsec transform-set t2 esp-des esp-sha-hmac ! crypto map test2 10 ipsec-isakmp set peer 10.0.0.1 set transform-set t2 match address 101
Additional References
The following sections provide references related to the IPsec NAT Transparency feature.
Related Documents
Related Topic |
Document Title |
---|---|
Additional NAT configuration tasks |
|
Additional NAT commands |
Cisco IOS IP Addressing Services Command Reference |
Additional IPsec configuration tasks |
“ Configuring Security for VPNs with IPsec ” module in the Cisco IOS XE Security Configuration Guide: Secure Connectivity |
Additional IPsec commands |
Cisco IOS Security Command Reference |
Information on IKE |
“ Configuring Internet Key Exchange for IPsec VPNs ” module in the Cisco IOS XE Security Configuration Guide: Secure Connectivity |
Additional information on IKE dead peer detection |
“ Easy VPN Server ” module in the Cisco IOS XE Security Configuration Guide: Secure Connectivity |
Standards
Standards |
Title |
---|---|
No new or modified MIBs are supported by this feature, and support for existing MIBs has not been modified by this feature. |
-- |
MIBs
MIBs |
MIBs Link |
---|---|
No new or modified MIBs are supported by this feature, and support for existing MIBs has not been modified by this feature. |
To locate and download MIBs for selected platforms, Cisco IOS XE software releases, and feature sets, use Cisco MIB Locator found at the following URL: |
RFCs
RFCs1 |
Title |
---|---|
RFC 2402 |
IP Authentication Header |
RFC 2406 |
IP Encapsulating Security Payload (ESP) |
Technical Assistance
Description |
Link |
---|---|
The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies. To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds. Access to most tools on the Cisco Support website requires a Cisco.com user ID and password. |
Feature Information for IPsec NAT Transparency
The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Feature Name |
Releases |
Feature Information |
---|---|---|
IPsec NAT Transparency |
Cisco IOS XE Release 2.1 |
The IPsec NAT Transparency feature introduces support for IP Security (IPsec) traffic to travel through Network Address Translation (NAT) or Port Address Translation (PAT) points in the network by addressing many known incompatibilities between NAT and IPsec. The following commands were introduced or modified: crypto isamkp nat keepalive, access-list (IP extended), show crypto ipsec sa |
Glossary
IKE --Internet Key Exchange. Hybrid protocol that implements Oakley key exchange and Skeme key exchange inside the Internet Security Association Key Management Protocol (ISAKMP) framework. Although IKE can be used with other protocols, its initial implementation is with IPsec. IKE provides authentication of the IPsec peers, negotiates IPsec keys, and negotiates IPsec security associations (SAs).
IPsec --IP Security. Framework of open standards developed by the Internet Engineering Task Force (IETF). IPsec provides security for transmission of sensitive information over unprotected networks such as the Internet. IPsec acts at the network layer, protecting and authenticating IP packets between participating IPsec devices (“peers”), such as Cisco routers.
NAT --Network Address Translation. Translates a private IP address used inside the corporation to a public, routable address for use on the outside of the corporation, such as the Internet. NAT is considered a one-to-one mapping of addresses from private to public.
PAT --Port Address Translation. Like NAT, PAT also translated private IP address to public, routable addresses. Unlike NAT, PAT provides a many-to-one mapping of private addresses to a public address; each instance of the public address is associated with a particular port number to provide uniqueness. PAT can be used in environments where the cost of obtaining a range of public addresses is too expensive for an organization.