Using Application Level Gateways with NAT
Using Application-Level Gateways with NAT
Last Updated: June 6, 2012
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 ALGs for IP header translation.
NAT performs translation services on any TCP/UDP traffic that does not carry source and destination IP addresses in the application data stream. Protocols that do not carry the source and destination IP addresses 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 embed the IP address information within the payload require the support of an ALG. NAT requires a variety of ALGs to handle application data stream (Layer 7) protocol-specific services such as translating embedded IP addresses and port numbers in the packet payload and extracting new connection/session information from control channels.
NAT supports virtual routing and forwarding (VRF) for protocols that have a supported ALG.
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 NAT device configured in Overload or Port Address Translation (PAT) mode.
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 Toolkit 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 at the end of this module.
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
Restrictions for Using Application-Level Gateways with NAT
Information About Using Application-Level Gateways with NAT
An application-level gateway (ALG), also known as an application-layer gateway, is an application that translates IP address information inside the payload of an application packet. An ALG is used to interpret the application-layer protocol and perform firewall and NAT actions. These actions can be one or more of the following, depending on your configuration of the firewall and NAT:
The firewall opens a pinhole and NAT performs translation service on any TCP or UDP traffic that does not carry the source and destination IP addresses in the application-layer data stream. Specific protocols or applications that embed IP address information require the support of an ALG.
IPsec is a set of extensions to the IP 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 the characteristics of these tunnels. When the IPsec peer receives a sensitive packet, the peer sets up the appropriate secure tunnel and sends the packet through the tunnel to the remote peer.
IPsec using Encapsulating Security Payload (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. These factors include capabilities of the VPN server and client, 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 device with NAPT:
We recommend that TCP and UDP be used when conducting IPsec sessions that traverse a NAPT device. However, not all VPN servers or clients support TCP or UDP.
Benefits of Configuring NAT IPsec
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.
NAT Support for Application-Level Gateways
The following section provides information on NAT support for ALGs.
The features described in the following subsections are enabled by default unless otherwise noted; no configuration is necessary:
NAT Support of H.323 v2 RAS
NAT supports all H.225 and H.245 message types, including those sent in the Remote Access Service (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. 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 to learn about another user already registered. If these messages are not known to NAT, they cannot be translated to an IP address that is visible to the public.
Embedded IP addresses can be inspected for potential address translation.
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 packet networks. NAT supports four versions of the H.323 protocols: Version 1, Version 2, Version 3, and Version 4. The NAT Support for H.323 v3 and v4 in v2 Compatibility Mode feature enables NAT routers to support messages coded in H.323 Version 3 and Version 4 when these messages contain fields that are compatible with H.323 Version 2. This feature does not support H.323 capabilities introduced in H.323 Version 3 and Version 4, such as new message types or new fields that require address translation.
NAT H.245 Tunneling Support
The NAT H.245 Tunneling Support feature supports H.245 tunneling in H.323 ALGs. The H.245 tunneling supports H.245 tunnel messages that are needed to create a media channel setup.
For an H.323 call to take place, an H.225 connection on TCP port 1720 must be opened. When the H.225 connection is opened, the H.245 session is initiated and established. The H.323 connection can take place on a separate channel other than the H.225 or it can be done by using H.245 tunneling on the same H.225 channel whereby the H.245 messages are embedded in H.225 messages and sent on the previously established H.225 channel.
If the H.245 tunneled message is not understood by NAT, the media address or the port number is left untranslated by NAT, resulting in media traffic failure. The H.245 FastConnect procedures will not help if the H.245 tunneled message is not understood by NAT because FastConnect is terminated as soon as an H.245 tunneled message is sent.
NAT Segmentation with Layer 4 Forwarding
The NAT Segmentation with Layer 4 Forwarding feature is implemented for the H.323, Skinny Client Control Protocol (SCCP), and the TCP Domain Name System (DNS) protocol. 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 setting sequence numbers in order, acknowledging the numbers in a packet, resegmenting the translated packet if it is larger than the maximum segment size (MSS), and handling retransmissions in case of packet loss. Layer 4 forwarding also handles out-of-order packets and these packets are buffered and not dropped. Layer 4 forwarding buffers received packets and notifies the NAT ALG when an in-order packet is available, sends acknowledgments to end hosts for received packets, and sends translated packets that it receives from the NAT ALG back into the output packet path.
The NAT Segmentation with Layer 4 Forwarding feature does not work when:
NAT Support for SIP--Voice and Multimedia over IP Networks
SIP is a protocol developed by the IETF Multiparty Multimedia Session Control (MMUSIC) Working Group. The Cisco Session Initiation Protocol (SIP) functionality equips Cisco devices to signal the setup of voice and multimedia calls over IP networks. SIP provides an alternative to H.323 within 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 device that is configured with NAT to be translated and encoded back to the packet. An ALG is used with NAT to translate SIP messages.
NAT Support of Skinny Client Control Protocol
Cisco IP phones use the Skinny Client Control Protocol (SCCP) to connect with and register to Cisco Unified CallManager.
To deploy NAT between the IP phone and the Cisco Unified CallManager in a scalable environment, NAT must detect SCCP and understand the information that is passed within these messages. Messages that flow back and forth include the IP address and the port information to identify other IP phone users with whom calls can be placed.
The SCCP client to the Cisco Unified CallManager communication typically flows from inside to outside. The Domain Name System (DNS) is used to resolve the Cisco Unified CallManager IP address connection when the Cisco Unified CallManager is configured on the inside (behind the NAT device), or when static NAT is configured to reach the Cisco Unified CallManager on the inside.
When an IP phone attempts to connect to the Cisco Unified CallManager and matches the configured NAT rules, NAT translates the original source IP address and replaces it with one from the configured pool. This new IP address is reflected in the Cisco Unified CallManager and is visible to other IP phone users.
NAT Support of SCCP Fragmentation
Skinny Client Control Protocol (SCCP) messages, also called Skinny control messages, are exchanged over TCP. If either the IP phone or the Cisco Unified CallManager is configured to have a TCP maximum segment size (MSS) lower than the Skinny control message payload, the Skinny control message is segmented across multiple TCP segments. Prior to the introduction of this feature, Skinny control message exchanges used to fail during TCP segmentation because the NAT Skinny ALG was not able to reassemble Skinny control messages. The NAT SCCP Fragmentation Support feature adds support for TCP segments for the NAT Skinny ALG and fragmented payloads that requires an IP translation or a port translation is no longer dropped.
Skinny control messages can also be IP fragmented by 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.
How to Configure Application-Level Gateways with NAT
Configuring IPsec Through NAT
Configuring IPsec ESP Through NAT
The IPsec ESP Through NAT feature provides the ability to support multiple concurrent IPsec ESP tunnels or connections through a NAT device configured in Overload or PAT mode.
Enabling the Preserve Port
This task is used for IPsec traffic using port 500 for the source port and incoming port. 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.
Disabling SPI Matching on the NAT Device or Changing the Default Port
SPI matching is used to establish VPN connections between multiple pairs of destinations. NAT entries are immediately placed in the translation table for endpoints that match the configured access list.
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.
SPI matching is enabled by default for listening on port 2000. You can use this task to either change the default port or to disable SPI matching.
Before You BeginSUMMARY STEPS
Cisco software must be running on both the source device and the remote gateway, enabling parallel processing.
Enabling SPI Matching on Endpoints
Before You BeginSUMMARY STEPS
Cisco software must be running on both the source device and the remote gateway, enabling parallel processing.
Enabling MultiPart SDP Support for NAT
The MultiPart SDP Support for NAT feature provides support for the multipart Session Description Protocol (SDP) in a SIP ALG. MultiPart SDP support for NAT is disabled by default.
Specifying a Port for NAT Translation
The following task describes how to configure SCCP for a Cisco IP phone to Cisco Unified CallManager communication.
Configuration Examples for Using Application-Level Gateways with NAT
Example: Configuring IPsec ESP Through NAT
The following example shows NAT configured on a device with a static route. NAT is configured as inside source static one-to-one 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 esp 192.0.2.23 interface gigabitethernet 0/0/0 ip nat inside source static esp 192.0.2.21 interface gigabitethernet 0/0/1
Example: Enabling the Preserve Port
Example: Disabling SPI Matching on the NAT Device or Changing the Default Port
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.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: 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. (1110R)
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.
© 2012 Cisco Systems, Inc. All rights reserved.