Cisco Security Appliance Command Line Configuration Guide, Version 7.0 - Applying Application Layer Protocol Inspection [Cisco ASA 5500 Series Adaptive Security Appliances]

Table Of Contents

Applying Application Layer Protocol Inspection

Application Inspection Engines

Overview

How Inspection Engines Work

Supported Protocols

Applying Application Inspection to Selected Traffic

Overview

Identifying Traffic with a Traffic Class Map

Using an Application Inspection Map

Defining Actions with a Policy Map

Applying a Security Policy to an Interface

Managing CTIQBE Inspection

CTIQBE Inspection Overview

Limitations and Restrictions

Enabling and Configuring CTIQBE Inspection

Verifying and Monitoring CTIQBE Inspection

Managing DNS Inspection

How DNS Application Inspection Works

How DNS Rewrite Works

Configuring DNS Rewrite

Using the Alias Command for DNS Rewrite

Using the Static Command for DNS Rewrite

Configuring DNS Rewrite

DNS Rewrite with Three NAT Zones

Configuring DNS Rewrite with Three NAT Zones

Configuring DNS Inspection

Verifying and Monitoring DNS Inspection

Managing FTP Inspection

FTP Inspection Overview

Using the strict Option

Configuring FTP Inspection

Verifying and Monitoring FTP Inspection

Managing GTP Inspection

GTP Inspection Overview

Enabling and Configuring GTP Inspection

Enabling and Configuring GSN Pooling

Verifying and Monitoring GTP Inspection

Managing H.323 Inspection

H.323 Inspection Overview

How H.323 Works

Limitations and Restrictions

Enabling and Configuring H.323 Inspection

Configuring H.225 Timeout Values

Verifying and Monitoring H.323 Inspection

Monitoring H.225 Sessions

Monitoring H.245 Sessions

Monitoring H.323 RAS Sessions

Managing HTTP Inspection

HTTP Inspection Overview

Enabling and Configuring Advanced HTTP Inspection

Managing IPSec Pass Through Inspection

IPSec Pass Through Inspection Overview

Enabling and Configuring IPSec Pass Through Inspection

Managing MGCP Inspection

MGCP Inspection Overview

Configuring MGCP Call Agents and Gateways

Configuring and Enabling MGCP Inspection

Configuring MGCP Timeout Values

Verifying and Monitoring MGCP Inspection

Managing RTSP Inspection

RTSP Inspection Overview

Using RealPlayer

Restrictions and Limitations

Configuring RTSP Inspection

Managing SIP Inspection

SIP Inspection Overview

SIP Instant Messaging

Enabling and Configuring SIP Inspection

Configuring SIP Timeout Values

Verifying and Monitoring SIP Inspection

Managing Skinny (SCCP) Inspection

SCCP Inspection Overview

Supporting Cisco IP Phones

Restrictions and Limitations

Verifying and Monitoring SCCP Inspection

Managing SMTP and Extended SMTP Inspection

SMTP and Extended SMTP Inspection Overview

Enabling and Configuring SMTP and Extended SMTP Application Inspection

Managing SNMP Inspection

SNMP Inspection Overview

Enabling and Configuring SNMP Application Inspection

Managing Sun RPC Inspection

Sun RPC Inspection Overview

Enabling and Configuring Sun RPC Inspection

Managing Sun RPC Services

Verifying and Monitoring Sun RPC Inspection

Applying Application Layer Protocol Inspection

This chapter describes how to use and configure application inspection. This chapter includes the following sections:

•Application Inspection Engines

•Applying Application Inspection to Selected Traffic

•Managing CTIQBE Inspection

•Managing DNS Inspection

•Managing FTP Inspection

•Managing GTP Inspection

•Managing H.323 Inspection

•Managing HTTP Inspection

•Managing IPSec Pass Through Inspection

•Managing MGCP Inspection

•Managing RTSP Inspection

•Managing SIP Inspection

•Managing Skinny (SCCP) Inspection

•Managing SMTP and Extended SMTP Inspection

•Managing SNMP Inspection

•Managing Sun RPC Inspection

Application Inspection Engines

This section describes how application inspection engines work. This section includes the following topics:

•Overview

•How Inspection Engines Work

•Supported Protocols

Overview

The Adaptive Security Algorithm, used by the security appliance for stateful application inspection, ensures the secure use of applications and services. Some applications require special handling by the security appliance and specific application inspection engines are provided for this purpose. Applications that require special application inspection engines are those that embed IP addressing information in the user data packet or open secondary channels on dynamically assigned ports.

Application inspection engines work with NAT to help identify the location of embedded addressing information. This allows NAT to translate these embedded addresses and to update any checksum or other fields that are affected by the translation.

Each application inspection engine also monitors sessions to determine the port numbers for secondary channels. Many protocols open secondary TCP or UDP ports to improve performance. The initial session on a well-known port is used to negotiate dynamically assigned port numbers. The application inspection engine monitors these sessions, identifies the dynamic port assignments, and permits data exchange on these ports for the duration of the specific session.

How Inspection Engines Work

As illustrated in Figure 21-1, the security appliance uses three databases for its basic operation:

•Access lists —Used for authentication and authorization of connections based on specific networks, hosts, and services (TCP/UDP port numbers).

•Inspections—Contains a static, predefined set of application-level inspection functions.

•Connections (XLATE and CONN tables)—Maintains state and other information about each established connection. This information is used by the Adaptive Security Algorithm and cut-through proxy to efficiently forward traffic within established sessions.

Figure 21-1 Basic Adaptive Security Algorithm Operations

In Figure 21-1, operations are numbered in the order they occur, and are described as follows:

1. A TCP SYN packet arrives at the security appliance to establish a new connection.

2. The security appliance checks the access list database to determine if the connection is permitted.

3. The security appliance creates a new entry in the connection database (XLATE and CONN tables).

4. The security appliance checks the Inspections database to determine if the connection requires application-level inspection.

5. After the application inspection engine completes any required operations for the packet, the security appliance forwards the packet to the destination system.

6. The destination system responds to the initial request.

7. The security appliance receives the reply packet, looks up the connection in the connection database, and forwards the packet because it belongs to an established session.

The default configuration of the security appliance includes a set of application inspection entries that associate supported protocols with specific TCP or UDP port numbers and that identify any special handling required. For certain applications some inspection engines do not support NAT or PAT because of the constraints imposed by the applications. You can change the port assignments for some applications, while other applications have fixed port assignments that you cannot change. Table 21-1 summarizes this information about the application inspection engines provided with the security appliance.

Supported Protocols

Table 21-1 summarizes the type of application inspections that is provided for each protocol supported by the security appliance. The following inspection engines are described in this chapter:

•CTIQBE—See the "Managing CTIQBE Inspection" section

•DNS—See the "Managing DNS Inspection" section

•FTP—See the "Managing FTP Inspection" section

•GTP—See the "Managing GTP Inspection" section

•H.323—See the "Managing H.323 Inspection" section

•HTTP—See the "Managing HTTP Inspection" section

•MGCP—See the "Managing MGCP Inspection" section

•RTSP—See the "Managing RTSP Inspection" section

•SIP—See the "Managing SIP Inspection" section

•Skinny—See the "Managing Skinny (SCCP) Inspection" section

•SMTP/ESMTP—See the "Managing SMTP and Extended SMTP Inspection" section

•SNMP—See the "Managing SNMP Inspection" section

•Sun RPC—See the "Managing Sun RPC Inspection" section

For more information about the inspection engines that are not discussed in this chapter, see the appropriate inspect command pages in the Cisco Security Appliance Command Reference.

Table 21-1 Application Inspection Engines

Application

PAT?

NAT (1-1)?

Configure Port?

Default Port

Standards

Comments

CTIQBE

Yes

Yes

Yes

TCP/2748

—

—

DNS¹

Yes

Yes

No

UDP/53

RFC 1123

Only forward NAT. No PTR records are changed.

FTP

Yes

Yes

Yes

TCP/21

RFC 959

—

GTP

Yes

Yes

Yes

UDP/3386
UDP/2123

—

Requires a special license.

H.323

Yes

Yes

Yes

TCP/1720 UDP/1718
UDP (RAS) 1718-1719

ITU-T H.323, H.245, H225.0, Q.931, Q.932

HTTP

Yes

Yes

Yes

TCP/80

RFC 2616

Beware of MTU limitations stripping ActiveX and Java.²

ICMP

Yes

Yes

No

—

—

—

ICMP ERROR

Yes

Yes

No

—

—

—

ILS (LDAP)

Yes

Yes

Yes

—

—

—

MGCP

Yes

Yes

Yes

2427, 2727

RFC 2705bis-05

—

NBDS / UDP

Yes

Yes

No

UDP/138

—

—

NBNS / UDP

No

No

No

UDP/137

—

No WINS support.

NetBIOS over IP³

No

No

No

—

—

—

PPTP

Yes

Yes

Yes

1723

RFC 2637

—

RSH

Yes

Yes

Yes

TCP/514

Berkeley UNIX

—

RTSP

No

No

Yes

TCP/554

RFC 2326, 2327, 1889

No handling for HTTP cloaking.

SIP

Yes

Yes

Yes

TCP/5060
UDP/5060

RFC 2543

—

SKINNY (SCCP)

Yes

Yes

Yes

TCP/2000

—

Does not handle TFTP uploaded Cisco IP Phone configurations under certain circumstances.

SMTP/ESMTP

Yes

Yes

Yes

TCP/25

RFC 821, 1123

—

SNMP

No

No

Yes

161, 162

RFC 1155, 1157, 1212, 1213, 1215

v.2 RFC 1902-1908; v.3 RFC 2570-2580.

SQL*Net

Yes

Yes

Yes

TCP/1521

—

v.1 and v.2.

Sun RPC

No

Yes

No

UDP/111 TCP/111

—

Payload not NATed.

XDCMP

No

No

No

UDP/177

—

—

¹No NAT support is available for name resolution through WINS.

²If the MTU is too small to allow the Java or ActiveX tag to be included in one packet, stripping may not occur.

³NetBIOS is supported by performing NAT of the packets for NBNS UDP port 137 and NBDS UDP port 138.

Applying Application Inspection to Selected Traffic

This section describes how to identify traffic to which you want to apply an inspection engine, how to associate the inspection engine with a particular security policy, and how to apply the policy to one or more interfaces on the security appliance. This section includes the following topics:

•Overview

•Identifying Traffic with a Traffic Class Map

•Using an Application Inspection Map

•Defining Actions with a Policy Map

•Applying a Security Policy to an Interface

Overview

Application inspection is enabled by default for many protocols, while it is disabled for other protocols. In most cases, you can change the port on which the application inspection listens for traffic. To change the default configuration for application inspection for any application inspection engine, use the Modular Policy Framework CLI.

Modular Policy Framework provides a consistent and flexible way to configure security appliance features in a manner to similar to Cisco IOS software Modular Quality of Server (QoS) CLI.

To use Modular Policy Framework to enable application inspection, perform the following steps:

Step 1 (Optional) Define a traffic class by entering the class-map command.

A traffic class is a set of traffic that is identifiable by its packet content. You only need to perform this step if you want to change the default port assignments for application inspection or identify traffic to be subjected to application inspection using other criteria, such as the IP address. For a list of default port assignments used for application inspection, see Table 21-1.

Step 2 Create a policy map by associating the traffic class with one or more actions by entering the policy-map command.

An action is a security feature, such as application inspection, that helps protect information or resources on one or more protected network interfaces. Application inspection for a specific protocol is one type of action that can be applied using Modular Policy Framework.

Step 3 (Optional) Use an application inspection map to change the parameters used for certain application inspection engines.

The application inspection map command enables the configuration mode for a specific application inspection engine, from where you can enter the commands required to change the configuration. The supported application inspection map commands include the following:

•ftp-map—See Managing FTP Inspection.

•gtp-map—See Managing GTP Inspection.

•http-map—See Managing HTTP Inspection.

•mgcp-map—See Managing MGCP Inspection.

•snmp-map—See Managing SNMP Inspection.

For detailed information about the syntax for each of these commands, see the Cisco Security Appliance Command Reference.

Step 4 Create a security policy by associating the policy map with one or more interfaces by entering the service-policy command.

A security policy associates a previously defined traffic class with a security-related action and applies it to a specific interface.

You can associate more than one traffic class with a single action and more than one action with a specific traffic class. You can associate all interfaces with a traffic class by entering the global option, or multiple interfaces by entering the service-policy command on separate interfaces.

Identifying Traffic with a Traffic Class Map

A traffic class map contains a name and one match command. The match command identifies the traffic included in the traffic class. The name can be any string of alphanumeric characters.

Match commands can include different criteria to define the traffic included in the class map. For example, you can use one or more access lists to identify specific types of traffic. The permit command in an access control entry causes the traffic to be included, while a deny command causes the traffic to be excluded from the traffic class map. For more information about configuring access lists, see Chapter 9, "Identifying Traffic with Access Control Lists," in the Cisco Security Appliance Command Line Configuration Guide.

After a traffic class is applied to an interface, packets received on that interface are compared to the criteria defined by the match commands in the class map.

If the packet matches the specified criteria, it is included in the traffic class and is subjected to any action, such as application inspection, that is associated with that traffic class. Packets that do not match any of the criteria in any traffic class are assigned to the default traffic class.

To define a traffic class map, perform the following steps:

Step 1 To use an access list to define the traffic class, define the access list in global configuration mode, as in the following example:
hostname(config)# access-list http_acl permit tcp any any eq 80
The http_acl access list in this example includes traffic on port 80. To enable traffic on more than one non-contiguous port, enter the access-list command to create an access control entry for each port.

For the complete syntax of the access-list command see the access-list command page in the Cisco Security Appliance Command Reference.
Step 2 Name the traffic class by entering the following command in global configuration mode:
hostname(config)# class-map class_map_name
Replace class_map_name with the name of the traffic class, as in the following example:
hostname(config)# class-map http_port
When you enter the class-map command, the CLI enters the class map configuration mode, and the prompt changes, as in the following example:
hostname(config-cmap)#
Step 3 In the class map configuration mode, define the traffic to include in the class by entering the following command:
hostname(config-cmap)# match any | access-list acl_ID | {port tcp | udp {eq port_num | 
range port_num port_num}}
Use the any option to include all traffic in the traffic class. Use the access-list option 
to match the criteria defined in a specific access list. Use the port option to identify a 
specific port number or a range of port numbers. 
Note For applications that use multiple ports that are not within a continuous range, enter the access-list option and define an access control entry to match each port.

The following example uses the port option to assign the default port to the current traffic class:
hostname(config-cmap)# match port tcp eq 80
The following example uses the access-list option to assign traffic identified by the access control entries in the http_acl access list:
hostname(config-cmap)# match access-list http_acl
You can also enter the match command to identify traffic based on IP precedence, DSCP (QoS) value, RTP port, or tunnel group. For the complete syntax of the match command, see the Cisco Security Appliance Command Reference.

Step 4 To apply application inspection to the default port assignments for every application and protocol, enter the following command:
hostname(config-cmap)# match default-inspection-traffic
This command overrides any other port assignments made by entering another match command. However, it can be used with another match command that specifies other criteria, such as destination or source IP address. Table 21-2 lists the default port assignments for different protocols.

Table 21-2 Default Port Assignments

Protocol Name

Protocol

Port

ctiqbe

tcp

2748

dns

udp

53

ftp

tcp

21

gtp

udp

2123,3386

h323 h225

tcp

1720

h323 ras

udp

1718-1719

http

tcp

80

icmp

icmp

N/A

ils

tcp

389

mgcp

udp

2427,2727

netbios

udp

N/A

sunrpc

udp

111

rsh

tcp

514

rtsp

tcp

554

sip

tcp, udp

5060

skinny

tcp

2000

smtp

tcp

25

sqlnet

tcp

1521

tftp

udp

69

xdmcp

udp

177

Step 5 To return to global configuration mode, enter the following command:
hostname(config-cmap)# exit
hostname(config)#
Using an Application Inspection Map

Some application inspection engines have configurable parameters that are used to control application inspection. The default value of these parameters may work without modification, but if you need to fine tune control of the application inspection engine, use an application inspection map. The following procedure provides the general steps required to create an application inspection map.

To use an application inspection map, perform the following steps:

Step 1 Create an application inspection map by entering the following command:
hostname(config)# application-map application_map_name
Replace application with the type of application inspection. Replace application_map_name with the name of the application inspection map, for example:
hostname(config)# http-map inbound_http
This example causes the system to enter HTTP map configuration mode and the CLI prompt changes as follows:
hostname(config-http-map)#
Step 2 Define the configuration of the application inspection map by entering any of the supported commands. To display a list of the supported commands, type a question mark (?) from within the application.
hostname(config-http-map)# ?
Http-map configuration commands:
  content-length             Content length range inspection
  content-type-verification  Content type inspection
  max-header-length          Maximum header size inspection
  max-uri-length             Maximum URI size inspection
  no                         Negate a command or set its defaults
  port-misuse                Application inspection
  request-method             Request method inspection
  strict-http                Strict HTTP inspection
  transfer-encoding          Transfer encoding inspection
hostname(config-http-map)# strict-http
hostname(config-http-map)#
Step 3 Return to global configuration mode:
hostname(config-http-map)# exit
hostname(config)#
Defining Actions with a Policy Map

You use a policy map to associate a traffic class map with a specific action, such as application inspection for a particular protocol. To define a policy map, assign a name to the policy with the policy-map command and then list one or more traffic class maps and one or more actions that should be taken on packets that belong to the given traffic class.

Note A packet is assigned to the first matching traffic class in the policy map.

To create a policy map by associating an action with a traffic class, perform the following steps:

Step 1 Name the policy map by entering the following command:
hostname(config)# policy-map policy_map_name 
For example, the following command creates or modifies the sample_policy policy map:
(config)# policy-map sample_policy 
The CLI enters the policy map configuration mode and the prompt changes accordingly, as follows:
hostname(config-pmap)# 
Step 2 Specify one or more traffic classes to be included in the traffic policy, as in the following example:
hostname(config-pmap)# class class_map_name
For example, the following command creates the http_port policy map:
hostname(config-pmap)# class http_port
The CLI enters the class map configuration mode and the prompt changes accordingly, as follows:
hostname(config-pmap-c)# 
Step 3 Enable application inspection by entering the following command:
hostname(config-pmap-c)# inspect protocol application_inspection_map
Use application_inspection_map if you are enabling a protocol that uses an application map for setting configurable parameters. For example, the following command enables HTTP application inspection using the parameters defined using the http_traffic application inspection map.
hostname(config-pmap-c)# inspect http http_traffic
Step 4 To return to policy map configuration mode, enter the following command:
hostname(config-pmap-c)# exit
hostname(config-pmap)# 
Step 5 To return to global configuration mode, enter the following command:
hostname(config-pmap-c)# exit
Applying a Security Policy to an Interface

After defining the policy map, apply the policy map to one or more interfaces on the security appliance by entering the service-policy command in global configuration mode. You can enter the service-policy command to activate a policy map globally on all the security appliance interfaces or on a specific interface.

For example, the following command enables the sample_policy service policy on the outside interface:
hostname(config)# service-policy sample_policy interface outside
To enable the sample_policy service policy on all the security appliance interfaces, enter the following command:
hostname(config)# service-policy sample_policy global
Managing CTIQBE Inspection

This section describes how to enable CTIQBE application inspection and change the default port configuration. This section includes the following topics:

•CTIQBE Inspection Overview

•Limitations and Restrictions

•Enabling and Configuring CTIQBE Inspection

•Verifying and Monitoring CTIQBE Inspection

CTIQBE Inspection Overview

The inspect ctiqbe 2748 command enables CTIQBE protocol inspection, which supports NAT, PAT, and bidirectional NAT. This enables Cisco IP SoftPhone and other Cisco TAPI/JTAPI applications to work successfully with Cisco CallManager for call setup across the security appliance.

TAPI and JTAPI are used by many Cisco VoIP applications. CTIQBE is used by Cisco TSP to communicate with Cisco CallManager.

Limitations and Restrictions

The following summarizes limitations that apply when using CTIQBE application inspection:

•CTIQBE application inspection does not support configurations with the alias command.

•Stateful Failover of CTIQBE calls is not supported.

•Entering the debug ctiqbe command may delay message transmission, which may have a performance impact in a real-time environment. When you enable this debugging or logging and Cisco IP SoftPhone seems unable to complete call setup through the security appliance, increase the timeout values in the Cisco TSP settings on the system running Cisco IP SoftPhone.

The following summarizes special considerations when using CTIQBE application inspection in specific scenarios:

•If two Cisco IP SoftPhones are registered with different Cisco CallManagers, which are connected to different interfaces of the security appliance, calls between these two phones fails.

•When Cisco CallManager is located on the higher security interface compared to Cisco IP SoftPhones, if NAT or outside NAT is required for the Cisco CallManager IP address, the mapping must be static as Cisco IP SoftPhone requires the Cisco CallManager IP address to be specified explicitly in its Cisco TSP configuration on the PC.

•When using PAT or Outside PAT, if the Cisco CallManager IP address is to be translated, its TCP port 2748 must be statically mapped to the same port of the PAT (interface) address for Cisco IP SoftPhone registrations to succeed. The CTIQBE listening port (TCP 2748) is fixed and is not user-configurable on Cisco CallManager, Cisco IP SoftPhone, or Cisco TSP.

Enabling and Configuring CTIQBE Inspection

To enable CTIQBE inspection or change the default port used for receiving CTIQBE traffic, perform the following steps:

Step 1 Name the traffic class by entering the following command in global configuration mode:
hostname(config)# class-map class_map_name
Replace class_map_name with the name of the traffic class, For example:
hostname(config)# class-map ctiqbe_port
When you enter the class-map command, the CLI enters the class map configuration mode, and the prompt changes, as in the following example:
hostname(config-cmap)#
Step 2 In the class map configuration mode, define the match command, as in the following example:
hostname(config-cmap)# match port tcp eq 2748
hostname(config-cmap)# exit
hostname(config)#
To assign a range of continuous ports, enter the range keyword, as in the following example:
hostname(config-cmap)# match port tcp range 2748-2750
To assign more than one non-contiguous port for CTIQBE inspection, enter the access-list command and define an access control entry to match each port. Then enter the match command to associate the access lists with the CTIQBE traffic class.

Step 3 Name the policy map by entering the following command:
hostname(config)# policy-map policy_map_name
Replace policy_map_name with the name of the policy map, as in the following example:
hostname(config)# policy-map sample_policy 
The CLI enters the policy map configuration mode and the prompt changes accordingly, as follows:
hostname(config-pmap)# 
Step 4 Specify the traffic class defined in Step 1 to be included in the policy map by entering the following command:
hostname(config-pmap)# class class_map_name
For example, the following command assigns the ctiqbe_port traffic class to the current policy map:
hostname(config-pmap)# class ctiqbe_port
The CLI enters the policy map class configuration mode and the prompt changes accordingly, as follows:
hostname(config-pmap-c)# 
Step 5 To enable CTIQBE application inspection, enter the following command:
hostname(config-pmap-c)# inspect ctiqbe 
Step 6 Return to policy map configuration mode by entering the following command:
hostname(config-pmap-c)# exit
hostname(config-pmap)#
Step 7 Return to global configuration mode by entering the following command:
hostname(config-pmap)# exit
hostname(config)#
Step 8 Apply the policy map globally or to a specific interface by entering the following command:
hostname(config)# service-policy policy_map_name [global | interface interface_ID
Replace policy_map_name with the policy map you configured in Step 3, and identify all the interfaces with the global option or a specific interface using the name assigned with the nameif command.

For example, the following command applies the sample_policy to the outside interface:
hostname(config)# service-policy sample_policy interface outside
The following command applies the sample_policy to the all the security appliance interfaces:
hostname(config)# service-policy sample_policy global
Example 21-1 Enabling and Configuring CTIQBE Inspection

You enable the CTIQBE inspection engine as shown in the following example, which creates a class map to match CTIQBE traffic on the default port (2748). The service policy is then applied to the outside interface.
hostname(config)# class-map ctiqbe_port
hostname(config-cmap)# match port tcp eq 2748
hostname(config-cmap)# exit
hostname(config)# policy-map sample_policy 
hostname(config-pmap)# class ctiqbe_port
hostname(config-pmap-c)# inspect ctiqbe
hostname(config-pmap-c)# exit
hostname(config)# service-policy sample_policy interface outside
To enable CTIQBE inspection for all interfaces, enter the global parameter in place of interface outside.

Verifying and Monitoring CTIQBE Inspection

The show ctiqbe command displays information regarding the CTIQBE sessions established across the security appliance. It shows information about the media connections allocated by the CTIQBE inspection engine.

The following is sample output from the show ctiqbe command under the following conditions. There is only one active CTIQBE session setup across the security appliance. It is established between an internal CTI device (for example, a Cisco IP SoftPhone) at local address 10.0.0.99 and an external Cisco CallManager at 172.29.1.77, where TCP port 2748 is the Cisco CallManager. The heartbeat interval for the session is 120 seconds.
hostname# # show ctiqbe
Total: 1
        LOCAL           FOREIGN         STATE   HEARTBEAT
---------------------------------------------------------------
1       10.0.0.99/1117  172.29.1.77/2748        1       120
        ----------------------------------------------
        RTP/RTCP: PAT xlates: mapped to 172.29.1.99(1028 - 1029)
        ----------------------------------------------
        MEDIA: Device ID 27     Call ID 0
               Foreign 172.29.1.99      (1028 - 1029)
               Local   172.29.1.88      (26822 - 26823)
        ----------------------------------------------
The CTI device has already registered with the CallManager. The device internal address and RTP listening port is PATed to 172.29.1.99 UDP port 1028. Its RTCP listening port is PATed to UDP 1029.

The line beginning with RTP/RTCP: PAT xlates: appears only if an internal CTI device has registered with an external CallManager and the CTI device address and ports are PATed to that external interface. This line does not appear if the CallManager is located on an internal interface, or if the internal CTI device address and ports are NATed to the same external interface that is used by the CallManager.

The output indicates a call has been established between this CTI device and another phone at 172.29.1.88. The RTP and RTCP listening ports of the other phone are UDP 26822 and 26823. The other phone locates on the same interface as the CallManager because the security appliance does not maintain a CTIQBE session record associated with the second phone and CallManager. The active call leg on the CTI device side can be identified with Device ID 27 and Call ID 0.

The following is sample output from the show xlate debug command for these CTIBQE connections:
hostname# show xlate debug
3 in use, 3 most used
Flags:  D - DNS, d - dump, I - identity, i - inside, n - no random,
        r - portmap, s - static
TCP PAT from inside:10.0.0.99/1117 to outside:172.29.1.99/1025 flags ri idle 0:00:22 
timeout 0:00:30
UDP PAT from inside:10.0.0.99/16908 to outside:172.29.1.99/1028 flags ri idle 0:00:00 
timeout 0:04:10
UDP PAT from inside:10.0.0.99/16909 to outside:172.29.1.99/1029 flags ri idle 0:00:23 
timeout 0:04:10
The show conn state ctiqbe command displays the status of CTIQBE connections. In the output, the media connections allocated by the CTIQBE inspection engine are denoted by a `C' flag. The following is sample output from the show conn state ctiqbe command:
hostname# show conn state ctiqbe
1 in use, 10 most used
hostname# show conn state ctiqbe detail
1 in use, 10 most used
Flags: A - awaiting inside ACK to SYN, a - awaiting outside ACK to SYN,
       B - initial SYN from outside, C - CTIQBE media, D - DNS, d - dump,
       E - outside back connection, F - outside FIN, f - inside FIN,
       G - group, g - MGCP, H - H.323, h - H.225.0, I - inbound data,
       i - incomplete, J - GTP, j - GTP data, k - Skinny media,
       M - SMTP data, m - SIP media, O - outbound data, P - inside back connection,
       q - SQL*Net data, R - outside acknowledged FIN,
       R - UDP RPC, r - inside acknowledged FIN, S - awaiting inside SYN,
       s - awaiting outside SYN, T - SIP, t - SIP transient, U - up
Managing DNS Inspection

This section describes how to manage DNS application inspection. This section includes the following topics:

•How DNS Application Inspection Works

•How DNS Rewrite Works

•Configuring DNS Rewrite

•Configuring DNS Inspection

•Verifying and Monitoring DNS Inspection

How DNS Application Inspection Works

DNS guard tears down the DNS session associated with a DNS query as soon as the DNS reply is forwarded by the security appliance. DNS guard also monitors the message exchange to ensure that the ID of the DNS reply matches the ID of the DNS query.

When DNS inspection is enabled, which it is the default, the security appliance performs the following additional tasks:

•Translates the DNS record based on the configuration completed using the alias, static and nat commands (DNS rewrite). Translation only applies to the A-record in the DNS reply. Therefore, reverse lookups, which request the PTR record, are not affected by DNS rewrite.

Note DNS rewrite is not applicable for PAT because multiple PAT rules are applicable for each A-record and the PAT rule to use is ambiguous.

•Enforces the maximum DNS message length (the default is 512 bytes and the maximum length is 65535 bytes). Reassembly is performed as necessary to verify that the packet length is less than the maximum length configured. The packet is dropped if it exceeds the maximum length.

Note If you enter the inspect dns command without the maximum-length option, DNS packet size is not checked

•Enforces a domain-name length of 255 bytes and a label length of 63 bytes.

•Verifies the integrity of the domain-name referred to by the pointer if compression pointers are encountered in the DNS message.

•Checks to see if a compression pointer loop exists.

A single connection is created for multiple DNS sessions, as long as they are between the same two hosts, and the sessions have the same 5-tuple (source/destination IP address, source/destination port, and protocol). DNS identification is tracked by app_id, and the idle timer for each app_id runs independently.

Because the app_id expires independently, a legitimate DNS response can only pass through the security appliance within a limited period of time and there is no resource build-up. However, if you enter the show conn command, you will see the idle timer of a DNS connection being reset by a new DNS session. This is due to the nature of the shared DNS connection and is by design.

DNS port redirection can be enabled using the static command, as in the following example:
static (inside,outside) udp x.x.x.x 53 10.1.1.1 8053
In this example, the DNS server listens on port 8053 and the security appliance redirects DNS queries on port 53 to port 8053. For this to work with DNS inspection, you must enable DNS inspection on port 8053. For configuration instructions, see the"Configuring DNS Inspection" section.

How DNS Rewrite Works

When DNS inspection is enabled, DNS rewrite provides full support for NAT of DNS messages originating from any interface.

If a client on an inside network requests DNS resolution of an inside address from a DNS server on an outside interface, the DNS A-record is translated correctly. If the DNS inspection engine is disabled, the A-record is not translated.

As long as DNS inspection remains enabled, you can configure DNS rewrite using the alias, static, or nat commands. For details about the configuration required see the "Configuring DNS Rewrite" section.

DNS rewrite performs two functions:

•Translating a public address (the routable or "mapped" address) in a DNS reply to a private address (the "real" address) when the DNS client is on a private interface.

•Translating a private address to a public address when the DNS client is on the public interface.

In Figure 21-2, the DNS server resides on the external (ISP) network The real address of the server (192.168.100.1) has been mapped using the static command to the ISP-assigned address (209.165.200.5). A client on any interface can issue an HTTP request to a server. For configuration instructions for this scenario, see the "Configuring DNS Rewrite" section.

Figure 21-2 Translating the Address in a DNS Reply (DNS Rewrite)

A client on any interface can issue a DNS request using "server.example.com." When the DNS request is sent to the external DNS server, the security appliance translates the non-routable source address in the IP header and forwards the request to the ISP network on its outside interface. When the DNS reply is returned, the security appliance applies address translation not only to the destination address, but also to the embedded IP address of the web server, which is contained in the A-record in the DNS reply. As a result, the web client on the inside network gets the correct address for connecting to the web server on the inside network.

DNS rewrite also works if the client making the DNS request is on a DMZ network and the DNS server is on an inside interface. For an illustration and configuration instructions for this scenario, see the "DNS Rewrite with Three NAT Zones" section.

Configuring DNS Rewrite

You configure DNS rewrite using the alias, static, or nat commands. The alias and static command can be used interchangeably. However, Cisco recommends using the static command for new deployments because it is more precise and unambiguous. Also, DNS rewrite is optional when using the static command.

This section describes how to use the alias and static commands to configure DNS rewrite. It provides configuration procedures for using the static command in a simple scenario and in a more complex scenario. Using the nat command is similar to using the static command except that DNS rewrite is based on dynamic translation instead of a static mapping.

This section includes the following topics:

•Using the Alias Command for DNS Rewrite

•Using the Static Command for DNS Rewrite

•Configuring DNS Rewrite

•DNS Rewrite with Three NAT Zones

•Configuring DNS Rewrite with Three NAT Zones

For detailed syntax and additional functions for the alias, nat, and static command, see the appropriate command page in the Cisco Security Appliance Command Reference.

Using the Alias Command for DNS Rewrite

The alias command causes addresses on an IP network residing on any interface to be translated into addresses on another IP network connected through a different interface. The syntax for this command is as follows:
hostname(config)# alias (inside) mapped-address real-address 
For example:
hostname(config)# alias (inside) 209.165.200.5 192.168.100.10
This command specifies that the real address (192.168.100.10) on any interface except the inside interface will be translated to the mapped address (209.165.200.5) on the inside interface. Note that the location of 192.168.100.10 is not precisely defined.

Note If you use the alias command to configure DNS rewrite, proxy ARP will be performed for the mapped address. To prevent this, disable Proxy ARP by entering the sysopt noproxyarp internal_interface command after entering the alias command.

Using the Static Command for DNS Rewrite

The static command causes addresses on an IP network residing on a specific interface to be translated into addresses on another IP network on a different interface. The syntax for this command is as follows:
hostname(config)# static (inside,outside) mapped-address real-address dns
For example:
hostname(config)# static (inside,outside) 209.165.200.5 192.168.100.10 dns
This command specifies that the address 192.168.100.10 on the inside interface is translated into 209.165.200.5 on the outside interface.

Note Using the nat command is similar to using the static command except that DNS rewrite is based on dynamic translation instead of a static mapping.

Configuring DNS Rewrite

To implement the DNS rewrite scenario shown in Figure 21-2, perform the following steps:

Step 1 Create a static translation for the web server as shown in the following example:
hostname(config)# static (inside,outside) 209.165.200.5 192.168.100.1 netmask 
255.255.255.255 dns
This command creates a static translation between the web server real address of 192.168.100.1 to the global IP address 209.165.200.5.

Step 2 To grant access to anyone on the Internet to the web server on port 80, enter the following commands:
hostname(config)# access-list 101 permit tcp any host 209.165.200.5 eq www
hostname(config)# access-group 101 in interface outside
These commands permit any outside user to access the web server on port 80.

Step 3 Configure DNS Inspection if it has been previously disabled or if you want to change the maximum DNS packet length.

DNS application inspection is enabled by default with a maximum DNS packet length of 512 bytes. For configuration instructions, see the "Limitations and Restrictions" section.

Step 4 On the public DNS server, add an A-record into the example.com zone, for example:
server.example.com. IN A 209.165.200.5 
This DNS A-record binds the name server.example.com to the IP address 209.165.200.5.

DNS Rewrite with Three NAT Zones

Figure 21-3 provides a more complex scenario to illustrate how DNS inspection allows NAT to operate transparently with a DNS server with minimal configuration. For configuration instructions for this scenario, see the "Configuring DNS Rewrite with Three NAT Zones" section.