- Finding Feature Information
- Prerequisites for Using Application Level Gateways with NAT
- Restrictions for Using Application Level Gateways with NAT
- Information About Using Application Level Gateways with NAT
- Application Level Gateway
- IP Security
- Voice and Multimedia over IP Networks
- NAT Support of H.323 v2 RAS
- NAT Support for H.323 v3 and v4 in v2 Compatibility Mode
- NAT H.245 Tunneling Support
- NAT Support of Skinny Client Control Protocol
- NAT Support of SCCP Fragmentation
- NAT Segmentation with Layer 4 Forwarding
- How to Configure Application Level Gateways with NAT
- Configuration Examples for Using Application Level Gateways with NAT
- Where to Go Next
- Additional References
- Feature Information for Using Application Level Gateways with NAT
Using Application Level Gateways with NAT
This module describes the basic tasks to configure an Application Level Gateway (ALG) with Network Address Translation (NAT). This module also provides information about the protocols that use ALG for IP header translation.
NAT performs translation service on any TCP/UDP traffic that does not carry the source and destination IP addresses in the application data stream. These protocols include HTTP, TFTP, telnet, archie, finger, Network Time Protocol (NTP), Network File System (NFS), remote login (rlogin), remote shell (rsh) protocol, and remote copy (rcp). Specific protocols that do embed IP the address information within the payload require support of an ALG.
NAT with an ALG will translate packets from applications that do not use H.323, as long as the applications use port 1720.
The Support for IPsec ESP Through NAT feature provides the ability to support multiple concurrent IPsec Encapsulating Security Payload (ESP) tunnels or connections through a Cisco IOS NAT device configured in Overload or Port Address Translation (PAT) mode.
- Finding Feature Information
- Prerequisites for Using Application Level Gateways with NAT
- Restrictions for Using Application Level Gateways with NAT
- Information About Using Application Level Gateways with NAT
- How to Configure Application Level Gateways with NAT
- Configuration Examples for Using Application Level Gateways with NAT
- Where to Go Next
- Additional References
- Feature Information for Using Application Level Gateways with NAT
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see 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 at the end of this document.
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.
Prerequisites for Using Application Level Gateways with NAT
- Before performing the tasks in this module, you should be familiar with the concepts described in the “Configuring NAT for IP Address Conservation” module.
- All access lists required for use with the tasks in this module should be configured prior to beginning the configuration task. For information about how to configure an access list, see the “IP Access List Sequence Numbering” document.
Restrictions for Using Application Level Gateways with NAT
NAT will translate only embedded IP version 4 addresses.
Information About Using Application Level Gateways with NAT
- Application Level Gateway
- IP Security
- Voice and Multimedia over IP Networks
- NAT Support of H.323 v2 RAS
- NAT Support for H.323 v3 and v4 in v2 Compatibility Mode
- NAT H.245 Tunneling Support
- NAT Support of Skinny Client Control Protocol
- NAT Support of SCCP Fragmentation
- NAT Segmentation with Layer 4 Forwarding
Application Level Gateway
An application level gateway is an application that translates IP address information inside the payload of an applications packet.
Benefits of Configuring NAT ALG
- NAT support for SIP adds the ability to deploy Cisco IOS NAT between VoIP solutions based on SIP.
- Customers can control their IP address scheme and include complete support for H.323 v2 gatekeeper designs.
- NAT enables customers to deploy private IP addresses within their network and perform translation to public IP addresses when connecting to the Internet or interconnecting with another corporate network.
- Normally ESP entries in the translation table are delayed from being transmitted until a reply is received from the destination. With predictable security parameter indexes (SPIs) and SPI matching, the delay can be eliminated because the SPI entries are matched. Some third-party concentrators require both the source and incoming ports to use port 500. Use of the preserve-port keyword with the ip nat service command preserves the ports rather than changing one, which is required with regular NAT.
IP Security
IPsec is a set of extensions to the IP protocol family in a framework of open standards for ensuring secure private communications over the Internet. Based on standards developed by the IETF, IPsec ensures confidentiality, integrity, and authenticity of data communications across the public network and provides cryptographic security services.
Secure tunnels between two peers, such as two routers, are provided and decisions are made as to which packets are considered sensitive and should be sent through these secure tunnels, and which parameters should be used to protect these sensitive packets by specifying characteristics of these tunnels. When the IPsec peer receives a sensitive packet, it sets up the appropriate secure tunnel and sends the packet through the tunnel to the remote peer.
IPsec using ESP can pass through a router running NAT without any specific support from it as long as Network Address Port Translation (NAPT) or address overloading is not configured.
There are a number of factors to consider when attempting an IPsec VPN connection that traverses a NAPT device that represents multiple private internal IP addresses as a single public external IP address. Such factors include the capabilities of the VPN server and client, the capabilities of the NAPT device, and whether more than one simultaneous connection is attempted across the NAPT device.
There are two possible methods for configuring IPsec on a router with NAPT:
- Encapsulate IPsec in a Layer 4 protocol such as TCP or UDP. In this case, IPsec is sneaking through NAT. The NAT device is unaware of the encapsulation.
- Add IPsec specific support to NAPT. IPsec works with NAT in this case as opposed to sneaking through NAT. The NAT Support for IPsec ESP-- Phase II feature provides support for Internet Key Exchange (IKE) and ESP without encapsulation in tunnel mode through a Cisco IOS router configured with NAPT.
The recommended protocols to use when conducting IPsec sessions that traverse a NAPT device are TCP and UDP, but not all VPN servers or clients support TCP or UDP.
SPI Matching
Security Parameter Index ( SPI) matching is used to establish VPN connections between multiple pairs of destinations. NAT entries will immediately be placed in the translation table for endpoints matching the configured access list. SPI matching is available only for endpoints that choose SPIs according to the predictive algorithm implemented in Cisco IOS Release 12.2(15)T.
Voice and Multimedia over IP Networks
SIP is a protocol developed by the IETF Multiparty Multimedia Session Control (MMUSIC) Working Group. The Cisco SIP functionality equips Cisco routers to signal the setup of voice and multimedia calls over IP networks. SIP provides an alternative to H.323 within the VoIP internetworking software.
Session Description Protocol (SDP) is a protocol that describes multimedia sessions. SDP may be used in SIP message bodies to describe multimedia sessions used for creating and controlling multimedia sessions with two or more participants.
The NAT Support for SIP feature allows SIP embedded messages passing through a router configured with NAT to be translated and encoded back to the packet. An ALG is used with NAT to translate the SIP or SDP messages.
Note |
By default support for SIP is enabled on port 5060. Therefore, NAT-enabled devices interpret all packets on this port as SIP call messages. If other applications in the system use port 5060 to send packets, the NAT service may corrupt the packet as it attempts to interpret the packet as a SIP call message. |
NAT Support of H.323 v2 RAS
Cisco IOS NAT supports all H.225 and H.245 message types, including those sent in the Registration, Admission, and Status (RAS) protocol. RAS provides a number of messages that are used by software clients and VoIP devices to register their location, request assistance in call setup, and control bandwidth. The RAS messages are directed toward an H.323 gatekeeper.
Some RAS messages include IP addressing information in the payload, typically meant to register a user with the gatekeeper or learn about another user already registered. If these messages are not known to NAT, they cannot be translated to an IP address that will be visible to the public.
In Cisco IOS Release 12.2(2)T and later releases, embedded IP addresses can be inspected for potential address translation. Prior to Cisco IOS Release 12.2(2)T, NAT did not support H.323 v2 RAS messages.
NAT Support for H.323 v3 and v4 in v2 Compatibility Mode
H.323 is an ITU-T specification for transmitting audio, video, and data across a packet network. NAT supports four versions of the H.323 protocols: v1, v2, v3, and v4. The NAT Support for H.323 v3 and v4 in v2 Compatibility Mode feature enables Cisco NAT routers to support messages coded in H.323 v3 and v4 when those messages contain fields compatible with H.323 v2. This feature does not add support for H.323 capabilities introduced in v3 and v4, such as new message types or new fields that require address translation.
NAT H.245 Tunneling Support
NAT H.245 tunneling allows H.245 tunneling in H.323 ALGs. NAT H.245 tunneling provides a mechanism for supporting the H.245 tunnel message that is needed to create a media channel setup.
In order for an H.323 call to take place, an H.225 connection on TCP port 1720 needs to be opened. When the H.225 connection is opened, the H.245 session is initiated and established. This connection can take place on a separate channel from the H.225 or it can be done using H.245 tunneling on the same H.225 channel whereby the H.245 messages are embedded in the H.225 messages and sent on the previously established H.225 channel.
If the H.245 tunneled message is not understood, the media address or port will be left untranslated by the Cisco IOS NAT, resulting in failure in media traffic. H.245 FastConnect procedures will not help because FastConnect is terminated as soon as an H.245 tunneled message is sent.
NAT Support of Skinny Client Control Protocol
Cisco IP phones use the SCCP to connect with and register to Cisco CallManager.
To be able to configure Cisco IOS NAT between the IP phone and Cisco CallManager in a scalable environment, NAT needs to be able to detect the SCCP and understand the information passed within the messages. Messages flow back and forth that include IP address and port information used to identify other IP phone users with which a call can be placed.
The SCCP client to Cisco CallManager communication typically flows from inside to outside. Domain Name System (DNS) should be used to resolve the Cisco CallManager IP address connection when the Cisco CallManager is on the inside (behind the NAT device), or static NAT should be configured to reach the Cisco CallManager in the inside.
When an IP phone attempts to connect to the Cisco CallManager and it matches the configured NAT rules, NAT will translate the original source IP address and replace it with one from the configured pool. This new address will be reflected in the Cisco CallManager and be visible to other IP phone users.
NAT Support of SCCP Fragmentation
Skinny control messages are exchanged over TCP. If either the IP phone or Cisco CallManager has been configured to have a TCP maximum segment size (MSS) lower than the skinny control message payload, the skinny control message will be segmented across multiple TCP segments. Prior to this feature skinny control message exchanges would fail in a TCP segmentation scenario because NAT skinny ALG was not able to reassemble the skinny control messages. The NAT SCCP Fragmentation Support feature adds support for TCP segments for NAT skinny ALG. A fragmented payload that requires an IP or port translation will no longer be dropped.
Skinny control messages can also be IP fragmented but they are supported using Virtual Fragmentation Reassembly (VFR).
In Cisco IOS Release 15.1(3)T and later releases, NAT works with SCCP phones version 17 and higher.
NAT Segmentation with Layer 4 Forwarding
The NAT Segmentation with Layer 4 Forwarding feature is implemented for the H.323, SCCP, and TCP DNS protocols. NAT supports the processing of segmented H.323, SCCP, or TCP DNS messages that are split across multiple packets.
Layer 4 forwarding or TCP proxy is responsible for session handling that includes putting the sequence numbers in order, acknowledging the numbers in a packet, resegmenting the translated packet if it is larger than the MSS, and handling retransmissions in case of packet loss. Layer 4 forwarding also handles out-of-order packets. These packets are buffered and not dropped.
Layer 4 forwarding buffers the received packets and notifies NAT ALG when an in-order packet is available. It also sends acknowledgments to the end hosts for the received packets. Layer 4 forwarding also sends the translated packets that it receives from NAT ALG back into the output packet path.
Restrictions
The NAT Segmentation with Layer 4 Forwarding feature does not work when:
- Cisco IOS firewalls are configured using the ip inspect name command. (Zone-based firewalls are supported.)
- H.323, SCCP, or TCP DNS messages are larger than 18 KB.
- Multiprotocol Label Switching (MPLS) is configured.
- NAT and the Cisco CallManager are configured on the same device. In this case, the colocated solution in Call Manager Express (CME) is used.
- NAT Virtual Interface (NVI) is configured.
- Stateful Network Address Translation (SNAT) is enabled.
- The match-in-vrf keyword is configured along with the ip nat inside source command for packet translation.
- The packets are IPv6 packets.
How to Configure Application Level Gateways with NAT
Configuring IPsec Through NAT
To successfully configure application level gateways with NAT, you should understand the following concepts:
This section contains the following tasks related to configuring IPsec through NAT:
- Configuring IPsec ESP Through NAT
- Enabling the Preserve Port
- Enabling SPI Matching on the NAT Device
- Enabling SPI Matching on the Endpoints
- Enabling MultiPart SDP Support for NAT
Configuring IPsec ESP Through NAT
IPsec ESP Through NAT provides the ability to support multiple concurrent IPsec ESP tunnels or connections through a Cisco IOS NAT device configured in Overload or PAT mode.
Perform this task to configure IPsec ESP through NAT.
Note |
IPsec can be configured for any NAT configuration, not just static NAT configurations. |
DETAILED STEPS
Enabling the Preserve Port
This task is used for IPsec traffic using port 500 for the source port. Perform this task to enable port 500 to be preserved for the source port.
Note |
This task is required by certain VPN concentrators. Cisco VPN devices generally do not use this feature. > |
DETAILED STEPS
Enabling SPI Matching on the NAT Device
Note |
SPI matching is disabled by default. |
Security parameter index (SPI) matching is used to establish VPN connections between multiple pairs of destinations. NAT entries are immediately placed in the translation table for endpoints matching the configured access list. SPI matching is available only for endpoints that choose SPIs according to the predictive algorithm implemented in Cisco IOS Release 12.2(15)T.
The generation of SPIs that are predictable and symmetric is enabled. SPI matching should be used in conjunction with NAT devices when multiple ESP connections across a NAT device are desired.
Cisco IOS software must be running on both the source router and the remote gateway enabling parallel processing.
Note |
SPI matching must be configured on the NAT device and both endpoint devices. > |
DETAILED STEPS
Enabling SPI Matching on the Endpoints
Perform this task to enable SPI matching on both endpoints.
Cisco IOS software must be running on both the source router and the remote gateway enabling parallel processing.
Note |
SPI matching must be configured on the NAT device and both endpoint devices. |
DETAILED STEPS
Enabling MultiPart SDP Support for NAT
The MultiPart SDP Support for NAT feature provides support for multipart SDP in a SIP ALG for the Advanced NAT portfolio. MultiPart SDP support for NAT is disabled by default.
Perform this task to enable multipart SDP support for NAT.
Note |
NAT will translate only embedded IP version 4 addresses. > |
DETAILED STEPS
Configuring NAT Between an IP Phone and Cisco CallManager
This section describes configuring Cisco’s Skinny Client Control Protocol (SCCP) for Cisco IP phone to Cisco CallManager communication. The task in this section configures NAT between an IP phone and Cisco CallManager.
DETAILED STEPS
Configuration Examples for Using Application Level Gateways with NAT
- Example Configuring IPsec ESP Through NAT
- Example Enabling the Preserve Port
- Example Enabling SPI Matching
- Example Configuring SPI Matching on the Endpoint Routers
- Example Enabling MultiPart SDP Support for NAT
- Example Configuring NAT Between an IP Phone and Cisco CallManager
Example Configuring IPsec ESP Through NAT
The following example shows NAT configured on the provider edge (PE) router with a static route to the shared service for the vrf1 and vrf2 VPNs. NAT is configured as inside source static 1-to-1 translations.
ip nat pool outside 192.0.2.1 192.0.2.14 netmask 255.255.255.0 ip nat outside source list 1 pool mypool access-list 1 permit 192.0.2.3 0.0.0.255 ip nat inside source static 192.0.2.23 192.0.2.22 vrf vrf1 ip nat inside source static 192.0.2.21 192.0.2.2 vrf vrf2
Example Enabling the Preserve Port
The following example shows how to configure TCP port 500 of the third-party concentrator. Access list 10 is configured:
ip nat service list 10 IKE preserve-port access-list 10 permit 10.1.1.1
Example Enabling SPI Matching
The following example shows how to enable SPI matching. Access list 10 is configured:
ip nat service list 10 ESP spi-match access-list 10 permit 10.1.1.1
Example Configuring SPI Matching on the Endpoint Routers
The following example show how to enable SPI matching on the endpoint routers:
crypto ipsec nat-transparency spi-matching
Example Enabling MultiPart SDP Support for NAT
The following example shows how to enable multipart SDP support for NAT:
ip nat service allow-multipart
Example Configuring NAT Between an IP Phone and Cisco CallManager
The following example shows how to configure the 20002 port of the Cisco CallManager:
ip nat service skinny tcp port 20002
Where to Go Next
- To learn about NAT and configure NAT for IP address conservation, see the “Configuring NAT for IP Address Conservation” module.
- To verify monitor, and maintain NAT, see the “Monitoring and Maintaining NAT” module.
- To integrate NAT with MPLS VPNs, see the “Integrating NAT with MPLS VPNs” module.
- To configure NAT for high availability, see the “Configuring NAT for High Availability” module.
Additional References
Related Documents
Related Topic |
Document Title |
---|---|
Cisco IOS commands |
|
NAT commands: complete command syntax, command mode, defaults, usage guidelines, and examples |
Cisco IOS IP Addressing Services Command Reference |
IP access list sequence numbering |
"IP Access List Sequence Numbering" document |
Standards
Standards |
Title |
---|---|
None |
-- |
MIBs
MIBs |
MIBs Link |
---|---|
None |
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL: |
Technical Assistance
Description |
Link |
---|---|
The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password. |
Feature Information for Using Application Level Gateways with NAT
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.
Table 1 | Feature Information for Using Application Level Gateways with NAT |
Feature Name |
Releases |
Feature Configuration Information |
---|---|---|
MultiPart SDP Support for NAT |
15.0(1)M |
The MultiPart SDP Support for NAT feature adds support for multipart SDP in a SIP ALG for the Advanced NAT Portfolio. This feature is disabled by default. The following commands were modified by this feature: debug ip nat, ip nat service. |
NAT H.245 Tunneling Support |
12.3(11)T |
The NAT H.245 Tunneling Support feature allows H.245 tunneling in H.323 Application Level Gateways (ALGs). |
NAT SCCP Fragmentation Support |
12.4(6)T 15.1(3)T |
The NAT SCCP Fragmentation Support feature adds support for TCP segments for NAT skinny ALG. A fragmented payload that requires an IP or port translation will no longer be dropped. In Cisco IOS Release 15.1(3)T, the NAT Segmentation with Layer 4 Forwarding feature was introduced. The following command was modified by this feature: debug ip nat. |
NAT Support for H.323 v2 RAS feature |
12.2(2)T 15.0(1)S |
Cisco IOS NAT supports all H.225 and H.245 message types, including those sent in the RAS protocol. |
NAT Support for H.323 v3 and v4 in v2 Compatibility Mode |
12.3(2)T |
The NAT Support for H.323 v3 and v4 in v2 Compatibility Mode feature enables Cisco NAT routers to support messages coded in H.323 v3 and v4 when those messages contain fields compatible with H.323 v2. This feature does not add support for H.323 capabilities introduced in v3 and v4, such as new message types or new fields that require address translation. |
NAT Support for IPsec ESP--Phase II |
12.2(15)T |
The NAT Support for IPsec ESP-- Phase II feature provides support for Internet Key Exchange (IKE) and ESP without encapsulation in tunnel mode through a Cisco IOS router configured with NAPT. |
NAT Support for SIP |
12.2(8)T |
NAT Support for SIP adds the ability to configure Cisco IOS NAT between VoIP solutions based on SIP. |
Support for applications that do not use H.323 |
12.2(33)XNC |
NAT with an ALG will translate packets from applications that do not use H.323, as long as the applications use port 1720. |
Support for IPsec ESP Through NAT |
12.2(13)T |
IPsec ESP through NAT provides the ability to support multiple concurrent IPsec Encapsulating Security Payload (ESP) tunnels or connections through a Cisco IOS Network Address Translation (NAT) device configured in Overload or Port Address Translation (PAT) mode. |
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.