Using Application Level Gateways with NAT

An application level gateway is an application that translates IP address information inside the payload of an applications packet.

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.

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.

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.

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 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.

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.

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.

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.

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
  

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ip nat service skinny tcp port number

DETAILED STEPS

	Command or Action	Purpose
Step 1	enable Example: Router> enable	Enables privileged EXEC mode. Enter your password if prompted.
Step 2	configure terminal Example: Router# configure terminal	Enters global configuration mode.
Step 3	ip nat service skinny tcp port number Example: Router(config)# ip nat service skinny tcp port 20002	Configures the skinny protocol on the specified TCP port.