Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide, 3.2
Applying Application Layer Protocol Inspection
Downloads: This chapterpdf (PDF - 1.47MB) The complete bookPDF (PDF - 16.1MB) | Feedback

Applying Application Layer Protocol Inspection

Table Of Contents

Applying Application Layer Protocol Inspection

Application Inspection Engine Overview

How Inspection Engines Work

Inspection Limitations

NAT, PAT, and Application Inspection

Supported Protocols

Application Engine Defaults

About Application Inspection Configuration

Default Application Inspection

CTIQBE Inspection

CTIQBE Inspection Overview

Limitations and Restrictions

Enabling and Configuring CTIQBE Inspection

Verifying and Monitoring CTIQBE Inspection

CTIQBE Sample Configurations

DCERPC Inspection

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 with Two NAT Zones

DNS Rewrite with Three NAT Zones

Configuring DNS Rewrite with Three NAT Zones

Configuring DNS Inspection

Verifying and Monitoring DNS Inspection

FTP Inspection

FTP Inspection Overview

Using the strict Option

The request-command deny Command

Configuring FTP Inspection

Verifying and Monitoring FTP Inspection

GTP Inspection

GTP Inspection Overview

GTP Maps and Commands

Enabling and Configuring GTP Inspection

Verifying and Monitoring GTP Inspection

GGSN Load Balancing

GTP Sample Configuration

H.323 Inspection

H.323 Inspection Overview

How H.323 Works

Limitations and Restrictions

Topologies Requiring H.225 Configuration

H.225 Map Commands

Enabling and Configuring H.323 Inspection

Configuring H.323 and H.225 Timeout Values

Verifying and Monitoring H.323 Inspection

Monitoring H.225 Sessions

Monitoring H.245 Sessions

Monitoring H.323 RAS Sessions

H.323 GUP Support

H.323 GUP Configuration

H.323 Sample Configuration

HTTP Inspection

HTTP Inspection Overview

Enhanced HTTP Inspection Commands

Enabling and Configuring Advanced HTTP Inspection

ICMP Inspection

ILS Inspection

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

MGCP Sample Configuration

NetBIOS Inspection

PPTP Inspection

RSH Inspection

RTSP Inspection

RTSP Inspection Overview

Using RealPlayer

Restrictions and Limitations

Enabling and Configuring RTSP Inspection

SIP Inspection

SIP Inspection Overview

SIP Instant Messaging

IP Address Privacy

Enabling and Configuring SIP Inspection

Configuring SIP Timeout Values

SIP Inspection Enhancement

Verifying and Monitoring SIP Inspection

SIP Sample Configurations

SIP Inspection Example

SIP IP Address Privacy Example

Skinny (SCCP) Inspection

SCCP Inspection Overview

Supporting Cisco IP Phones

Restrictions and Limitations

Configuring and Enabling SCCP Inspection

Verifying and Monitoring SCCP Inspection

SCCP (Skinny) Sample Configuration

SMTP and Extended SMTP Inspection

SMTP and Extended SMTP Inspection Overview

Configuring and Enabling SMTP and Extended SMTP Application Inspection

SNMP Inspection

SNMP Inspection Overview

Enabling and Configuring SNMP Application Inspection

SQL*Net Inspection

Sun RPC Inspection

Sun RPC Inspection Overview

Enabling and Configuring Sun RPC Inspection

Managing Sun RPC Services

Verifying and Monitoring Sun RPC Inspection

TFTP Inspection

XDMCP Inspection


Applying Application Layer Protocol Inspection


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

Application Inspection Engine Overview

How Inspection Engines Work

Inspection Limitations

NAT, PAT, and Application Inspection

Supported Protocols

Application Engine Defaults

About Application Inspection Configuration

Default Application Inspection

CTIQBE Inspection

DCERPC Inspection

DNS Inspection

FTP Inspection

GTP Inspection

H.323 Inspection

HTTP Inspection

ICMP Inspection

ILS Inspection

MGCP Inspection

NetBIOS Inspection

PPTP Inspection

RSH Inspection

RTSP Inspection

SIP Inspection

Skinny (SCCP) Inspection

SMTP and Extended SMTP Inspection

SNMP Inspection

SQL*Net Inspection

Sun RPC Inspection

TFTP Inspection

XDMCP Inspection

Application Inspection Engine Overview

This section describes how application inspection engines work. The Adaptive Security Algorithm, used by the FWSM for stateful application inspection, ensures the secure use of applications and services. Some applications require special handling by the FWSM 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.

This section includes the following topics:

How Inspection Engines Work

Inspection Limitations

Supported Protocols

How Inspection Engines Work

As illustrated in Figure 20-1, the FWSM 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 20-1 Basic Adaptive Security Algorithm Operations

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

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

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

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

4. The FWSM 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 FWSM forwards the packet to the destination system.

6. The destination system responds to the initial request.

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

Inspection Limitations

Some application inspection engines do not support NAT or PAT because those applications have fixed port assignments that you cannot change. See NAT, PAT, and Application Inspection for information.

When application inspection is enabled on the FWSM for TCP flows (especially for application inspection of protocols like VoIP), the TCP sender segments the TCP packets based on the maximum segment size (MSS) advertised by the TCP receiver. The FWSM reassembles the TCP segments, performs the inspection, and transmits the packets to the TCP receiver based on its interface maximum transmission unit (MTU) and not the MSS advertised by the TCP receiver.

For example, two SIP endpoints (Polycomm video conferencing units) advertise an MSS of 536 bytes. The FWSM proxies this connection and one video unit sends a H.245 setup message that is 761 bytes segmented into three packets. The FWSM reassembles these three segments and transmits them to the endpoint as one single 761 data byte packet instead of honoring the 536 byte MSS and resegmenting the message as appropriate.

To account for this limitation, you must perform the following actions on the FWSM:

Increase the MSS on the TCP receiver.

Lower the MTU on the FWSM interface.

Only if possible, disable the advanced protocol inspection.

When application inspection is enabled for a protocol and another application utilizes the same port as that inspected application protocol, the FWSM can exhibit unpredictable behavior (including packet loss) when inspecting that application protocol. When this situation occurs, you should disable the inspection engine for that application protocol.

NAT, PAT, and Application Inspection

Use of NAT and PAT affects application inspection in the following ways:

Some application inspection engines do not support NAT or PAT because those applications have fixed port assignments that you cannot change. For a summary of which application engines support NAT and PAT, see Table 20-1.

If you configure PAT for traffic that is being inspected, the FWSM performs application inspection on the translated port numbers rather than the real port numbers.

Service policies applying inspection to traffic with translated port numbers should use class-maps that identify traffic using the translated port numbers. For example, if you implement PAT to translate ports 2727 and 2427 to port 1400, you should configure MGCP inspection to match traffic sent to port 1400 rather than the well known ports 2427 and 2727.

Supported Protocols

The FWSM supports the following inspection engines:

CTIQBE—See the "CTIQBE Inspection" section

DCERPC—See the "DCERPC Inspection" section

DNS—See the "DNS Inspection" section

FTP—See the "FTP Inspection" section

GTP—See the "GTP Inspection" section

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

HTTP—See the "HTTP Inspection" section

ICMP—See the inspect icmp and inspect icmp error command pages in the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.

ILS—See the inspect ils command page in the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.

MGCP—See the "MGCP Inspection" section

NetBIOS—See the inspect netbios command page in the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.

PPTP—See the inspect pptp command page in the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.

RSH—See the inspect rsh command page in the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.

RTSP—See the "RTSP Inspection" section

SIP—See the "SIP Inspection" section

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

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

SNMP—See the "SNMP Inspection" section

SQL*Net—See the inspect sqlnet command page in the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.

SunRPC—See the "Sun RPC Inspection" section

TFTP—See the inspect tftp command page in the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.

XDMCP—See the inspect xdmcp command page in the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.

Application Engine Defaults

Table 20-1 summarizes the type of application inspections that is provided for each protocol supported by the FWSM.

Table 20-1 Application Inspection Engines and Their Defaults 

Application
Enabled by Default?
PAT?
NAT (1-1)?
Configure Port?
Default Port
Standards
Comments

CTIQBE

No

Yes

Yes

Yes

TCP/2748

DCERPC

No

Yes

Yes

No

TCP/135

DNS1

Yes

Yes

Yes

No

UDP/53

RFC 1123

Only forward NAT. No PTR records are changed.

Default maximum packet length is 512 bytes.

FTP

Yes

Yes

Yes

Yes

TCP/21

RFC 959

Default FTP inspection does not enforce compliance with RFC standards. To do so, configure the inspect ftp command with the strict keyword.

GTP

No

Yes

Yes

Yes

UDP/3386
UDP/2123

Requires a special license.

H.323

Yes

Yes

Yes

Yes

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

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

By default, both RAS and H.225 inspection are enabled.

HTTP

No

Yes

Yes

Yes

TCP/80

RFC 2616

Beware of MTU limitations when stripping ActiveX and Java.2

ICMP

No

Yes

Yes

No

ICMP ERROR

No

Yes

Yes

No

ILS (LDAP)

No

Yes

Yes

Yes

MGCP

No

Yes

Yes

Yes

2427, 2727

RFC2705bis-05

NetBIOS Datagram Service / UDP

Yes

Yes

Yes

No

UDP/138

NetBIOS Name Service / UDP

Yes

No

No

No

UDP/137

No WINS support.

NetBIOS over IP3

Yes

No

No

No

PPTP

No

Yes

Yes

Yes

1723

RFC2637

RSH

Yes

Yes

Yes

Yes

TCP/514

Berkeley UNIX

RTSP

No

Yes

No

Yes

TCP/554

RFC 2326, RFC 2327, RFC 1889

No handling for HTTP cloaking.

SIP

Yes

Yes

Yes

Yes

TCP/5060 UDP/5060

RFC 2543

SKINNY (SCCP)

Yes

Yes

Yes

Yes

TCP/2000

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

SNMP

Yes

No

No

Yes

UDP/161, 162

RFC 1155, 1157, 1212, 1213, 1215

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

SMTP/ESMTP

Yes

Yes

Yes

Yes

TCP/25

RFC 821, 1123

By default, SMTP inspection is enabled rather than ESMTP inspection.

SQL*Net

Yes

Yes

Yes

Yes

TCP/1521 (v.1)

V.1 and v.2.

Sun RPC

Yes

No

Yes

No

UDP/111 TCP/111

Payload not NATed.

TFTP

Yes

Yes

Yes

Yes

TCP/69 UDP/69

RFC 1530

XDCMP

Yes

No

No

No

UDP/177

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

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

3 NetBIOS is supported by performing NAT of the packets for NetBIOS Name Service UDP port 137 and NetBIOS Datagram Service UDP port 138.


About Application Inspection Configuration

You use Modular Policy Framework commands to configure application inspection engines. Before configuring application inspection, read Chapter 17 "Using Modular Policy Framework," which introduces Modular Policy Framework concepts and common commands that you must rely on to configure application inspection.

Enabling and applying an application inspection engine always consists of the following:

A class map that identifies the traffic that the FWSM submits to the inspection engine.

A policy map that links the class map (and thus the relevant traffic) to the inspection engine.

A service policy that applies the policy map to one interface or to all interfaces.

Chapter 17 "Using Modular Policy Framework," provides more overview information about these three elements of configuring Modular Policy Framework. For the inspection engines discussed in this chapter, we provide a detailed configuration procedure and a simple example configuration. For inspection engines not discussed in this chapter, see the applicable inspect command entry in the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.

Application inspection maps are an exception, though. They are unique to application inspection configuration. Application inspection maps let you create a named set of inspection parameters for a particular inspection engine. When you configure a policy map for an application inspection engine that supports an inspection map, you can specify the inspection map by name.

The inspection engines for the following protocols support application maps:

DCERPC—For more information, see the "DCERPC Inspection" section.

FTP—For more information, see the "The request-command deny Command" section.

GTP—For more information, see the "GTP Maps and Commands" section.

HTTP—For more information, see the "Enhanced HTTP Inspection Commands" section.

MGCP—For more information, see the "Configuring MGCP Call Agents and Gateways" section.

SIP—For more information, see the "IP Address Privacy" section.

SNMP—For more information, see the "SNMP Inspection Overview" section.

Default Application Inspection

Application inspection is enabled by default for many but not all protocols. Table 20-1 includes information about which application inspection engines are enabled by default; however, you can determine the inspection engines enabled by default by examining the default policy configuration, which follows:

class-map inspection_default
 match default-inspection-traffic
policy-map global_policy
 class inspection_default
  inspect dns maximum-length 512
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect rsh
  inspect smtp
  inspect sqlnet
  inspect skinny
  inspect sunrpc
  inspect xdmcp
  inspect sip
  inspect netbios
  inspect tftp
service-policy global_policy global
 
   

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 Sample Configurations

CTIQBE Inspection Overview

The inspect ctiqbe 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 FWSM.

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 FWSM, 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 FWSM, 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 Create a class map or modify an existing class map to identify CTIQBE traffic. Use the class-map command to do so, as follows:

hostname(config)# class-map class_map_name
hostname(config-cmap)#
 
   

where class_map_name is the name of the traffic class. When you enter the class-map command, the CLI enters class map configuration mode.

Step 2 Use the match port command to identify CTIQBE traffic, as follows:

hostname(config-cmap)# match port tcp eq 2748
 
   

Step 3 Create a policy map or modify an existing policy map that you want to use to apply the CTIQBE inspection engine to FTP traffic. To do so, use the policy-map command, as follows:

hostname(config-cmap)# policy-map policy_map_name
hostname(config-pmap)# 
 
   

where policy_map_name is the name of the policy map. The CLI enters the policy map configuration mode and the prompt changes accordingly.

Step 4 Specify the class map, created in Step 1, that identifies the CTIQBE traffic. Use the class command to do so, as follows:

hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)# 
 
   

where class_map_name is the name of the class map you created in Step 1. The CLI enters the policy map class configuration mode and the prompt changes accordingly.

Step 5 Enable CTIQBE application inspection.

hostname(config-pmap-c)# inspect ctiqbe
 
   

Step 6 Use the service-policy command to apply the policy map globally or to a specific interface, as follows:

hostname(config-pmap-c)# service-policy policy_map_name [global | interface interface_ID]
hostname(config)#
 
   

where policy_map_name is the policy map you configured in Step 3. If you want to apply the policy map to traffic on all the interfaces, use the global option. If you want to apply the policy map to traffic on a specific interface, use the interface interface_ID option, where interface_ID is the name assigned to the interface with the nameif command.

The FWSM begins inspecting CTIQBE traffic, as specified.


Example 20-1 Enabling and Configuring CTIQBE Inspection

The following example creates a class map to match CTIQBE traffic on the default port (2748) and enables CTIQBE inspection in the policy using the class matching CTIQBE traffic. 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)# policy-map sample_policy 
hostname(config-pmap)# class ctiqbe_port
hostname(config-pmap-c)# inspect ctiqbe
hostname(config-pmap-c)# service-policy sample_policy interface outside
hostname(config)#
 
   

Verifying and Monitoring CTIQBE Inspection

The show ctiqbe command displays information regarding the CTIQBE sessions established across the FWSM. 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 FWSM. 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 FWSM 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
 
   

CTIQBE Sample Configurations

The following is a sample configuration for a single transparent firewall for Softphone:

Figure 20-2 Single Transparent Firewall for Softphone (Virtual Conference)

See the following configuration for this example:

firewall transparent
!
interface Vlan50
nameif inside
bridge-group 1
security-level 100
!
interface Vlan100
nameif outside
bridge-group 1
security-level 0
!
interface BVI1
ip address 100.0.0.30 255.0.0.0
!
access-list voice extended permit tcp any any eq ctiqbe
access-list voice extended permit tcp any any eq 1503
!
access-group voice in interface inside
access-group voice in interface outside
!
policy-map global_policy
class inspection_default
inspect ctiqbe
!
 
   

Note TCP port 1503 must be allowed to pass through the security appliance for virtual conference room collaboration to work with Softphone through the security appliance.


The following is a sample configuration for a single transparent firewall for Softphone with NetMeeting enabled. Softphone is configured with the collaboration setting of NetMeeting.

Figure 20-3 Single Transparent Firewall for Softphone (Virtual Conference) with NetMeeting

See the following configuration for this example:

firewall transparent
!
interface Vlan50
nameif inside
bridge-group 1
security-level 100
!
interface Vlan100
nameif outside
bridge-group 1
security-level 0
!
interface BVI1
ip address 100.0.0.30 255.0.0.0
!
access-list voice extended permit tcp any any eq ctiqbe
access-list voice extended permit tcp any any eq h323
access-list voice extended permit tcp any any eq 1503
!
access-group voice in interface inside
access-group voice in interface outside
!
policy-map global_policy
class inspection_default

inspect ctiqbe

!


Note To allow successful collaboration and application sharing, TCP ports 1503 and 1720 must be allowed to pass through.


The following is sample output for this configuration using the show conn detail command:

hostname# show conn detail
25 in use, 33 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 SUNRPC, r - inside acknowledged FIN, S - awaiting inside SYN,
		s - awaiting outside SYN, T - SIP, t - SIP transient, U - up
Network Processor 1 connection
TCP out 100.0.0.101:2748 in 100.0.0.23:3598 idle 0:00:09 Bytes 103065 FLAGS - UOI
UDP out 100.0.0.21:30504 in 100.0.0.23:3650 idle 0:00:00 Bytes 4810406 
 FLAGS - C
UDP out 100.0.0.21:1436 in 100.0.0.23:19972 idle 0:00:00 Bytes 4813240 
 FLAGS - C
TCP out 100.0.0.21:1437 in 100.0.0.23:1720 idle 0:07:04 Bytes 1027 FLAGS - UBOIh
UDP out 100.0.0.21:49608 in 100.0.0.23:49608 idle 0:00:10 Bytes 241836 
 FLAGS - H
UDP out 100.0.0.21:49609 in 100.0.0.23:49609 idle 0:00:01 Bytes 17480 
 FLAGS - H
TCP out 100.0.0.21:1440 in 100.0.0.23:1503 idle 0:06:58 Bytes 4488 FLAGS - UBOI
TCP out 100.0.0.21:1441 in 100.0.0.23:1503 idle 0:04:50 Bytes 17888 FLAGS - UBOI
TCP out 100.0.0.21:1442 in 100.0.0.23:1503 idle 0:04:50 Bytes 471135 FLAGS - UBOI
 Network Processor 2 connections 
Multicast sessions:
 Network Processor 1 connections 
 Network Processor 2 connections 
IPv6 connections:
 
   

DCERPC Inspection

DCERPC is a protocol widely used by Microsoft distributed client and server applications that allows software clients to execute programs on a server remotely.

This typically involves a client querying a server called the Endpoint Mapper listening on a well known port number for the dynamically allocated network information of a required service. The client then sets up a secondary connection to the server instance providing the service. The security appliance allows the appropriate port number and network address and also applies NAT, if needed, for the secondary connection.

DCERPC inspect maps inspect for native TCP communication between the EPM and client on well known TCP port 135. Map and lookup operations of the EPM are supported for clients. Client and server can be located in any security zone. The embedded server IP address and Port number are received from the applicable EPM response messages. Since a client may attempt multiple connections to the server port returned by EPM, multiple use of pinholes are allowed, which have user configurable timeouts.

DCERPC application inspection supports using an application inspection map. Application inspection maps let you create a named set of inspection parameters for a particular inspection engine. When you configure a policy map for an application inspection engine that supports an inspection map, you can specify the inspection map by name.

For information about configuring DCERPC application inspection by using an application inspection map, see the inspect dcerpc command and the dcerpc-map command in the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.

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

The FWSM tears down the DNS session associated with a DNS query as soon as the DNS reply is forwarded by the FWSM. The FWSM 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 is the default, the FWSM 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, DNS Rewrite does not affect reverse lookups, which request the PTR record.


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). The FWSM performs reassembly as needed to verify that the packet length is less than the maximum length configured. The FWSM drops the packet if it exceeds the maximum length.


Note If you enter the inspect dns command without the maximum-length option, the 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 FWSM 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.

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 20-4, the DNS server resides on the external (ISP) network. On the FWSM, a static command maps the real address of the web server (192.168.100.1) to the ISP-assigned address (209.165.200.5). When a web client on the inside interface attempts to access the web server with the URL http://server.example.com, the host running the web client sends a DNS request to the DNS server to resolve the IP address of the web server. The FWSM 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 FWSM 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. For the exact NAT and DNS configuration for this example, see Example 20-2. For configuration instructions for scenarios similar to this one, see the "Configuring DNS Rewrite with Two NAT Zones" section.

Figure 20-4 DNS Rewrite with Two NAT Zones

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, we recommend 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 with Two NAT Zones

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 Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.

Using the Alias Command for DNS Rewrite

The alias command causes the FWSM to translate addresses on an IP network residing on any interface 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
 
   

The following example 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.225) on the inside interface. Notice that the location of 192.168.100.10 is not precisely defined.

hostname(config)# alias (inside) 209.165.200.225 192.168.100.10
 
   

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
 
   

The following example specifies that the address 192.168.100.10 on the inside interface is translated into 209.165.200.5 on the outside interface:

hostname(config)# static (inside,outside) 209.165.200.225 192.168.100.10 dns
 
   

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 with Two NAT Zones

To implement a DNS Rewrite scenario similar to the one shown in Figure 20-4, perform the following steps:


Step 1 Create a static translation for the web server, as follows:

hostname(config)# static (inside,outside) mapped-address real-address netmask 
255.255.255.255 dns
 
   

where the arguments are as follows:

inside—The name of the inside interface of the FWSM.

outside—The name of the outside interface of the FWSM.

mapped-address—The translated IP address of the web server.

real-address—The real IP address of the web server.

Step 2 Create an access list that permits traffic to the port that the web server listens to for HTTP requests.

hostname(config)# access-list acl-name permit tcp any host mapped-address eq port
 
   

where the arguments are as follows:

acl-name—The name you give the access-list.

mapped-address—The translated IP address of the web server.

port—The TCP port that the web server listens to for HTTP requests.

Step 3 Apply the access list created in Step 2 to the outside interface. To do so, use the access-group command, as follows:

hostname(config)# access-group acl-name in interface outside
 
   

Step 4 If DNS inspection is disabled or if you want to change the maximum DNS packet length, configure DNS inspection. DNS application inspection is enabled by default with a maximum DNS packet length of 512 bytes. For configuration instructions, see the "Configuring DNS Inspection" section.

Step 5 On the public DNS server, add an A-record for the web server, such as:

domain-qualified-hostname. IN A mapped-address
 
   

where domain-qualified-hostname is the hostname with a domain suffix, as in server.example.com. The period after the hostname is important. mapped-address is the translated IP address of the web server.


The following example configures the FWSM for the scenario shown in Figure 20-4. It assumes DNS inspection is already enabled.

Example 20-2 DNS Rewrite with Two NAT Zones

hostname(config)# static (inside,outside) 209.165.200.225 192.168.100.1 netmask 
255.255.255.255 dns
hostname(config)# access-list 101 permit tcp any host 209.165.200.225 eq www
hostname(config)# access-group 101 in interface outside
 
   

This configuration requires the following A-record on the DNS server:

server.example.com. IN A 209.165.200.225
 
   

DNS Rewrite with Three NAT Zones

Figure 20-5 illustrates a more complex scenario: how DNS inspection allows NAT to operate transparently with a DNS server with minimal configuration. For configuration instructions for scenarios like this one, see the "Configuring DNS Rewrite with Three NAT Zones" section.

Figure 20-5 DNS Rewrite with Three NAT Zones

In Figure 20-5, a web server, server.example.com, has the real address 192.168.100.10 on the DMZ interface of the FWSM. A web client with the IP address 10.10.10.25 is on the inside interface and a public DNS server is on the outside interface. The site NAT policies are as follows:

The outside DNS server holds the authoritative address record for server.example.com.

Hosts on the outside network can contact the web server with the domain name server.example.com through the outside DNS server or with the IP address 209.165.200.225.

Clients on the inside network can access the web server with the domain name server.example.com through the outside DNS server or with the IP address 192.168.100.10.

When a host or client on any interface accesses the DMZ web server, it queries the public DNS server for the A-record of server.example.com. The DNS server returns the A-record showing that server.example.com binds to address 209.165.200.225.

When a web client on the outside network attempts to access http://server.example.com, the sequence of events is as follows:

1. The host running the web client sends the DNS server a request for the IP address of server.example.com.

2. The DNS server responds with the IP address 209.165.200.225 in the reply.

3. The web client sends its HTTP request to 209.165.200.225.

4. The packet from the outside host reaches the FWSM at the outside interface.

5. The static rule translates the address 209.165.200.225 to 192.168.100.10 and the FWSM directs the packet to the web server on the DMZ.

When a web client on the inside network attempts to access http://server.example.com, the sequence of events is as follows:

1. The host running the web client sends the DNS server a request for the IP address of server.example.com.

2. The DNS server responds with the IP address 209.165.200.225 in the reply.

3. The FWSM receives the DNS reply and submits it to the DNS application inspection engine.

4. The DNS application inspection engine does the following:

a. Searches for any NAT rule to undo the translation of the embedded A-record address "[outside]:209.165.200.5". In this example, it finds the following static configuration:

static (dmz,outside) 209.165.200.225 192.168.100.10 dns
 
   

b. Uses the static rule to rewrite the A-record as follows because the dns option is included:

[outside]:209.165.200.225 --> [dmz]:192.168.100.10
 
   

Note If the dns option were not included with the static command, DNS Rewrite would not be performed and other processing for the packet continues.


c. Searches for any NAT to translate the web server address, [dmz]:192.168.100.10, when communicating with the inside web client.

No NAT rule is applicable, so application inspection completes.

If a NAT rule (nat or static) were applicable, the dns option must also be specified. If the dns option were not specified, the A-record rewrite in step b would be reverted and other processing for the packet continues.

5. The FWSM sends the HTTP request to server.example.com on the DMZ interface.

Configuring DNS Rewrite with Three NAT Zones

To enable the NAT policies for the scenario in Figure 20-5, perform the following steps:


Step 1 Create a static translation for the web server on the DMZ network, as follows:

hostname(config)# static (dmz,outside) mapped-address real-address dns
 
   

where the arguments are as follows:

dmz—The name of the DMZ interface of the FWSM.

outside—The name of the outside interface of the FWSM.

mapped-address—The translated IP address of the web server.

real-address—The real IP address of the web server.

Step 2 Create an access list that permits traffic to the port that the web server listens to for HTTP requests.

hostname(config)# access-list acl-name permit tcp any host mapped-address eq port
 
   

where the arguments are as follows:

acl-name—The name you give the access-list.

mapped-address—The translated IP address of the web server.

port—The TCP port that the web server listens to for HTTP requests.

Step 3 Apply the access list created in Step 2 to the outside interface. To do so, use the access-group command, as follows:

hostname(config)# access-group acl-name in interface outside
 
   

Step 4 If DNS inspection is disabled or if you want to change the maximum DNS packet length, configure DNS inspection. DNS application inspection is enabled by default with a maximum DNS packet length of 512 bytes. For configuration instructions, see the "Configuring DNS Inspection" section.

Step 5 On the public DNS server, add an A-record for the web server, such as:

domain-qualified-hostname. IN A mapped-address
 
   

where domain-qualified-hostname is the hostname with a domain suffix, as in server.example.com. The period after the hostname is important. mapped-address is the translated IP address of the web server.


The following example configures the FWSM for the scenario shown in Figure 20-5. It assumes DNS inspection is already enabled.

Example 20-3 DNS Rewrite with Three NAT Zones

hostname(config)# static (dmz,outside) 209.165.200.225 192.168.100.10 dns 
hostname(config)# access-list 101 permit tcp any host 209.165.200.225 eq www
hostname(config)# access-group 101 in interface outside
 
   

This configuration requires the following A-record on the DNS server:

server.example.com. IN A 209.165.200.225
 
   

Configuring DNS Inspection

DNS inspection is enabled by default.

To enable DNS inspection (if it has been previously disabled) or to change the default port used for receiving DNS traffic, perform the following steps:


Step 1 Create a class map or modify an existing class map to identify DNS traffic. Use the class-map command to do so, as follows:

hostname(config)# class-map class_map_name
hostname(config-cmap)#
 
   

where class_map_name is the name of the traffic class. When you enter the class-map command, the CLI enters class map configuration mode.

Step 2 Use the match port command to identify DNS traffic. The default port for DNS is UDP port 53.

hostname(config-cmap)# match port udp eq 53
 
   

Step 3 Create a policy map or modify an existing policy map that you want to use to apply the DNS inspection engine to FTP traffic. To do so, use the policy-map command, as follows:

hostname(config-cmap)# policy-map policy_map_name
hostname(config-pmap)# 
 
   

where policy_map_name is the name of the policy map. The CLI enters the policy map configuration mode and the prompt changes accordingly.

Step 4 Enable DNS application inspection. To do so, use the inspect dns command, as follows:

hostname(config-pmap-c)# inspect dns [maximum-length max-pkt-length]
 
   

To change the maximum DNS packet length from the default (512), use the maximum-length argument and replace max-pkt-length with a numeric value. Longer packets are dropped. To disable checking the DNS packet length, enter the inspect dns command without the maximum-length keyword.

Step 5 Use the service-policy command to apply the policy map globally or to a specific interface, as follows:

hostname(config-pmap-c)# service-policy policy_map_name [global | interface interface_ID]
hostname(config)#
 
   

where policy_map_name is the policy map you configured in Step 3. If you want to apply the policy map to traffic on all the interfaces, use the global option. If you want to apply the policy map to traffic on a specific interface, use the interface interface_ID option, where interface_ID is the name assigned to the interface with the nameif command.

The FWSM begins inspecting DNS traffic, as specified.


Example 20-4 Enabling and Configuring DNS Inspection

The following example creates a class map to match DNS traffic on the default port (53), and enables DNS inspection in the sample_policy policy map, and applies DNS inspection to the outside interface.

hostname(config)# class-map dns_port
hostname(config-cmap)# match port udp eq 53
hostname(config-cmap)# policy-map sample_policy 
hostname(config-pmap)# class dns_port
hostname(config-pmap-c)# inspect dns maximum-length 1500
hostname(config-pmap-c)# service-policy sample_policy interface outside
 
   

Verifying and Monitoring DNS Inspection

To view information about the current DNS connections, enter the following command:

hostname# show conn
 
   

For connections using a DNS server, the source port of the connection may be replaced by the IP address of DNS server in the show conn command output.

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 FWSM within a limited period of time and there is no resource build-up. However, when you enter the show conn command, you 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.

To display the statistics for DNS application inspection, enter the show service-policy command. The following is sample output from the show service-policy command:

hostname# show service-policy
Interface outside:
  Service-policy: sample_policy
    Class-map: dns_port
      Inspect: dns maximum-length 1500, packet 0, drop 0, reset-drop 0
 
   

FTP Inspection

This section describes how the FTP inspection engine works and how you can change its configuration. This section includes the following topics:

FTP Inspection Overview

Using the strict Option

The request-command deny Command

Configuring FTP Inspection

Verifying and Monitoring FTP Inspection

FTP Inspection Overview

The FTP application inspection inspects the FTP sessions and performs four tasks:

Prepares dynamic secondary data connection

Tracks ftp command-response sequence

Generates an audit trail

NATs embedded IP address

FTP application inspection prepares secondary channels for FTP data transfer. Ports for these channels are negotiated through PORT or PASV commands. The channels are allocated in response to a file upload, a file download, or a directory listing event.


Note If you disable FTP inspection engines with the no inspect ftp command, outbound users can start connections only in passive mode, and all inbound FTP is disabled.


Using the strict Option

Using the strict option with the inspect ftp command increases the security of protected networks by preventing web browsers from sending embedded commands in FTP requests.


Tip To specify FTP commands that are not permitted to pass through the FWSM, create an FTP map and enter the request-command deny command in FTP map configuration mode.


After you enable the strict option on an interface, FTP inspection enforces the following behavior:

An FTP command must be acknowledged before the FWSM allows a new command.

The FWSM drops connections that send embedded commands.

The 227 and PORT commands are checked to ensure they do not appear in an error string.


Caution Using the strict option may cause the failure of FTP clients that are not strictly compliant with FTP RFCs.

If the strict option is enabled, each ftp command and response sequence is tracked for the following anomalous activity:

Truncated command—Number of commas in the PORT and PASV reply command is checked to see if it is five. If it is not five, then the PORT command is assumed to be truncated and the TCP connection is closed.

Incorrect command—Checks the ftp command to see if it ends with <CR><LF> characters, as required by the RFC. If it does not, the connection is closed.

Size of RETR and STOR commands—These are checked against a fixed constant. If the size is greater, then an error message is logged and the connection is closed.

Command spoofing—The PORT command should always be sent from the client. The TCP connection is denied if a PORT command is sent from the server.

Reply spoofing—PASV reply command (227) should always be sent from the server. The TCP connection is denied if a PASV reply command is sent from the client. This prevents the security hole when the user executes "227 xxxxx a1, a2, a3, a4, p1, p2."

TCP stream editing—The FWSM closes the connection if it detects TCP stream editing.

Invalid port negotiation—The negotiated dynamic port value is checked to see if it is less than 1024. As port numbers in the range from 1 to 1024 are reserved for well-known connections, if the negotiated port falls in this range, then the TCP connection is freed.

Command pipelining—The number of characters present after the port numbers in the PORT and PASV reply command is cross checked with a constant value of 8. If it is more than 8, then the TCP connection is closed.

The FWSM replaces the FTP server response to the SYST command with a series of Xs to prevent the server from revealing its system type to FTP clients. To override this default behavior, use the no mask-syst-reply command in FTP map configuration mode.

The request-command deny Command

The request-command deny command lets you control which FTP commands the FWSM allows for FTP traffic through the FWSM. This command is available in FTP map configuration mode; therefore, to make use of it, you must create an FTP map and use that map when you enable FTP inspection, per "Configuring FTP Inspection" section.

Table 20-2 lists the FTP commands that you can disallow by using the request-command deny command.

.

Table 20-2 FTP Map request-command deny Options 

request-command deny Option
Purpose

appe

Disallows the command that appends to a file.

cdup

Disallows the command that changes to the parent directory of the current working directory.

dele

Disallows the command that deletes a file on the server.

get

Disallows the client command for retrieving a file from the server.

help

Disallows the command that provides help information.

mkd

Disallows the command that makes a directory on the server.

put

Disallows the client command for sending a file to the server.

rmd

Disallows the command that deletes a directory on the server.

rnfr

Disallows the command that specifies rename-from filename.

rnto

Disallows the command that specifies rename-to filename.

site

Disallows the command that are specific to the server system. Usually used for remote administration.

stou

Disallows the command that stores a file using a unique filename.


Configuring FTP Inspection

FTP application inspection is enabled default, so you only need to perform the procedures in this section if you want to change the default FTP configuration, in any of the following ways:

Enable the strict option.

Identify specific FTP commands that are not permitted to pass through the FWSM.

Change the default port number.

To configure FTP inspection, perform the following steps:


Step 1 Determine the ports to which FTP servers behind your FWSM listen. The default FTP port is TCP port 21; however, alternate ports are often used as a simple means to thwart attacks. To ensure that all FTP traffic is inspected, check your FTP servers for use of ports other than TCP port 21.

Step 2 Create a class map or modify an existing class map to identify FTP traffic. Use the class-map command to do so, as follows:

hostname(config)# class-map class_map_name
hostname(config-cmap)#
 
   

where class_map_name is the name of the traffic class. When you enter the class-map command, the CLI enters class map configuration mode.

Step 3 Identify traffic sent to the FTP ports you determined in Step 1. To do so, use a match port or match access-list command.

If you need to identify two or more non-contiguous ports, create an access list with the access-list extended command, add an ACE to match each port, and then use the match access-list command. The following commands show how to use an access list to identify multiple TCP ports with an access list:

hostname(config)# access-list acl-name any any tcp eq port_number_1
hostname(config)# access-list acl-name any any tcp eq port_number_2
hostname(config)# class-map class_map_name
hostname(config-cmap)# match access-list acl-name
 
   

If you need to identify a single port, use the match port command, as follows:

hostname(config-cmap)# match port tcp port_number
 
   

where port_number is the only TCP port listened to by FTP servers behind the FWSM.

If you need to identify a range of contiguous ports for a single protocol, use match port command with the range keyword, as follows:

hostname(config-cmap)# match port tcp range begin_port_number end_port_number
 
   

where begin_port_number is the lowest port in the range of FTP ports and end_port_number is the highest port.

Step 4 (Optional) If you want FTP inspection to do the following:

Allow FTP servers to reveal their system type to FTP clients.

Limit the allowed FTP commands.

then create and configure an FTP map. To do so, perform the following steps:

a. Create an FTP map that contains the additional parameters of FTP inspection. Use the ftp-map command to do so, as follows:

hostname(config-cmap)# ftp-map map_name
hostname(config-ftp-map)#
 
   

where map_name is the name of the FTP map. The CLI enters FTP map configuration mode.

b. (Optional) If you want to allow FTP servers from revealing their system type to FTP clients in responses to SYST messages, use the no form of the mask-syst-reply command, as follows:

hostname(config-ftp-map)# no mask-syst-reply
hostname(config-ftp-map)# 
 
   

Note By default, when FTP inspection is enabled, responses to SYST messages are masked. If you disable SYST response masking, you can reenable it with the mask-syst-response command.


c. (Optional) If you want to disallow specific FTP commands, use the request-command deny command and specify each FTP command that you want to disallow, as follows:

hostname(config-ftp-map)# request-command deny ftp_command [ftp_command...]
hostname(config-ftp-map)# 
 
   

where ftp_command with one or more FTP commands that you want to restrict. See Table 20-2 for a list of the FTP commands that you can restrict.

Step 5 Create a policy map or modify an existing policy map that you want to use to apply the FTP inspection engine to FTP traffic. To do so, use the policy-map command, as follows:

hostname(config-cmap)# policy-map policy_map_name
hostname(config-pmap)# 
 
   

where policy_map_name is the name of the policy map. The CLI enters the policy map configuration mode and the prompt changes accordingly.

Step 6 Specify the class map, created in Step 2, that identifies the FTP traffic. Use the class command to do so, as follows:

hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)# 
 
   

where class_map_name is the name of the class map you created in Step 2. The CLI enters the policy map class configuration mode and the prompt changes accordingly.

Step 7 Enable FTP application inspection with the options you want. To do so, do one of the following:

If you want to enable strict FTP inspection, use the inspect ftp command with the strict keyword, as follows:

hostname(config-pmap-c)# inspect ftp strict
 
   

If you want to enable strict FTP inspection with an optional FTP map you may have configured in Step 4, use the inspect ftp command with the strict keyword and the FTP map name, as follows:

hostname(config-pmap-c)# inspect ftp strict ftp_map_name
 
   

If you want to revert to default FTP inspection, use the inspect ftp command with no keywords, as follows:

hostname(config-pmap-c)# inspect ftp
 
   

Step 8 Use the service-policy command to apply the policy map globally or to a specific interface, as follows:

hostname(config-pmap-c)# service-policy policy_map_name [global | interface interface_ID]
hostname(config)#
 
   

where policy_map_name is the policy map you configured in Step 5. If you want to apply the policy map to traffic on all the interfaces, use the global option. If you want to apply the policy map to traffic on a specific interface, use the interface interface_ID option, where interface_ID is the name assigned to the interface with the nameif command.

The FWSM begins inspecting FTP traffic, as specified.


The following example shows how to identify FTP traffic, define a FTP map, define a policy, and apply the policy to the outside interface.

Example 20-5 Enabling and Configuring Strict FTP Inspection

hostname(config)# class-map ftp_port 
hostname(config-cmap)# match port tcp eq 21
hostname(config-cmap)# ftp-map sample_map
hostname(config-ftp-map)# request-command deny put stou appe
hostname(config-ftp-map)# policy-map sample_policy 
hostname(config-pmap)# class ftp_port
hostname(config-pmap-c)# inspect ftp strict sample_map 
hostname(config-pmap-c)# service-policy sample_policy interface outside
 
   

Verifying and Monitoring FTP Inspection

FTP application inspection generates the following log messages:

An Audit record 302002 is generated for each file that is retrieved or uploaded.

The FTP command is checked to see if it is RETR or STOR and the retrieve and store commands are logged.

The username is obtained by looking up a table providing the IP address.

The username, source IP address, destination IP address, NAT address, and the file operation are logged.

Audit record 201005 is generated if the secondary dynamic channel preparation failed due to memory shortage.

In conjunction with NAT, the FTP application inspection translates the IP address within the application payload. This is described in detail in RFC 959.

GTP Inspection

This section describes how the GTP inspection engine works and how you can change its configuration. This section includes the following topics:

GTP Inspection Overview

GTP Maps and Commands

Enabling and Configuring GTP Inspection

Verifying and Monitoring GTP Inspection

GGSN Load Balancing

GTP Sample Configuration


Note GTP inspection requires a special license. If you enter GTP-related commands on a FWSM without the required license, the FWSM displays an error message.


GTP Inspection Overview

GPRS provides uninterrupted connectivity for mobile subscribers between GSM networks and corporate networks or the Internet. The GGSN is the interface between the GPRS wireless data network and other networks. The SGSN performs mobility, data session management, and data compression (See Figure 20-6).

Figure 20-6 GPRS Tunneling Protocol

The UMTS is the commercial convergence of fixed-line telephony, mobile, Internet and computer technology. UTRAN is the networking protocol used for implementing wireless networks in this system. GTP allows multi-protocol packets to be tunneled through a UMTS/GPRS backbone between a GGSN, an SGSN and the UTRAN.

GTP does not include any inherent security or encryption of user data, but using GTP with the FWSM helps protect your network against these risks.

The SGSN is logically connected to a GGSN using GTP. GTP allows multiprotocol packets to be tunneled through the GPRS backbone between GSNs. GTP provides a tunnel control and management protocol that allows the SGSN to provide GPRS network access for a mobile station by creating, modifying and deleting tunnels. GTP uses a tunneling mechanism to provide a service for carrying user data packets.


Note When using GTP with failover, if a GTP connection is established and the active unit fails before data is transmitted over the tunnel, the GTP data connection (with a "j" flag set) is not replicated to the standby unit. This occurs because the active unit does not replicate embryonic connections to the standby unit.


The GGSN load balancing feature allows any GSN belonging to a GSN pool to respond to an SGSN request to achieve load balancing on the GGSNs.

GTP Maps and Commands

You can enforce additional inspection parameters on GTP traffic. The gtp-map command lets you specify a set of such parameters. When you enable GTP inspection with the inspect gtp command, you have the option of specifying a GTP map.

If you do not specify a map with the inspect gtp command, the FWSM uses the default GTP map, which is preconfigured with the following default values:

request-queue 200

timeout gsn 0:30:00

timeout pdp-context 0:30:00

timeout request 0:01:00

timeout signaling 0:30:00

timeout tunnel 0:01:00

tunnel-limit 500

Table 20-3 summarizes the commands that you use to configure GTP inspection parameters. These commands are available in GTP map configuration mode. For the detailed syntax of each command, see the applicable command page in the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.

Table 20-3 GTP Map Configuration Commands

Command
Description

description

Specifies the GTP configuration map description.

drop

Specifies the message ID, APN, or GTP version to drop.

mcc

Specifies the three-digit Mobile Country Code (000 - 999). One-digit or two-digit entries will be prefixes with 0s.

message-length

Specifies the message length min and max.

permit errors

Permits packets with errors or different GTP versions.

permit response

Specifies an object group allowed to receive responses from another object group.

request-queue

Specifies the maximum requests allowed in the queue.

timeout (gtp-map)

Specifies the idle timeout for the GSN, PDP context, requests, signaling connections, and tunnels.

tunnel-limit

Specifies the maximum number of tunnels allowed.


Enabling and Configuring GTP Inspection

GTP application inspection is disabled by default, so you need to complete the procedures described in this section to enable GTP inspection.


Note GTP inspection requires a special license. If you enter GTP-related commands on a FWSM without the required license, the FWSM displays an error message.


To enable or change GTP configuration, perform the following steps:


Step 1 Define an access list with ACEs that identify the ports required for GTP traffic. The standard ports are UDP ports 2123 and 3386. To create the access list, use the access-list extended command once for each ACE, as follows:

hostname(config)# access-list acl-name permit {udp | tcp} any any eq port
 
   

where acl-name is the name you assign to the access list and port is the GTP port that the ACE identifies.

Step 2 Create a class map or modify an existing class map to identify GTP traffic. Use the class-map command to do so, as follows:

hostname(config)# class-map class_map_name
hostname(config-cmap)#
 
   

where class_map_name is the name of the traffic class. When you enter the class-map command, the CLI enters class map configuration mode.

Step 3 Use a match access-list command to identify GTP traffic with the access list you created in Step 1.

hostname(config-cmap)# match access-list acl-name
 
   

Step 4 (Optional) If you want to enforce additional parameters on GTP traffic, create and configure a GTP map. For more information about GTP maps and the default values enforced if you do not specify GTP map, see "GTP Maps and Commands" section. To create and configure a GTP map, perform the following steps:

a. Create a GTP map that will contain the additional parameters of GTP inspection. Use the gtp-map command to do so, as follows:

hostname(config-cmap)# gtp-map map_name
hostname(config-gtp-map)#
 
   

where map_name is the name of the GTP map. The CLI enters GTP map configuration mode.

b. Configure GTP inspection parameters. To do so, use the GTP map configuration mode commands that you want to enforce. For a list of commands, see Table 20-3.

Step 5 Create a policy map or modify an existing policy map that you want to use to apply the GTP inspection engine to GTP traffic. To do so, use the policy-map command, as follows:

hostname(config-cmap)# policy-map policy_map_name
hostname(config-pmap)# 
 
   

where policy_map_name is the name of the policy map. The CLI enters the policy map configuration mode and the prompt changes accordingly.

Step 6 Specify the class map, created in Step 2, that identifies the GTP traffic. Use the class command to do so, as follows:

hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)# 
 
   

where class_map_name is the name of the class map you created in Step 2. The CLI enters the policy map class configuration mode and the prompt changes accordingly.

 
   

Step 7 Enable GTP application inspection. To do so, use the inspect gtp command, as follows:

hostname(config-pmap-c)# inspect gtp [map_name]
hostname(config-pmap-c)#
 
   

where map_name is the GTP map that you may have created in optional Step 4.

Step 8 Use the service-policy command to apply the policy map globally or to a specific interface, as follows:

hostname(config-pmap-c)# service-policy policy_map_name [global | interface interface_ID]
hostname(config)#
 
   

where policy_map_name is the policy map you configured in Step 5. If you want to apply the policy map to traffic on all the interfaces, use the global option. If you want to apply the policy map to traffic on a specific interface, use the interface interface_ID option, where interface_ID is the name assigned to the interface with the nameif command.

The FWSM begins inspecting GTP traffic, as specified.


The following example shows how to use access lists to identify GTP traffic, define a GTP map, define a policy, and apply the policy to the outside interface.

Example 20-6 Enabling and Configuring GTP Inspection

hostname(config)# access-list gtp_acl permit udp any any eq 3386
hostname(config)# access-list gtp_acl permit udp any any eq 2123
hostname(config)# class-map gtp-traffic
hostname(config-cmap)# match access-list gtp_acl
hostname(config-cmap)# gtp-map sample_map
hostname(config-gtp-map)# request-queue 300
hostname(config-gtp-map)# permit mcc 111 mnc 222
hostname(config-gtp-map)# message-length min 20 max 300
hostname(config-gtp-map)# drop message 20
hostname(config-gtp-map)# tunnel-limit 10000
hostname(config)# policy-map sample_policy
hostname(config-pmap)# class gtp-traffic
hostname(config-pmap-c)# inspect gtp sample_map
hostname(config)# service-policy sample_policy outside
 
   

Verifying and Monitoring GTP Inspection

To display GTP configuration, enter the show service-policy inspect gtp command in privileged EXEC mode. For the detailed syntax for this command, see the command page in the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.

Use the show service-policy inspect gtp statistics command to show the statistics for GTP inspection. The following is sample output from the show service-policy inspect gtp statistics command:

hostname# show service-policy inspect gtp statistics
GPRS GTP Statistics:
  version_not_support               0     msg_too_short             0
  unknown_msg                       0     unexpected_sig_msg        0
  unexpected_data_msg               0     ie_duplicated             0
  mandatory_ie_missing              0     mandatory_ie_incorrect    0
  optional_ie_incorrect             0     ie_unknown                0
  ie_out_of_order                   0     ie_unexpected             0
  total_forwarded                   0     total_dropped             0
  signalling_msg_dropped            0     data_msg_dropped          0
  signalling_msg_forwarded          0     data_msg_forwarded        0
  total created_pdp                 0     total deleted_pdp         0
  total created_pdpmcb              0     total deleted_pdpmcb      0
  pdp_non_existent                  0
 
   

You can use the vertical bar (|) to filter the display. Type ?| for more display filtering options.

Use the show service-policy inspect gtp pdp-context command to display PDP context-related information. The following is sample output from the show service-policy inspect gtp pdp-context command:

hostname# show service-policy inspect gtp pdp-context detail
1 in use, 1 most used, timeout 0:00:00
 
   
Version TID                  MS Addr        SGSN Addr    Idle      APN
v1      1234567890123425         10.0.1.1        10.0.0.2 0:00:13  gprs.example.com
 
   
    user_name (IMSI): 214365870921435    MS address:         10.5.1.1
    primary pdp: Y                       nsapi: 2
    sgsn_addr_signal:        10.0.0.2    sgsn_addr_data:          10.0.0.2
    ggsn_addr_signal:        10.1.1.1    ggsn_addr_data:          10.1.1.1
    sgsn control teid:     0x000001d1    sgsn data teid:        0x000001d3
    ggsn control teid:     0x6306ffa0    ggsn data teid:        0x6305f9fc
    seq_tpdu_up:                    0    seq_tpdu_down:                 0
    signal_sequence:                0
    upstream_signal_flow:          0     upstream_data_flow:          0
    downstream_signal_flow:        0     downstream_data_flow:        0
    RAupdate_flow:                 0
 
   

The PDP context is identified by the tunnel ID, which is a combination of the values for IMSI and NSAPI. A GTP tunnel is defined by two associated PDP contexts in different GSN nodes and is identified with a Tunnel ID. A GTP tunnel is necessary to forward packets between an external packet data network and a MS user.

You can use the vertical bar (|) to filter the display, as in the following example:

hostname# show service-policy gtp statistics | grep gsn
 
   

GGSN Load Balancing

GGSN load balancing (GSN pooling) allows any GSN the belongs to a GSN pool to respond to an SGSN request to achieve load balancing on the GGSN. To enable support for GNS pooling, use the permit response command.

If the security appliance performs GTP inspection, by default the security appliance drops GTP responses from GSNs that were not specified in the GTP request. This situation occurs when you use load balancing among a pool of GSNs to provide efficiency and scalability of GPRS.

You can enable support for GSN pooling by using the permit response command. This command configures the security appliance to allow responses from any of a designated set of GSNs, regardless of the GSN to which a GTP request was sent. You identify the pool of load-balancing GSNs as a network object. Likewise, you identify the SGSN as a network object. If the GSN responding belongs to the same object group as the GSN that the GTP request was sent to, and if the SGSN is in an object group that the responding GSN is permitted to send a GTP response to, the security appliance permits the response.

To create an object to represent the pool of load-balancing GSNs, perform the following steps:


Step 1 Define a new network object group representing the pool of load-balancing GSNs. To do so, use the object-group command:

hostname(config)# object-group network GSN-pool-name
hostname(config)#
 
   
where GSN-pool-name is the object group name for GGSNs.
 
   

Step 2 Specify the load-balancing GSNs using the network-object command. You can configure one network-object command per GSN using the host keyword. You can also specify a network containing GSNs that perform load balancing.

hostname(config)# network-object host IP-address
hostname(config)#
 
   
where IP-address is the IP address of the host.
 
   

Step 3 Create an object to represent the SGSN that the load-balancing GSNs are permitted to respond to. To do so, use the object-group command:

a. Define an SGSN network object group that sends GTP requests to the GSN pool. To do so, use the object-group command:

hostname(config)# object-group network SGSN-name
hostname(config)#
 
   

where SGSN-name is the SGSN network object group name.

b. Identify the SGSN. To do so, use the network-object command:

hostname(config)# network-object host IP-address
hostname(config)#
 
   

where IP-address is the SGSN.

Step 4 Allow GTP responses, from any GSN in the network object representing the GSN pool, to the network object representing the SGSN. To do so, use the gtp-map and permit responses commands:

hostname(config)# gtp-map map_name
hostname(config-gtp-map)# permit response to-object-group SGSN-name from-object-group 
GSN-pool-name
 
   

where map-name is the name of the gtp map, SGSN-name is the name of the SGSN created in Step 3, and GSN-pool-name is the name of the GSN pool created in Step 1.


The following example shows how to support GSN pooling by defining network objects for the GSN pool and the SGSN. An entire Class C network is defined as the GSN pool in this case, but you can identify multiple individual IP addresses as well. The GTP map is configured to permit responses from the GSN pool to the SGSN.

Example 20-7 Enabling and Configuring GGSN Load Balancing

hostname(config)# object-group network GGSNS
hostname(config-network)# network-object 15.1.1.0 255.255.255.0
hostname(config)# object-group network SGSNS
hostname(config-network)# network-object hjost 11.1.1.1
hostname(config)# gtp-map GTPMAP
hostname(config-gtp-map)# permit response to-object-group SGSNS from-object-group GGSNS
 
   

For additional GGSN load balancing information and configurations, refer to the Cisco GGSN Release 7.0 Configuration Guide and the Cisco MultiProcessor WAN Module User Guide.

GTP Sample Configuration

The following is a sample configuration for GTP inspection:

Figure 20-7 GTP Inspection Setup

Sample configuration of SLB (IOS SLB, MSFC used), GGSN (MWAM module used) and FWSM. SLB and MWAM configuration on supervisor/MSFC:

The MWAM is a Cisco IOS application module that you can install in the Cisco Catalyst 6500 Series switch. Each MWAM contains three processor complexes, with two CPUs each and Each CPU can be used to run an independent IOS image. Several Cisco mobile wireless applications are supported. This sample configuration runs Cisco Gateway GPRS Support (General Packet Radio Service Packet Gateway application).

Please refer the following documentation for installation and configuration of MWAM module on Cisco Catalyst 6500 Series switch.

http://cisco.com/en/US/partner/products/hw/modules/ps5510/products_user_guide_chapter09186a0080551fd8.html

The below configuration explains the config requirements for MWAM module as well as how to configure a gateway GPRS support node (GGSN) to support load balancing functions using the Cisco IOS software Server Load Balancing (SLB) feature.

Please refer the following documentation for configuration of load balancing on GGSNs:

http://cisco.com/en/US/partner/products/ps6706/products_feature_guide_chapter09186a00807873e8.html

As per the diagram, two GGSNs (GGSN1 and GGSN2) are configured on the MWAM module:

firewall multiple-vlan-interfaces
firewall module 4 vlan-group 1
firewall module 10 vlan-group 1
firewall vlan-group 1  3-40,44,84,115,119,172,200-202,400-500,800-900
mwam module 9 port 1 allowed-vlan 1,3-40,44,84,172,200-202,400-500,800-900   
mwam module 9 port 2 allowed-vlan 1,3-40,44,84,172,200-202,400-500,800-900
mwam module 9 port 3 allowed-vlan 1,3-40,44,84,172,200-202,400-500,800-900
ip subnet-zero
!
no ip domain-lookup
ip slb timers gtp gsn 40000
ip slb probe PING ping
!
ip slb serverfarm GGSN-POOL
 nat server
 probe PING
 !
 real 15.1.1.32
  weight 1
  inservice
 !        
 real 15.1.1.33
  weight 1
  inservice
!
ip slb serverfarm TGGSN-POOL
 nat server
 probe PING
 !
 real 15.1.1.34
  faildetect numconns 2
  inservice
 !
 real 15.1.1.35
  faildetect numconns 2
  inservice
!
ip slb vserver GTP-V0
 virtual 5.1.1.29 udp 3386 service gtp
 serverfarm GGSN-POOL
 inservice
!
ip slb vserver GTP-V1
 virtual 5.1.1.29 udp 2123 service gtp
 serverfarm GGSN-POOL
 inservice
!
ip slb vserver TGTP-V0
 virtual 5.1.1.28 udp 3386 service gtp
 serverfarm TGGSN-POOL
 inservice
!
ip slb vserver TGTP-V1
 virtual 5.1.1.28 udp 2123 service gtp
 serverfarm TGGSN-POOL
 inservice
!
ip slb dfp password 7 13061E010803
 agent 8.1.1.2 1111 30 0 10
 agent 8.1.1.3 1111 30 0 10
 agent 8.1.1.4 1111 30 0 10
 agent 8.1.1.5 1111 30 0 10
!
 
   

GGSN1 configuration:

hostname# show run 
Building configuration...
 
   
Current configuration : 1460 bytes
!
! Last configuration change at 21:33:19 UTC Wed Dec 13 2006
! NVRAM config last updated at 01:54:40 UTC Sat Nov 18 2006
!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
service gprs ggsn
!
hostname GGSN2ADCTX
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
!
resource policy
!
ip subnet-zero
ip dfp agent gprs
 port 1111
 password cisco
 inservice
!
ip cef
no ip domain lookup
ip domain name cisco.com
no ip dhcp use vrf connected
!
interface GigabitEthernet0/0
 no ip address
!
interface GigabitEthernet0/0.1
!
interface GigabitEthernet0/0.8
 encapsulation dot1Q 8
 ip address 8.1.1.2 255.255.255.0
 no snmp trap link-status
!
interface Virtual-Template1 
 ip address 15.1.1.32 255.255.255.0
 encapsulation gtp
 gprs access-point-list gtp-test
!
ip local pool localpool1 8.1.1.101 8.1.1.110
ip local pool localpool11 18.3.3.3 18.3.3.255
ip classless
ip route 0.0.0.0 0.0.0.0 8.1.1.1
!
no ip http server
!
gprs access-point-list gtp-test
  access-point 1
   access-point-name sj-gtp.cisco.com
   ip-address-pool local localpool11
   !
control-plane
!
line con 0
line vty 0
 no login
line vty 1 4
 login
line vty 5 15
 login
!
end
          

GGSN3 configuration:

 
   
hostname# show run
Building configuration...
 
   
Current configuration : 1533 bytes
!
! Last configuration change at 21:33:47 UTC Wed Dec 13 2006
! NVRAM config last updated at 01:56:07 UTC Sat Nov 18 2006
!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
service gprs ggsn
!
hostname GGSN3ADCTX
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
!
resource policy
!
ip subnet-zero
ip dfp agent gprs
 port 1111
 password cisco
 inservice
!
ip cef
no ip domain lookup
ip domain name cisco.com
no ip dhcp use vrf connected
!
interface GigabitEthernet0/0
 no ip address
!
interface GigabitEthernet0/0.3
!
interface GigabitEthernet0/0.8
 encapsulation dot1Q 8
 ip address 8.1.1.3 255.255.255.0
 no snmp trap link-status
!
interface Virtual-Template1 
 ip address 15.1.1.33 255.255.255.0
 encapsulation gtp
 gprs access-point-list gtp-test
!
ip local pool localpool2 8.1.1.111 8.1.1.120
ip local pool localpool22 8.4.4.4 8.4.4.254
ip classless
ip route 0.0.0.0 0.0.0.0 8.1.1.1
!
no ip http server
!
gprs maximum-pdp-context-allowed 50000
gprs qos default-response requested
gprs access-point-list gtp-test
  access-point 1
   access-point-name sj-gtp.cisco.com
   ip-address-pool local localpool22
   !      
control-plane
!
line con 0
line vty 0
 no login
line vty 1 4
 login
line vty 5 15
 login
!
!         
end
 
   

FWSM configuration for loadbalancing the GGSNs:

FWSM Version 3.2(0)45 <context>
!
hostname admin
domain-name cisco.com
enable password 9jNfZuG3TC5tCVH0 encrypted
no names
!
interface Vlan172
 nameif mgmt
 security-level 100
 ip address 172.21.64.35 255.255.255.128 standby 172.21.64.36 
!
interface Vlan5
 nameif inside
 security-level 100
 ip address 5.1.1.41 255.255.255.0 standby 5.1.1.40 
!
interface Vlan9
 nameif outside
 security-level 0
 ip address 9.1.1.41 255.255.255.0 standby 9.1.1.40 
!
passwd 2KFQnbNIdI.2KYOU encrypted
same-security-traffic permit inter-interface
object-group network GGSNS ================================configured object group to 
define GGSNs
 network-object host 15.1.1.32
 network-object host 15.1.1.33
object-group network SGSNS =================================configured object group to 
define SGSNs
 network-object host 11.1.1.1
object-group network servers
 network-object 5.1.1.0 255.255.255.0
 network-object host 9.1.1.25
 network-object host 9.1.1.26
 network-object host 9.1.1.27
 network-object host 15.1.1.32
 network-object host 15.1.1.33
object-group network clients
 network-object 9.1.1.0 255.255.255.0
 network-object host 11.1.1.1
access-list gtpacl extended permit udp any any eq 2123 
access-list gtpacl extended permit udp any any eq 3386 
access-list gtpacl extended permit icmp any any 
access-list gtpacl extended permit udp any any 
access-list gtpacl extended permit tcp any any eq www 
access-list gtpacl extended permit tcp any any eq ftp 
access-list gtpacl extended permit tcp any any eq telnet 
access-list gtpacl extended permit tcp any any eq ssh 
access-list 112 extended permit tcp object-group servers object-group clients eq www 
access-list 112 extended permit tcp object-group servers object-group clients eq https 
access-list 112 extended permit tcp object-group servers object-group clients eq ftp 
access-list 112 extended permit tcp object-group servers object-group clients eq telnet 
access-list 112 extended permit udp object-group servers object-group clients eq 3386 
access-list 112 extended permit udp object-group servers object-group clients eq 2123 
access-list 112 extended permit tcp object-group servers object-group clients eq ssh 
!
gtp-map GTPMAP ============================================================configured GTP 
map to include the permit response cli
 permit response to-object-group SGSNS from-object-group GGSNS
 permit errors
!
pager lines 24
logging enable
logging timestamp
logging buffered debugging
mtu mgmt 1500
mtu inside 1500
mtu outside 1500
monitor-interface inside
monitor-interface outside
icmp permit any mgmt
icmp permit any inside
icmp permit any outside
asdm history enable
arp timeout 14400
nat-control
no xlate-bypass
static (outside,inside) 11.1.1.1 11.1.1.1 netmask 255.255.255.255 
static (inside,outside) 15.1.1.31 15.1.1.31 netmask 255.255.255.255 
static (inside,outside) 15.1.1.32 15.1.1.32 netmask 255.255.255.255 
static (inside,outside) 15.1.1.33 15.1.1.33 netmask 255.255.255.255 
access-group OO in interface mgmt
access-group 111 in interface outside per-user-override
route inside 15.1.1.32 255.255.255.255 8.1.1.2 1
route inside 15.1.1.33 255.255.255.255 8.1.1.3 1
route outside 11.1.1.1 255.255.255.255 9.1.1.31 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00
timeout mgcp-pat 0:05:00 sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 
0:02:00
timeout uauth 0:05:00 absolute
username cisco password 3USUcOPFUiMCO4Jk encrypted
no snmp-server location
no snmp-server contact
telnet timeout 5
ssh 171.69.42.198 255.255.255.255 mgmt
ssh timeout 5
!             
class-map inspection_default
 match default-inspection-traffic
!
!
policy-map global_policy
 class inspection_default
  inspect dns maximum-length 512 
  inspect ftp 
  inspect h323 h225 
  inspect h323 ras 
  inspect http 
  inspect netbios 
  inspect rsh 
  inspect rtsp 
  inspect skinny 
  inspect smtp 
  inspect sunrpc 
  inspect tftp 
  inspect xdmcp 
  inspect icmp 
  inspect gtp GTPMAP =========================================attached the GTP map to gtp 
inspection in service policy 
  !
service-policy global_policy global
Cryptochecksum:3b1c3373e908cb9163d9aa1387478fa4
: end
 
   

H.323 Inspection

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

H.323 Inspection Overview

How H.323 Works

Limitations and Restrictions

Enabling and Configuring H.323 Inspection

Topologies Requiring H.225 Configuration

H.225 Map Commands

Enabling and Configuring H.323 Inspection

Configuring H.323 and H.225 Timeout Values

Verifying and Monitoring H.323 Inspection

H.323 GUP Support

H.323 Sample Configuration

H.323 Inspection Overview

H.323 inspection provides support for H.323 compliant applications such as Cisco CallManager and VocalTec Gatekeeper. H.323 is a suite of protocols defined by the International Telecommunication Union for multimedia conferences over LANs. The FWSM supports H.323 through Version 4, including the H.323 v3 feature Multiple Calls on One Call Signaling Channel. The H.323 Gatekeeper Update Protocol inspection is also supported. Because GUP is a Cisco proprietary protocol, H.323-GUP inspection is relevant only in topologies where the Cisco Gatekeeper devices are employed.

With H.323 inspection enabled, the FWSM supports multiple calls on the same call signaling channel, a feature introduced with H.323 Version 3. This feature reduces call setup time and reduces the use of ports on the FWSM.

The two major functions of H.323 inspection are as follows:

NAT the necessary embedded IPv4 addresses in the H.225 and H.245 messages. Because H.323 messages are encoded in PER encoding format, the FWSM uses an ASN.1 decoder to decode the H.323 messages.

Dynamically allocate the negotiated H.245 and RTP/RTCP connections.

How H.323 Works

The H.323 protocols collectively may use up to two TCP connection and four to six UDP connections. FastConnect uses only one TCP connection. RAS uses a single UDP connection for registration, admissions, and status.

An H.323 client may initially establish a TCP connection to an H.323 server using TCP port 1720 to request Q.931 call setup. As part of the call setup process, the H.323 terminal supplies a port number to the client to use for an H.245 TCP connection. In environments where H.323 gatekeeper is in use, the initial packet is transmitted using UDP.

H.323 inspection monitors the Q.931 TCP connection to determine the H.245 port number. If the H.323 terminals are not using FastConnect, the FWSM dynamically allocates the H.245 connection based on the inspection of the H.225 messages.

Within each H.245 message, the H.323 endpoints exchange port numbers that are used for subsequent UDP data streams. H.323 inspection inspects the H.245 messages to identify these ports and dynamically creates connections for the media exchange. RTP uses the negotiated port number, while RTCP uses the next higher port number.

The H.323 control channel handles H.225 and H.245 and H.323 RAS. H.323 inspection uses the following ports.

UDP port 1718—Gate Keeper Discovery

UDP port 1719—RAS

TCP port 1720—Control Port

You must permit traffic for the well-known H.323 port 1720 for the H.225 call signaling; however, the H.245 signaling ports are negotiated between the endpoints in the H.225 signaling. When an H.323 gatekeeper is used, the FWSM opens an H.225 connection based on inspection of the ACF message.

After inspecting the H.225 messages, the FWSM opens the H.245 channel and then inspects traffic sent over the H.245 channel as well. All H.245 messages passing through the FWSM undergo H.245 application inspection, which NATs embedded IP addresses and opens the media channels negotiated in H.245 messages.

The H.323 ITU standard requires that a TPKT header, defining the length of the message, precede the H.225 and H.245, before being passed on to the reliable connection. Because the TPKT header does not necessarily need to be sent in the same TCP packet as H.225 and H.245 messages, the FWSM must remember the TPKT length to process and decode the messages properly. For each connection, the FWSM keeps a record that contains the TPKT length for the next expected message.

If the FWSM needs to perform NAT on IP addresses in messages, it changes the checksum, the UUIE length, and the TPKT, if it is included in the TCP packet with the H.225 message. If the TPKT is sent in a separate TCP packet, the FWSM proxy ACKs that TPKT and appends a new TPKT to the H.245 message with the new length.


Note The FWSM does not support TCP options in the Proxy ACK for the TPKT.


Each UDP connection with a packet going through H.323 inspection is marked as an H.323 connection and times out with the H.323 timeout as configured with the timeout command.

Limitations and Restrictions

Some of the known issues and limitations of H.323 application inspection are as follows:

Static PAT may not properly translate IP addresses embedded in optional fields within H.323 messages. If you experience this kind of problem, do not use static PAT with H.323.

When a NetMeeting client registers with an H.323 gatekeeper and tries to call an H.323 gateway that is also registered with the H.323 gatekeeper, the connection is established but no voice is heard in either direction. This problem is unrelated to the FWSM.

If you configure a network static address where the network static address is the same as a third-party netmask and address, then any outbound H.323 connection fails.

Dynamic NAT (PAT) is not supported for H.323-GUP inspection.

Topologies Requiring H.225 Configuration

Some additional H.225 configuration may be required in a topology where call control happens between H.323 endpoints connecting through an FWSM (see Figure 20-8).

Figure 20-8 Topology Requiring H.225 Configuration

In this topology, call signaling occurs between the Cisco CallManager and the HSI on one side of the FWSM and between the HSI and the Cisco CallManager endpoint on the other side. Afterwards, call control happens directly between the Cisco CallManager and the Cisco CallManager endpoint. When the HSI and one endpoint is on a network protected by the FWSM and the other endpoint is on another network, the call control may not go through without additional H.225 configuration.

The FWSM is not aware of the existence of the Cisco CallManager in this topology. With only the packet flows that happen through the security appliance, the FWSM cannot open a proper pinhole to allow such a call to be successful. For this reason, some additional H.225 configuration is required in this scenario.

To provide the necessary configuration, you identify an HSI and its associated endpoints within an HSI group. After this configuration is completed, when the FWSM sees the HSI as one of the communicating hosts in an H.225 connection, it opens H.245 holes between the endpoints in the HSI group. The actual H.245 connection will match one of these pinholes and will go through properly.

H.225 Map Commands

The H.225 map allows the FWSM to open dynamic, port-specific pinholes for an H.245 connection when an HSI is involved in H.225 call-signalling. The H.225 map provides information about the HSI and its associated endpoints, which is required to establish this connection without compromising the security of the network protected by the FWSM.

The h225-map command lets you create an H.225 map. One H225 map can contain a maximum of five HSI groups. Table 20-4 lists the commands available in H.225 map configuration mode.

Table 20-4 H.225 Configuration Commands

Command
Configuration mode
Description

hsi-group

H.225 map configuration mode

Defines an HSI group and enables HSI group configuration mode. Each HSI group can contain a maximum of ten endpoints.

hsi

HSI group configuration mode

Identifies the HSI.

endpoint

HSI group configuration mode

Identifies one or more endpoints within the HSI group.


Enabling and Configuring H.323 Inspection

H.323 inspection is enabled by default.

To enable H.323 inspection, including the optional use of an H.225 map, perform the following steps:


Step 1 Define an access list with ACEs that identify the ports required for H.323 traffic. The standard ports are UDP ports 1718 and 1719 and TCP port 1720. To create the access list, use the access-list extended command once for each ACE, as follows:

hostname(config)# access-list acl-name permit {udp | tcp} any any eq port
 
   

where acl-name is the name you assign to the access list and port is the H.323 port that the ACE identifies.

Step 2 Create a class map or modify an existing class map to identify H.323 traffic. Use the class-map command to do so, as follows:

hostname(config)# class-map class_map_name
hostname(config-cmap)#
 
   

where class_map_name is the name of the traffic class. When you enter the class-map command, the CLI enters class map configuration mode.

Step 3 Use a match access-list command to identify H.323 traffic with the access list you created in Step 1.

hostname(config-cmap)# match access-list acl-name
 
   

Step 4 (Optional) If required by your network topology, configure an H.225 map. For more information about whether your network requires an H.225 map, see the "Topologies Requiring H.225 Configuration" section. To create and configure an H.225 map, perform the following steps:

a. Create an H.225 map.

hostname(config)# h225-map map_name
hostname(config-h225-map)#
 
   

The system enters H.225 map configuration mode and the CLI prompt changes accordingly.

b. Identify an HSI group. To do so, use the hsi-group command, as follows:

hostname(config-h225-map)# hsi-group group_ID
hostname(config-h225-map-hsi-grp)#
 
   

where group_ID is a number, from 0 to 2147483647, that identifies the HSI group.


Note The maximum number of HSI groups allowed per H.225 map is five.


The system enters HSI group configuration mode and the CLI prompt changes accordingly.

c. Define an HSI for the group.

hostname(config-h225-map-hsi-grp)# hsi ip_address
 
   

where ip_address is the addresses of the HSI.

d. Define up to ten endpoints. To do so, use the endpoint command once per endpoint, as follows:

hostname(config-h225-map-hsi-grp)# endpoint ip_address interface
 
   

where interface with the interface on the FWSM that is connected to the endpoint and ip_address is the addresses of the endpoint.

e. If you need to create additional HSI groups, repeat step b. through d.

Step 5 Create a policy map or modify an existing policy map that you want to use to apply the H.323 inspection engine to H.323 traffic. To do so, use the policy-map command, as follows:

hostname(config-cmap)# policy-map policy_map_name
hostname(config-pmap)# 
 
   

where policy_map_name is the name of the policy map. The CLI enters the policy map configuration mode and the prompt changes accordingly.

Step 6 Specify the class map, created in Step 2, that identifies the H.323 traffic. Use the class command to do so, as follows:

hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)# 
 
   

where class_map_name is the name of the class map you created in Step 2. The CLI enters the policy map class configuration mode and the prompt changes accordingly.

 
   

Step 7 Enable H.323 application inspection. To do so, use the inspect h323 command, as follows:

hostname(config-pmap-c)# inspect h323 [h225 map_name]
hostname(config-pmap-c)#
 
   

where map_name is the H.225 map that you may have created in optional Step 4.

Step 8 Use the service-policy command to apply the policy map globally or to a specific interface, as follows:

hostname(config-pmap-c)# service-policy policy_map_name [global | interface interface_ID]
hostname(config)#
 
   

where policy_map_name is the policy map you configured in Step 5. If you want to apply the policy map to traffic on all the interfaces, use the global option. If you want to apply the policy map to traffic on a specific interface, use the interface interface_ID option, where interface_ID is the name assigned to the interface with the nameif command.

The FWSM begins inspecting H.323 traffic, as specified.


Example 20-8 Configuring H.323 Inspection without an H.225 Map

You enable the H.323 inspection engine as shown in the following example, which creates a class map to match H.323 traffic on the default port (1720). The service policy is then applied to the outside interface.

hostname(config)# access-list h323_acl permit udp any any eq 1718
hostname(config)# access-list h323_acl permit udp any any eq 1719
hostname(config)# access-list h323_acl permit tcp any any eq 1720
hostname(config)# class-map h323-traffic 
hostname(config-cmap)# match access-list h323_acl 
hostname(config-cmap)# policy-map sample_policy 
hostname(config-pmap)# class h323_port
hostname(config-pmap-c)# inspect h323 ras
hostname(config-pmap-c)# inspect h323 h225
hostname(config-pmap-c)# service-policy sample_policy interface outside
hostname(config)#
 
   

Example 20-9 includes an H.225 map with two HSI groups, as part of the overall H.323 configuration.

Example 20-9 Configuring H.323 Inspection with an H.225 Map

hostname(config)# access-list h323_acl permit udp any any eq 1718
hostname(config)# access-list h323_acl permit udp any any eq 1719
hostname(config)# access-list h323_acl permit tcp any any eq 1720 
hostname(config)# class-map h323-traffic 
hostname(config-cmap)# match access-list h323_acl 
hostname(config-cmap)# h225-map sample_map
hostname(config-h225-map)# hsi-group 1
hostname(config-h225-map-hsi-grp)# hsi 10.10.15.11 
hostname(config-h225-map-hsi-grp)# endpoint 10.3.6.1 inside
hostname(config-h225-map-hsi-grp)# endpoint 10.10.25.5 outside
hostname(config-h225-map-hsi-grp)# policy-map sample_policy 
hostname(config-pmap)# class h323_port
hostname(config-pmap-c)# inspect h323 ras
hostname(config-pmap-c)# inspect h323 h225 sample_map
hostname(config-pmap-c)# service-policy sample_policy interface outside
hostname(config)# 
 
   

Configuring H.323 and H.225 Timeout Values

To configure the idle time after which an H.225 signalling connection is closed, use the timeout h225 command. The default for H.225 timeout is one hour.

To configure the idle time after which an H.323 control connection is closed, use the timeout h323 command. The default is five minutes.

Verifying and Monitoring H.323 Inspection

This section describes how to display information about H.323 sessions. This section includes the following topics:

Monitoring H.225 Sessions

Monitoring H.245 Sessions

Monitoring H.323 RAS Sessions

Monitoring H.225 Sessions

The show h225 command displays information for H.225 sessions established across the FWSM. Along with the debug h323 h225 event, debug h323 h245 event, and show local-host commands, this command is used for troubleshooting H.323 inspection engine issues.

Before entering the show h225, show h245, or show h323-ras commands, we recommend that you configure the pager command. If there are a lot of session records and the pager command is not configured, it may take a while for the show command output to reach its end. If there is an abnormally large number of connections, check that the sessions are timing out based on the default timeout values or the values set by you. If they are not, then there is a problem that needs to be investigated.

The following is sample output from the show h225 command:

hostname# show h225
Total H.323 Calls: 1
1 Concurrent Call(s) for
    Local:   10.130.56.3/1040   Foreign: 172.30.254.203/1720
    1. CRV 9861
    Local:   10.130.56.3/1040   Foreign: 172.30.254.203/1720
0 Concurrent Call(s) for
    Local:   10.130.56.4/1050   Foreign: 172.30.254.205/1720
 
   

This output indicates that there is currently 1 active H.323 call going through the FWSM between the local endpoint 10.130.56.3 and foreign host 172.30.254.203, and for these particular endpoints, there is 1 concurrent call between them, with a CRV for that call of 9861.

For the local endpoint 10.130.56.4 and foreign host 172.30.254.205, there are 0 concurrent calls. This means that there is no active call between the endpoints even though the H.225 session still exists. This could happen if, at the time of the show h225 command, the call has already ended but the H.225 session has not yet been deleted. Alternately, it could mean that the two endpoints still have a TCP connection opened between them because they set "maintainConnection" to TRUE, so the session is kept open until they set it to FALSE again, or until the session times out based on the H.225 timeout value in your configuration.

Monitoring H.245 Sessions

The show h245 command displays information for H.245 sessions established across the FWSM by endpoints using slow start. Slow start is when the two endpoints of a call open another TCP control channel for H.245. Fast start is where the H.245 messages are exchanged as part of the H.225 messages on the H.225 control channel.) Along with the debug h323 h245 event, debug h323 h225 event, and show local-host commands, this command is used for troubleshooting H.323 inspection engine issues.

The following is sample output from the show h245 command:

hostname# show h245
Total: 1
        LOCAL           TPKT    FOREIGN         TPKT
1       10.130.56.3/1041        0       172.30.254.203/1245    0
        MEDIA: LCN 258 Foreign 172.30.254.203 RTP 49608 RTCP 49609
                      Local   10.130.56.3 RTP 49608 RTCP 49609
        MEDIA: LCN 259 Foreign 172.30.254.203 RTP 49606 RTCP 49607
                      Local   10.130.56.3 RTP 49606 RTCP 49607
 
   

There is currently one H.245 control session active across the FWSM. The local endpoint is 10.130.56.3, and we are expecting the next packet from this endpoint to have a TPKT header because the TPKT value is 0. The TKTP header is a 4-byte header preceding each H.225/H.245 message. It gives the length of the message, including the 4-byte header. The foreign host endpoint is 172.30.254.203, and we are expecting the next packet from this endpoint to have a TPKT header because the TPKT value is 0.

The media negotiated between these endpoints have an LCN of 258 with the foreign RTP IP address/port pair of 172.30.254.203/49608 and an RTCP IP address/port of 172.30.254.203/49609 with a local RTP IP address/port pair of 10.130.56.3/49608 and an RTCP port of 49609.

The second LCN of 259 has a foreign RTP IP address/port pair of 172.30.254.203/49606 and an RTCP IP address/port pair of 172.30.254.203/49607 with a local RTP IP address/port pair of 10.130.56.3/49606 and RTCP port of 49607.

Monitoring H.323 RAS Sessions

The show h323-ras command displays information for H.323 RAS sessions established across the FWSM between a gatekeeper and its H.323 endpoint. Along with the debug h323 ras event and show local-host commands, this command is used for troubleshooting H.323 RAS inspection engine issues.

The show h323-ras command displays connection information for troubleshooting H.323 inspection engine issues. The following is sample output from the show h323-ras command:

hostname# show h323-ras
Total: 1
        GK                      Caller
        172.30.254.214 10.130.56.14
 
   

This output shows that there is one active registration between the gatekeeper 172.30.254.214 and its client 10.130.56.14.

H.323 GUP Support

The H.323-GUP feature is used for creation of the secondary channel for the H.323-GUP connection from the H.323-RAS connection, and for translation (NAT) of the embedded addresses in the GUP messages. It enables Gatekeepers to communicate with each other through the firewall.

You do not need to enable H.323-GUP explicitly. To utilize this feature, enable H.323-RAS inspection with the appropriate access list (allowing UDP port 1719).

Limitations:

H.323-GUP inspection is relevant only in topologies where the Cisco Gatekeeper devices are employed because GUP is a Cisco proprietary protocol.

Dynamic NAT and dynamic PAT are not supported in H.323 GUP inspection.

H.323 GUP Configuration

Figure 20-9 illustrates an H.323 inspection topology configured with H.323 GUP support.

Figure 20-9 Example: H.323 Inspection Configuration with H.323 GUP Support

See the following configuration for this example:

firewall transparent
hostname FWSM
!
interface Vlan50
nameif inside
bridge-group 1
security-level 100
!
interface Vlan100
nameif outside
bridge-group 1
security-level 0
!
interface BVI1
ip address 100.0.0.8 255.255.255.0
!
access-list h323-gup-permit extended permit udp any any eq 1719
access-group h323-gup-permit in interface inside
access-group h323-gup-permit in interface outside
 
   

Note RAS inspection should be turned on for interfaces through which the gatekeeper running GUP protocol is reachable. In this example, RAS inspection is turned on for both inside and outside interfaces.


Outside gatekeeper configuration (GK):

gatekeeper
zone local GK cisco.com 100.0.0.6
zone cluster local gup-cluster GK
element inGK 100.0.0.7 1719
 
   

Inside gatekeeper configuration (inGK):

gatekeeper
zone local inGK cisco.com 100.0.0.7
zone cluster local gup-cluster inGK
element GK 100.0.0.6 1719
 
   

When the H.323 GUP session is established in this configuration, the following is output from the show h323 gup command:

hostname(config)# show h323 gup
 
   
No. 		LOCAL							FOREIGN
1		inside:100.0.0.7/15970				 		 	Outside:100.0.0.6/22754
 
   

The following output from the show conn command shows the secondary channel established between the H.323 Gatekeepers and the H.323 GUP connections marked with the flag n.

hostname(config)# show conn
 
   
3 in use, 37 most used
Network Processor 1 connection
UDP out 100.0.0.6:1719 in 100.0.0.7:1719 idle 0:00:45 Bytes 672
FLAGS - H
TCP out 100.0.0.6:22754 in 100.0.0.7:15970 idle 0:00:04 Bytes 1188 FLAGS - UBIn
Network Processor 2 connections
 
   
Multicast sessions:
Network Processor 1 connection
Network Processor 2 connections
IPv6 connections:
 
   

H.323 Sample Configuration

The following is a sample configuration for H.323 inspection:

Figure 20-10 H.323 Inspection Setup

Configuration of the IOS H.323 Gateway (Router R2) on the outside interface:

hostname(config)#hostname R2
hostname(config)#interface FastEthernet0/1
hostname(config-if)# ip address 100.100.100.1 255.0.0.0
hostname(config-if)#no shut
hostname(config-if)#exit
hostname(config)#ip route 50.0.0.0 255.0.0.0 100.100.100.2
hostname(config)#voice-port 1/0/0
hostname(config-voiceport)#no shut
hostname(config-voiceport)#exit
hostname(config)#gateway
hostname(config-gateway)# 
hostname(config-gateway)#exit
hostname(config)#ip cef
hostname(config)#int f0/1
hostname(config-if)#h323-gateway voip interface
hostname(config-if)#h323-gateway voip id inGK ipaddr 50.0.0.6
hostname(config-if)#h323-gateway voip h323-id R2
 
   

Configure dial peer to forward voice calls to destination number 4085280001 using the H.323 protocol:

hostname(config)#dial-peer voice 101 voip
hostname(config-dial-peer)#destination-pattern 4085280001 
hostname(config-dial-peer)#session target ras
hostname(config-dial-peer)#exit
 
   

Configure dial peer to forward voice calls to 4085280002 to voice port 1/0/0 in router R2:

hostname(config)#dial-peer voice 102 pots
hostname(config-dial-peer)#destination-pattern 4085280002
hostname(config-dial-peer)#port 1/0/0
hostname(config-dial-peer)#exit
hostname(config)#exit
 
   

Configuration of the IOS H.323 gateway (router R1) on the inside interface:

hostname(config)#hostname R1
hostname(config)#interface FastEthernet0/1
hostname(config-if)# ip address 50.100.100.1 255.0.0.0
hostname(config-if)#no shut
hostname(config-if)#ip route 100.0.0.0 255.0.0.0 50.100.100.2
hostname(config)#  
hostname(config)#voice-port 3/0/0
hostname(config-voiceport)#no shut
hostname(config-voiceport)#exit
hostname(config)#gateway
hostname(config-gateway)#exit
hostname(config)#ip cef
hostname(config)#int fastethernet0/1 
hostname(config-if)#h323-gateway voip interface
hostname(config-if)#h323-gateway voip id inGK ipaddr 50.0.0.6
hostname(config-if)#h323-gateway voip h323-id R1
hostname(config-if)#exit
 
   

Forward all voice calls destined to 408528002 using the H.323 protocol:

hostname(config)#dial-peer voice 101 voip
hostname(config-dial-peer)#destination-pattern 4085280002
hostname(config-dial-peer)#session target ras
 
   

Forward all voice calls destined to 4085280001 to voice port 3/0/0:

hostname(config)#dial-peer voice 102 pots
hostname(config-dial-peer)#destination-pattern 4085280001
hostname(config-dial-peer)#port 3/0/0
hostname(config-dial-peer)#^Z
 
   

Configuration of the IOS H.323 Gatekeeper (router inGK) on the inside interface:

 
   
hostname(config)#hostname inGK
hostname(config)#interface FastEthernet0/1
hostname(config-if)# ip address 50.0.0.6 255.0.0.0
hostname(config-if)#no shut
hostname(config-if)#exit
hostname(config)#gatekeeper
hostname(config-gk)#zone local inGK cisco.com 50.0.0.6
hostname(config-gk)#no shut
hostname(config)#
hostname(config)#ip route 100.0.0.0 255.0.0.0 50.100.100.2
 
   

Configuration of the FWSM for H.323 inspection:

 
   
hostname# config t
hostname(config)# interface Vlan100
hostname(config-if)#  nameif outside
hostname(config-if)#  security-level 0
hostname(config-if)#  ip address 100.100.100.2 255.0.0.0 
hostname(config-if)# 
hostname(config-if)# interface Vlan50
hostname(config-if)#  nameif inside
hostname(config-if)#  security-level 100
hostname(config-if)#  ip address 50.100.100.2 255.0.0.0 
hostname(config-if)# 
hostname(config-if)# access-list voice extended permit udp any any eq 1719 
hostname(config)# access-list voice extended permit tcp any any eq h323 
hostname(config)# 
hostname(config)# access-group voice in interface outside
hostname(config)# access-group voice in interface inside
hostname(config)# 
hostname(config)# policy-map global_policy
hostname(config-pmap)#  class inspection_default
hostname(config-pmap-c)# inspect h323 h225 
hostname(config-pmap-c)#   inspect h323 ras 
hostname(config-pmap-c)# 
 
   

Output of show conn shows H.323 media connections and control (connections flagged by h and output of show h225):

FWSM/admin# show conn
4 in use, 7 most used
 Network Processor 1 connections 
UDP out 100.100.100.1:52906 in 50.0.0.6:1719 idle 0:00:07 Bytes 5162 
 FLAGS - H
TCP out 100.100.100.1:1720 in 50.100.100.1:12139 idle 0:00:54 Bytes 1307 FLAGS - UOIh
UDP out 100.100.100.1:19253 in 50.100.100.1:17815 idle 0:00:03 Bytes 13012 
 FLAGS - H
UDP out 100.100.100.1:19252 in 50.100.100.1:17814 idle 0:00:00 Bytes 1370400 
 FLAGS - H
 Network Processor 2 connections 
Multicast sessions:
 Network Processor 1 connections 
 Network Processor 2 connections 
IPv6 connections:
 
   
FWSM/admin# show h225 
Total: 1
1  Concurrent Call(s) for
    Local:   50.100.100.1/12139 Foreign: 100.100.100.1/1720
0  CRV: 2
    Local: 50.100.100.1/12139  TPKT: 211        Foreign: 100.100.100.1/1720  TPKT: 113
 
   

HTTP Inspection

This section describes how the HTTP inspection engine works and how you can change its configuration. This section includes the following topics:

HTTP Inspection Overview

Enhanced HTTP Inspection Commands

Enabling and Configuring Advanced HTTP Inspection

HTTP Inspection Overview

Use the inspect http command to protect your network against HTTP-specific attacks and other threats associated with HTTP. HTTP inspection performs the following functions:

Enhanced HTTP inspection

Java and ActiveX filtering

You configure the second feature in conjunction with the filter command. For more information about filtering, see Chapter 16 "Applying Filtering Services."


Note The no inspect http command also disables the filter url command.


The enhanced HTTP inspection feature, which is also known as an application firewall, can help prevent attackers from using HTTP messages for circumventing network security policy. It verifies the following for all HTTP messages:

Conformance to RFC 2616

Use of RFC-defined methods only.

Compliance with the additional criteria, defined by command in Table 20-5.

When you specify an HTTP map with the inspect http command, you enable enhanced HTTP inspection. The parameters of enhanced HTTP inspection engine are defined by the HTTP map, which you create with the http-map command and configure with the commands available in the HTTP map configuration mode.


Note When you enable HTTP inspection with an HTTP map, strict HTTP inspection with the action reset and log is enabled by default. You can change the actions performed in response to inspection failure, but you cannot disable strict inspection as long as the HTTP map remains enabled.


Enhanced HTTP Inspection Commands

Table 20-5 summarizes the commands that you use to configure enhanced HTTP inspection parameters. These commands are available in HTTP map configuration mode. Each command lets you specify the action taken when a message violates the parameter enforced by the command. These actions include allowing the message, sending a reset message, or dropping the message. In addition to these actions, you can specify to log the event or not.

For the detailed syntax of each command, see the applicable command page in the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.

Table 20-5 HTTP Map Configuration Commands 

Command
Description

content-length

Enables inspection based on the length of the HTTP content.

content-type-verification

Enables inspection based on the type of HTTP content.

max-header-length

Enables inspection based on the length of the HTTP header.

max-uri-length

Enables inspection based on the length of the URI.

port-misuse

Enables application firewall inspection.

request-method

Enables inspection based on the HTTP request method.

strict-http

Enables strict HTTP inspection.

transfer-encoding

Enables inspection based on the transfer encoding type.


Enabling and Configuring Advanced HTTP Inspection

To enable and configure enhanced HTTP inspection, perform the following steps:


Step 1 Determine the ports that HTTP servers behind the FWSM listen to for HTTP traffic. The default port is TCP port 80; however, alternate ports are often used as a simple means to thwart attacks. To ensure that all HTTP traffic is inspected, check your HTTP servers for use of ports other than TCP port 80.

Step 2 Create a class map or modify an existing class map to identify HTTP traffic. Use the class-map command to do so, as follows:

hostname(config)# class-map class_map_name
hostname(config-cmap)#
 
   

where class_map_name is the name of the traffic class. When you enter the class-map command, the CLI enters class map configuration mode.

Step 3 Identify traffic sent to the HTTP ports you determined in Step 1. To do so, use a match port or match access-list command.

If you need to identify two or more non-contiguous ports, create an access list with the access-list extended command, add an ACE to match each port, and then use the match access-list command. The following commands show how to use an access list to identify multiple TCP ports with an access list:

hostname(config)# access-list acl-name any any tcp eq port_number_1
hostname(config)# access-list acl-name any any tcp eq port_number_2
hostname(config)# class-map class_map_name
hostname(config-cmap)# match access-list acl-name
 
   

If you need to identify a single port, use the match port command, as follows:

hostname(config-cmap)# match port tcp port_number
 
   

where port_number is the only TCP port listened to by HTTP servers behind the FWSM.

If you need to identify a range of contiguous ports for a single protocol, use match port command with the range keyword, as follows:

hostname(config-cmap)# match port tcp range begin_port_number end_port_number
 
   

where begin_port_number is the lowest port in the range of HTTP ports and end_port_number is the highest port.

Step 4 (Optional) If you want to enable enhanced HTTP inspection, perform the following steps:

a. Create an HTTP map that will contain the additional parameters of HTTP inspection. Use the http-map command to do so, as follows:

hostname(config-cmap)# http-map map_name
hostname(config-http-map)#
 
   

where map_name is the name of the HTTP map. The CLI enters HTTP map configuration mode.

b. Configure enhanced HTTP inspection parameters. To do so, determine which enhanced HTTP commands you want to use. For a list of commands, see Table 20-5.

Step 5 Create a policy map or modify an existing policy map that you want to use to apply the HTTP inspection engine to HTTP traffic. To do so, use the policy-map command, as follows:

hostname(config-cmap)# policy-map policy_map_name
hostname(config-pmap)# 
 
   

where policy_map_name is the name of the policy map. The CLI enters the policy map configuration mode and the prompt changes accordingly.

Step 6 Specify the class map, created in Step 2, that identifies the HTTP traffic. Use the class command to do so, as follows:

hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)# 
 
   

where class_map_name is the name of the class map you created in Step 2. The CLI enters the policy map class configuration mode and the prompt changes accordingly.

Step 7 Enable HTTP application inspection. To do so, use the inspect http command, as follows:

hostname(config-pmap-c)# inspect http [map_name]
hostname(config-pmap-c)#
 
   

where map_name is the HTTP map that you may have created in optional Step 4.

Step 8 Use the service-policy command to apply the policy map globally or to a specific interface, as follows:

hostname(config-pmap-c)# service-policy policy_map_name [global | interface interface_ID]
hostname(config)#
 
   

where policy_map_name is the policy map you configured in Step 5. If you want to apply the policy map to traffic on all the interfaces, use the global option. If you want to apply the policy map to traffic on a specific interface, use the interface interface_ID option, where interface_ID is the name assigned to the interface with the nameif command.

The FWSM begins inspecting HTTP traffic, as specified.


Example 20-10 Enabling and Configuring Enhanced HTTP Inspection

The following example shows how to use access lists to identify HTTP traffic, define an HTTP map, define a policy, and apply the policy to the outside interface:

hostname(config)# class-map http_port
hostname(config-cmap)# match port tcp eq 80
hostname(config-cmap)# http-map sample_map
hostname(config-http-map)# content-length min 100 max 2000 action reset log
hostname(config-http-map)# content-type-verification match-req-rsp action reset log
hostname(config-http-map)# max-header-length request 100 action reset log
hostname(config-http-map)# max-uri-length 100 action reset log
hostname(config-http-map)# policy-map sample_policy
hostname(config-pmap)# class http_port
hostname(config-pmap-c)# inspect http sample_map
hostname(config-pmap-c)# service-policy sample_policy interface outside
hostname(config)#
 
   

ICMP Inspection

ICMP inspection is disabled by default.

For information about ICMP inspection, see the inspect icmp and inspect icmp error command pages in the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.

ILS Inspection

ILS inspection is disabled by default.

For information about ILS inspection, see the inspect ils command page in the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.

MGCP Inspection

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

MGCP Inspection Overview

Configuring MGCP Call Agents and Gateways

Configuring and Enabling MGCP Inspection

Configuring MGCP Timeout Values

Verifying and Monitoring MGCP Inspection

MGCP Sample Configuration

MGCP Inspection Overview

MGCP is a master/slave protocol used to control media gateways from external call control elements called media gateway controllers or call agents. A media gateway is typically a network element that provides conversion between the audio signals carried on telephone circuits and data packets carried over the Internet or over other packet networks. Using NAT and PAT with MGCP lets you support a large number of devices on an internal network with a limited set of external (global) addresses. Examples of media gateways are as follows:

Trunking gateways that interface between the telephone network and a VoIP network. Such gateways typically manage a large number of digital circuits.

Residential gateways that provide a traditional analog (RJ11) interface to a VoIP network. Examples of residential gateways include cable modem/cable set-top boxes, xDSL devices, broad-band wireless devices.

Business gateways that provide a traditional digital PBX interface or an integrated soft PBX interface to a VoIP network.

MGCP messages are transmitted over UDP. A response is sent back to the source (IP address and UDP port number) of the command, but the response may not arrive from the same address as the command was sent to. This can happen when multiple call agents are being used in a failover configuration and the call agent that received the command has passed control to a backup call agent, which then sends the response. Figure 20-11 illustrates how NAT can be used with MGCP.

Figure 20-11 Using NAT with MGCP

MGCP endpoints are physical or virtual sources and destinations for data. Media gateways contain endpoints on which the call agent can create, modify and delete connections to establish and control media sessions with other multimedia endpoints. Also, the call agent can instruct the endpoints to detect certain events and generate signals. The endpoints automatically communicate changes in service state to the call agent.

MGCP transactions are composed of a command and a mandatory response. There are eight types of commands:

CreateConnection

ModifyConnection

DeleteConnection

NotificationRequest

Notify

AuditEndpoint

AuditConnection

RestartInProgress

The first four commands are sent by the call agent to the gateway. The Notify command is sent by the gateway to the call agent. The gateway may also send a DeleteConnection command. The registration of the MGCP gateway with the call agent is achieved by the RestartInProgress command. The AuditEndpoint and the AuditConnection commands are sent by the call agent to the gateway.

All commands are composed of a Command header, optionally followed by a session description. All responses are composed of a Response header, optionally followed by a session description.

To use MGCP, you usually need to configure inspection for traffic sent to two ports:

The port on which the gateway receives commands from the call agent. Gateways usually listen to UDP port 2427.

The port on which the call agent receives commands from the gateway. Call agents usually listen to UDP port 2727.


Note MGCP inspection does not support the use of different IP addresses for MGCP signaling and RTP data. A common and recommended practice is to send RTP data from a resilient IP address, such as a loopback or virtual IP address; however, the FWSM requires the RTP data to come from the same address as MGCP signalling.


Configuring MGCP Call Agents and Gateways

Use the call-agent command to specify a group of call agents that can manage one or more gateways. The call agent group information is used to open connections for the call agents in the group (other than the one a gateway sends a command to) so that any of the call agents can send the response. Call agents with the same group_id belong to the same group. A call agent may belong to more than one group. The group_id option is a number from 0 to 4294967295. The ip_address option specifies the IP address of the call agent.

To specify a group of call agents, enter the call-agent command in MGCP map configuration mode, which is accessible by entering the mgcp-map command in global configuration mode.


Note Using call agents to control the MGCP gateways does not restrict calls between the gateways. For example, the FWSM does not deny voice calls based on the call agent or gateway IP addresses configured by using the mgcp-map command. The gateways can make voice calls even when they are not configured by using the mgcp-map command.


Use the gateway command to specify which group of call agents are managing a particular gateway. The IP address of the gateway is specified with the ip_address option. The group_id option is a number from 0 to 4294967295 that must correspond with the group_id of the call agents that are managing the gateway. A gateway may only belong to one group.


Note MGCP call agents send AUEP messages to determine if MGCP end points are present. This establishes a flow through the FWSM and allows MGCP end points to register with the call agent.


Configuring and Enabling MGCP Inspection

To enable and configure MGCP application inspection, perform the following steps:


Step 1 Define an access list with ACEs that identify the two ports required for receiving MGCP traffic. The standard ports are UDP ports 2427 and 2727. To create the access list, use the access-list extended command, as follows:

hostname(config)# access-list acl-name permit udp any any eq port-1
hostname(config)# access-list acl-name permit udp any any eq port-2
 
   

where acl-name is the name you assign to the access list, port-1 is the first MGCP port and port-2 is the second MGCP port.

Step 2 Create a class map or modify an existing class map to identify MGCP traffic. Use the class-map command to do so, as follows:

hostname(config)# class-map class_map_name
hostname(config-cmap)#
 
   

where class_map_name is the name of the traffic class. When you enter the class-map command, the CLI enters class map configuration mode.

Step 3 Use a match access-list command to identify MGCP traffic with the access list you created in Step 1.

hostname(config-cmap)# match access-list acl-name
 
   

Step 4 (Optional) If the network has multiple call agents and gateways for which the FWSM has to open pinholes, create an MGCP map. To do so, perform the following steps:

a. Create an MGCP map by using the mgcp-map command. The mgcp-map command lets you create parameters for MGCP inspection. Use the mgcp-map command as follows:

hostname(config-cmap)# mgcp-map map_name
hostname(config-mgcp-map)#
 
   

where map_name is the name of the MGCP map. The system enters MGCP map configuration mode and the CLI prompt changes accordingly.

b. Configure the call agents. To do so, use the call-agent command once per call agent, as follows:

hostname(config-mgcp-map)# call-agent ip_address group_id
 
   

c. Configure the gateways. To do so, use the gateway command once per gateway, as follows:

hostname(config-mgcp-map)# gateway ip_address group_id
 
   

d. (Optional) If you want to change the maximum number of commands allowed in the MGCP command queue, use the command-queue command, as follows:

hostname(config-mgcp-map)# command-queue command_limit
 
   

Step 5 Create a policy map or modify an existing policy map that you want to use to apply the MGCP inspection engine to MGCP traffic. To do so, use the policy-map command, as follows:

hostname(config-cmap)# policy-map policy_map_name
hostname(config-pmap)# 
 
   

where policy_map_name is the name of the policy map. The CLI enters the policy map configuration mode and the prompt changes accordingly.

Step 6 Specify the class map, created in Step 2, that identifies the MGCP traffic. Use the class command to do so, as follows:

hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)# 
 
   

where class_map_name is the name of the class map you created in Step 2. The CLI enters the policy map class configuration mode and the prompt changes accordingly.

 
   

Step 7 Enable MGCP application inspection. To do so, use the inspect mgcp command, as follows:

hostname(config-pmap-c)# inspect mgcp [map_name]
hostname(config-pmap-c)#
 
   

where map_name is the MGCP map that you may have created in optional Step 4.

Step 8 Use the service-policy command to apply the policy map globally or to a specific interface, as follows:

hostname(config-pmap-c)# service-policy policy_map_name [global | interface interface_ID]
hostname(config)#
 
   

where policy_map_name is the policy map you configured in Step 5. If you want to apply the policy map to traffic on all the interfaces, use the global option. If you want to apply the policy map to traffic on a specific interface, use the interface interface_ID option, where interface_ID is the name assigned to the interface with the nameif command.

The FWSM begins inspecting MGCP traffic, as specified.


Example 20-11 shows how to identify MGCP traffic, define a MGCP map, define a policy, and apply the policy to the outside interface. This creates a class map to match MGCP traffic on the default ports (2427 and 2727). This configuration allows call agents 10.10.11.5 and 10.10.11.6 to control gateway 10.10.10.115, and allows call agents 10.10.11.7 and 10.10.11.8 to control both gateways 10.10.10.116 and 10.10.10.117. The maximum number of MGCP commands that can be queued is 150. The service policy is then applied to the outside interface.

Example 20-11 Enabling and Configuring MGCP Inspection

hostname(config)# access-list mgcp_acl permit udp any any eq 2427 
hostname(config)# access-list mgcp_acl permit udp any any eq 2727
hostname(config)# class-map mgcp-traffic 
hostname(config-cmap)# match access-list mgcp_acl 
hostname(config-cmap)# mgcp-map sample_map
hostname(config-mgcp-map)# call-agent 10.10.11.5 101
hostname(config-mgcp-map)# call-agent 10.10.11.6 101
hostname(config-mgcp-map)# call-agent 10.10.11.7 102
hostname(config-mgcp-map)# call-agent 10.10.11.8 102
hostname(config-mgcp-map)# gateway 10.10.10.115 101
hostname(config-mgcp-map)# gateway 10.10.10.116 102
hostname(config-mgcp-map)# gateway 10.10.10.117 102
hostname(config-mgcp-map)# command-queue 150
hostname(config-mgcp-map)# policy-map sample_policy
hostname(config-pmap)# class mgcp_port
hostname(config-pmap-c)# inspect mgcp sample_map
hostname(config-pmap-c)# service-policy sample_policy interface outside
 
   

Configuring MGCP Timeout Values

The timeout mgcp command lets you set the interval for inactivity after which an MGCP media connection is closed. The default is five minutes.

The timeout mgcp-pat command lets you set the timeout for PAT xlates. Because MGCP does not have a keepalive mechanism, if you use non-Cisco MGCP gateways (call agents), the PAT xlates are torn down after the default timeout interval, which is 30 seconds.

Verifying and Monitoring MGCP Inspection

The show mgcp commands command lists the number of MGCP commands in the command queue. The show mgcp sessions command lists the number of existing MGCP sessions. The detail option includes additional information about each command (or session) in the output. The following is sample output from the show mgcp commands command:

hostname# show mgcp commands
1 in use, 1 most used, 200 maximum allowed
CRCX, gateway IP: host-pc-2, transaction ID: 2052, idle: 0:00:07
 
   

The following is sample output from the show mgcp commands detail command:

hostname# show mgcp commands detail
1 in use, 1 most used, 200 maximum allowed
CRCX, idle: 0:00:10
Gateway IP      host-pc-2
Transaction ID  2052
Endpoint name   aaln/1
Call ID         9876543210abcdef
Connection ID   
Media IP        192.168.5.7
Media port      6058
 
   

The following is sample output from the show mgcp sessions command:

hostname# show mgcp sessions
1 in use, 1 most used
Gateway IP host-pc-2, connection ID 6789af54c9, active 0:00:11
 
   

The following is sample output from the show mgcp sessions detail command:

hostname# show mgcp sessions detail
1 in use, 1 most used
Session active 0:00:14
Gateway IP      host-pc-2
Call ID         9876543210abcdef
Connection ID   6789af54c9
Endpoint name   aaln/1
Media lcl port  6166
Media rmt IP    192.168.5.7
Media rmt port  6058
 
   

MGCP Sample Configuration

The following is a sample configuration for MGCP inspection:

Figure 20-12 MGCP Inspection Setup

See the following configuration for this example:

hostname(config)# interface Vlan100
hostname(config-if)# nameif outside
hostname(config-if)# security-level 0
hostname(config-if)# ip address 100.100.100.2 255.0.0.0
hostname(config-if)# !
hostname(config-if)# interface Vlan50
hostname(config-if)# nameif inside
hostname(config-if)# security-level 100
hostname(config-if)# ip address 50.100.100.2 255.0.0.0
hostname(config-if)# !
hostname(config-if)# interface Vlan90
hostname(config-if)# nameif callmgr
hostname(config-if)# security-level 75
hostname(config-if)# ip address 150.0.0.254 255.0.0.0
 
   

TFTP port is enabled so that IOS MGCP gateway can download configuration files from the Cisco CallManager. MGCP control protocol over UDP port 2427 is enabled for pass through. MGCP backup port TCP 2428 is enabled.

hostname(config-if)# access-list mgcp extended permit udp any host 150.0.0.210 eq 2428
hostname(config)# access-list mgcp extended permit udp any any eq 2427
hostname(config)# access-list mgcp extended permit udp any any eq tftp
 
   

Apply the above access lists on the inside and outside interfaces for incoming traffic:

hostname(config)# access-group mgcp in interface outside
hostname(config)# access-group mgcp in interface inside
 
   

Configure call agent (IP address of the Cisco CallManager) and the IP address of the IOS MGCP gateway in an MGCP map:

hostname(config)# mgcp-map mgcp-inspect
hostname(config-mgcp-map)# call-agent 150.0.0.210 101
hostname(config-mgcp-map)# gateway 50.100.100.1 101
hostname(config-mgcp-map)# gateway 100.100.100.1 101
hostname(config-mgcp-map)# command-queue 150
hostname(config-mgcp-map)# exit
 
   

Apply MGCP inspection with MGCP map:

hostname(config)# policy-map global_policy
hostname(config-pmap)# class inspection_default
hostname(config-pmap-c)# inspect mgcp mgcp-inspect
 
   

Output of show conn in admin context, which shows the connections established between IOS MGCP gateways and call agents:

hostname(config)# show conn
6in use, 48 most used
	Network Processor 1 connections
	Network Processor 2 connections
UDP out 150.0.0.210:2427 in 50.100.100.1:2427 idle 0:00:04 Bytes 5790 FLAGS - g
UDP out 100.100.100.1:2427 in 150.0.0.210:2427 idle 0:00:00 Bytes 8221 FLAGS - g
UDP out 100.100.100.1:18199 in 50.100.100.1:19247 idle 0:00:03 Bytes 14080 FLAGS - g
UDP out 100.100.100.1:18199 in 50.100.100.1:19246 idle 0:00:00 Bytes 4030838 FLAGS - g
TCP out 150.0.0.210:2428 in 50.100.100.1:12695 idle 0:00:04 Bytes 1346 FLAGS - UOI
TCP out 100.100.100.1:15954 in 150.0.0.210:2428 idle 0:00:00 Bytes 1346 FLAGS - UBOI
Multicast sessions:
	Network Processor 1 connections
	Network Processor 2 connections
IPV6 connections:
 
   

IOS MGCP gateway configuration of router R2:

hostname(config)# interface FastEthernet 0/1
hostname(config-if)# ip address 100.100.100.1 255.0.0.0
hostname(config-if)# no shut
hostname(config-if)# ip host FWSM-CCM-14 150.0.0.210
hostname(config-if)# exit
hostname(config)# ip route 150.0.0.0 255.0.0.0 100.100.100.2
hostname(config)# mgcp
hostname(config)# mgcp call-agent FWSM-CCM-14
hostname(config)# mgcp dtmf-relay voip codec all mode out-of-band
hostname(config)# ccm-manager mgcp
hostname(config)# ccm-manager config server 150.0.0.210
hostname(config)# ccm-manager config
hostname(config)# dial-peer voice 100 pots
hostname(config-dial-peer)# application mgcpapp
hostname(config-dial-peer)# port 1/0/0
hostname(config-dial-peer)# no shut
 
   

IOS MGCP gateway configuration of router R1:

hostname(config)# interface FastEthernet 0/1
hostname(config-if)# ip address 50.100.100.1 255.0.0.0
hostname(config-if)# no shut
hostname(config-if)# exit
hostname(config)# ip route 150.0.0.0 255.0.0.0 50.100.100.2
hostname(config)# ccm-manager mgcp
hostname(config)# ccm-manager music-on-hold
hostname(config)# ccm-manager config server 150.0.0.210
hostname(config)# ccm-manager config
hostname(config)# mgcp
hostname(config)# mgcp call-agent FWSM-CCM-14
hostname(config)# mgcp dtmf-relay voip codec all mode out-of-band
hostname(config)# dial-peer voice 101 pots
hostname(config-dial-peer)# application mgcpapp
hostname(config-dial-peer)# port 3/0/0
 
   

NetBIOS Inspection

NetBIOS inspection is enabled by default.

For information about NetBIOS inspection, see the inspect netbios command page in the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.

PPTP Inspection

PPTP inspection is disabled by default.

For information about PPTP inspection, see the inspect pptp command page in the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.

RSH Inspection

RSH inspection is enabled by default.

For information about RSH inspection, see the inspect rsh command page in the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.

RTSP Inspection

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

RTSP Inspection Overview

Using RealPlayer

Restrictions and Limitations

Enabling and Configuring RTSP Inspection

RTSP Inspection Overview

You control RTSP application inspection with the inspect rtsp command, available in policy map class configuration mode. This command is disabled by default. The inspect rtsp command lets the FWSM pass RTSP packets. RTSP is used by RealAudio, RealNetworks, Apple QuickTime 4, RealPlayer, and Cisco IP/TV connections.


Note For Cisco IP/TV, use RTSP TCP port 554 and TCP 8554.


RTSP applications use the well-known port 554 with TCP (rarely UDP) as a control channel. The FWSM supports TCP only, in conformity with RFC 2326. This TCP control channel is used to negotiate the data channels that is used to transmit audio/video traffic, depending on the transport mode that is configured on the client.

The supported RDT transports are: rtp/avp, rtp/avp/udp, x-real-rdt, x-real-rdt/udp, and x-pn-tng/udp.

The FWSM parses SETUP response messages with a status code of 200. If the response message is travelling inbound, the server is outside relative to the FWSM and dynamic channels need to be opened for connections coming inbound from the server. If the response message is outbound, then the FWSM does not need to open dynamic channels.

Because RFC 2326 does not require that the client and server ports must be in the SETUP response message, the FWSM keeps state and remembers the client ports in the SETUP message. QuickTime places the client ports in the SETUP message and then the server responds with only the server ports.

RTSP inspection supports PAT. It does not support dual-NAT, however. Also, the FWSM cannot recognize HTTP cloaking, which hides RTSP messages in the HTTP messages.

Using RealPlayer

When using RealPlayer, it is important to properly configure transport mode. For the FWSM, add an access-list command from the server to the client or vice versa. For RealPlayer, change transport mode by choosing Options > Preferences > Transport > RTSP Settings.

If using TCP mode on the RealPlayer, check the Use TCP to Connect to Server and Attempt to use TCP for all content check boxes. On the FWSM, there is no need to configure the inspection engine.

If using UDP mode on the RealPlayer, check the Use TCP to Connect to Server and Attempt to use UDP for static content check boxes, and for live content not available via Multicast. On the FWSM, add an inspect rtsp port command.

Restrictions and Limitations

The following restrictions apply to RTSP inspection:

The FWSM does not support multicast RTSP or RTSP messages over UDP.

The FWSM does not have the ability to recognize HTTP cloaking, which hides RTSP messages in the HTTP messages.

The FWSM cannot perform NAT on RTSP messages because the embedded IP addresses are contained in the SDP files as part of HTTP or RTSP messages. Packets could be fragmented and FWSM cannot perform NAT on fragmented packets.

With Cisco IP/TV, the number of NATs the FWSM performs on the SDP part of the message is proportional to the number of program listings in the Content Manager (each program listing can have at least six embedded IP addresses).

You can configure NAT for Apple QuickTime 4 or RealPlayer. Cisco IP/TV only works with NAT if the Viewer and Content Manager are on the outside network and the server is on the inside network.

Enabling and Configuring RTSP Inspection

To enable or configure RTSP application inspection, perform the following steps:


Step 1 Determine the ports receiving RTSP SETUP messages behind the FWSM. The default ports are TCP ports 554 and 8554.

Step 2 Create an access list to identify the RTSP SETUP messages. Use the access-list extended command to do so, adding an ACE to match each port, as follows:

hostname(config)# access-list acl-name any any tcp eq port_number
 
   

Tip If you allow RTSP SETUP messages on one port only or on a contiguous range or ports, you can skip creating the access list and, in Step 4, use the match port command instead of the match access-list command.


Step 3 Create a class map or modify an existing class map to identify RTSP traffic. Use the class-map command to do so, as follows:

hostname(config)# class-map class_map_name
hostname(config-cmap)#
 
   

where class_map_name is the name of the traffic class. When you enter the class-map command, the CLI enters class map configuration mode.

Step 4 Identify traffic sent to the RTSP ports you determined in Step 1. To do so, use a match access-list command, as follows:

hostname(config-cmap)# match access-list acl-name
 
   

Step 5 Create a policy map or modify an existing policy map that you want to use to apply the RTSP inspection engine to RTSP traffic. To do so, use the policy-map command, as follows:

hostname(config-cmap)# policy-map policy_map_name
hostname(config-pmap)# 
 
   

where policy_map_name is the name of the policy map. The CLI enters the policy map configuration mode and the prompt changes accordingly.

Step 6 Specify the class map, created in Step 3, that identifies the RTSP traffic. Use the class command to do so, as follows:

hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)# 
 
   

where class_map_name is the name of the class map you created in Step 2. The CLI enters the policy map class configuration mode and the prompt changes accordingly.

Step 7 Enable RTSP application inspection. To do so, use the inspect rtsp command, as follows:

hostname(config-pmap-c)# inspect rtsp
hostname(config-pmap-c)#
 
   

Step 8 Use the service-policy command to apply the policy map globally or to a specific interface, as follows:

hostname(config-pmap-c)# service-policy policy_map_name [global | interface interface_ID]
hostname(config)#
 
   

where policy_map_name is the policy map you configured in Step 5. If you want to apply the policy map to traffic on all the interfaces, use the global option. If you want to apply the policy map to traffic on a specific interface, use the interface interface_ID option, where interface_ID is the name assigned to the interface with the nameif command.

The FWSM begins inspecting RTSP traffic, as specified.

 
   

Example 20-12 shows how to enable the RTSP inspection engine RTSP traffic on the default ports (554 and 8554). The service policy is then applied to the outside interface.

Example 20-12 Enabling and Configuring RTSP Inspection

hostname(config)# access-list rtsp_acl permit tcp any any eq 554 
hostname(config)# access-list rtsp_acl permit tcp any any eq 8554
hostname(config)# class-map rtsp-traffic 
hostname(config-cmap)# match access-list rtsp_acl 
hostname(config-cmap)# policy-map sample_policy 
hostname(config-pmap)# class rtsp_port
hostname(config-pmap-c)# inspect rtsp
hostname(config-pmap-c)# service-policy sample_policy interface outside
 
   

SIP Inspection

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

SIP Inspection Overview

SIP Instant Messaging

IP Address Privacy

Enabling and Configuring SIP Inspection

Configuring SIP Timeout Values

SIP Inspection Enhancement

Verifying and Monitoring SIP Inspection

SIP Sample Configurations

SIP Inspection Overview

SIP, as defined by the IETF, enables call handling sessions, particularly two-party audio conferences, or "calls." SIP works with SDP for call signalling. SDP specifies the ports for the media stream. Using SIP, the FWSM can support any SIP VoIP gateways and VoIP proxy servers. SIP and SDP are defined in the following RFCs:

SIP: Session Initiation Protocol, RFC 2543

SDP: Session Description Protocol, RFC 2327

Supporting SIP calls through the FWSM requires inspection of signaling messages for the media connection addresses, media ports, and embryonic connections for the media. While SIP signalling is sent over a well-known destination port (UDP/TCP 50/60), the media streams use dynamically allocated ports. Also, SIP embeds IP addresses in the user-data portion of the IP packet and SIP inspection applies NAT for these embedded IP addresses.

The following limitations and restrictions apply when using PAT with SIP:

If a remote endpoint tries to register with a SIP proxy on a network protected by the FWSM, the registration fails under very specific conditions, as follows:

PAT is configured for the remote endpoint.

The SIP registrar server is on the outside network.

The port is missing in the contact field in the REGISTER message sent by the endpoint to the proxy server.

If a SIP device transmits a packet in which the SDP portion has an IP address in the owner/creator field (o=) that is different than the IP address in the connection field (c=), the IP address in the o= field may not be properly translated. This is due to a limitation in the SIP protocol, which does not provide a port value in the o= field.

SIP Instant Messaging

Instant Messaging refers to the transfer of messages between users in near real-time. SIP supports the Chat feature on Windows XP using Windows Messenger RTC Client version 4.7.0105 only. The MESSAGE/INFO methods and 202 Accept response are used to support IM as defined in the following RFCs:

Session Initiation Protocol (SIP)-Specific Event Notification, RFC 3265

Session Initiation Protocol (SIP) Extension for Instant Messaging, RFC 3428

MESSAGE/INFO requests can come in at any time after registration/subscription. For example, two users can be online at any time, but not chat for hours. Therefore, the SIP inspection engine opens pinholes that time out according to the configured SIP timeout value. This value must be configured at least five minutes longer than the subscription duration. The subscription duration is defined in the Contact Expires value and is typically 30 minutes.

Because MESSAGE/INFO requests are typically sent using a dynamically allocated port other than port 5060, they are required to go through the SIP inspection engine.


Note Only the Chat feature is currently supported. Whiteboard, File Transfer, and Application Sharing are not supported. RTC Client 5.0 is not supported.


SIP inspection NATs the SIP text-based messages, recalculates the content length for the SDP portion of the message, and recalculates the packet length and checksum. It dynamically opens media connections for ports specified in the SDP portion of the SIP message as address/ports on which the endpoint should listen.

SIP inspection has a database with indices CALL_ID/FROM/TO from the SIP payload. These indices identify the call, the source, and the destination. This database contains the media addresses and media ports found in the SDP media information fields and the media type. There can be multiple media addresses and ports for a session. The FWSM opens RTP/RTCP connections between the two endpoints using these media addresses/ports.

The well-known port 5060 must be used on the initial call setup (INVITE) message; however, subsequent messages may not have this port number. The SIP inspection engine opens signaling connection pinholes, and marks these connections as SIP connections. This is done for the messages to reach the SIP application and be NATed.

As a call is set up, the SIP session is in the "transient" state until the media address and media port is received from the called endpoint in a Response message indicating the RTP port the called endpoint listens on. If there is a failure to receive the response messages within one minute, the signaling connection is torn down.

Once the final handshake is made, the call state is moved to active and the signaling connection remains until a BYE message is received.

If an inside endpoint initiates a call to an outside endpoint, a media hole is opened to the outside interface to allow RTP/RTCP UDP packets to flow to the inside endpoint media address and media port specified in the INVITE message from the inside endpoint. Unsolicited RTP/RTCP UDP packets to an inside interface does not traverse the FWSM, unless the FWSM configuration specifically allows it.

IP Address Privacy

When IP Address Privacy is enabled, if any two SIP endpoints participating in an IP phone call or instant messaging session use the same internal firewall interface to contact their SIP proxy server on an external firewall interface, all SIP signaling messages go through the SIP proxy server.

IP Address Privacy can be enabled when SIP over TCP or UDP application inspection is enabled. By default, this feature is disabled. If IP Address Privacy is enabled, the FWSM does not translate internal and external host IP addresses embedded in the TCP or UDP payload of inbound SIP traffic, ignoring translation rules for those IP addresses.

You control whether this feature is enabled by using the ip-address-privacy command in SIP map configuration mode.

Enabling and Configuring SIP Inspection

SIP inspection is enabled by default.

To enable SIP inspection, with or without enabling the IP Address Privacy feature, perform the following steps:


Step 1 Determine the ports that SIP servers behind the FWSM listen to for SIP traffic. The default port is TCP and UDP port 5060.

Step 2 Create a class map or modify an existing class map to identify SIP traffic. Use the class-map command to do so, as follows:

hostname(config)# class-map class_map_name
hostname(config-cmap)#
 
   

where class_map_name is the name of the traffic class. When you enter the class-map command, the CLI enters class map configuration mode.

Step 3 Identify traffic sent to the SIP ports you determined in Step 1. To do so, use a match port or match access-list command.

If you need to identify UDP and TCP ports or if you need to identify two or more non-contiguous ports, create an access list with the access-list extended command, add an ACE to match each port, and then use the match access-list command. The following commands show how to use an access list to identify TCP and UDP ports with an access list:

hostname(config)# access-list acl-name any any tcp eq port_number
hostname(config)# access-list acl-name any any udp eq port_number
hostname(config)# class-map class_map_name
hostname(config-cmap)# match access-list acl-name
 
   

If you need to identify a single port using a single protocol, use the match port command, as follows:

hostname(config-cmap)# match port {tcp | udp} port_number
 
   

where port_number is the only port listened to by SIP servers behind the FWSM.

If you need to identify a range of contiguous ports for a single protocol, use match port command with the range keyword, as follows:

hostname(config-cmap)# match port tcp range begin_port_number end_port_number
 
   

where begin_port_number is the lowest port in the range of SIP ports and end_port_number is the highest port.

Step 4 (Optional) If you want to enable IP address privacy, perform the following steps:

a. Create a SIP map that will contain the parameters of SIP inspection. Use the sip-map command to do so, as follows:

hostname(config-cmap)# sip-map map_name
hostname(config-sip-map)#
 
   

where map_name is the name of the SIP map. The CLI enters SIP map configuration mode.

b. Define the configuration of the SIP map by entering the following command:

hostname(config-sip-map)# ip-address-privacy
 
   

Step 5 Create a policy map or modify an existing policy map that you want to use to apply the SIP inspection engine to the SIP traffic. To do so, use the policy-map command, as follows:

hostname(config-cmap)# policy-map policy_map_name
hostname(config-pmap)# 
 
   

where policy_map_name is the name of the policy map. The CLI enters the policy map configuration mode and the prompt changes accordingly.

Step 6 Specify the class map, created in Step 2, that identifies the SIP traffic. Use the class command to do so, as follows:

hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)# 
 
   

where class_map_name is the name of the class map you created in Step 2. The CLI enters the policy map class configuration mode and the prompt changes accordingly.

Step 7 Enable SIP application inspection. To do so, use the inspect sip command, as follows:

hostname(config-pmap-c)# inspect sip [map_name]
hostname(config-pmap-c)#
 
   

where map_name is the SIP map that you may have created in optional Step 4.

Step 8 Use the service-policy command to apply the policy map globally or to a specific interface, as follows:

hostname(config-pmap-c)# service-policy policy_map_name [global | interface interface_ID]
hostname(config)#
 
   

where policy_map_name is the policy map you configured in Step 5. If you want to apply the policy map to traffic on all the interfaces, use the global option. If you want to apply the policy map to traffic on a specific interface, use the interface interface_ID option, where interface_ID is the name assigned to the interface with the nameif command.

The FWSM begins inspecting SIP traffic, as specified.


You enable the SIP inspection engine as shown in Example 20-13, which creates a class map to match SIP traffic on the default port (5060). The service policy is then applied to the outside interface.

Example 20-13 Enabling SIP Application Inspection

hostname(config)# class-map sip_port
hostname(config-cmap)# match port tcp eq 5060
hostname(config-cmap)# sip-map sample_map
hostname(config-snmp-map)# ip-address-privacy
hostname(config-snmp-map)# policy-map sample_policy 
hostname(config-pmap)# class sip_port
hostname(config-pmap-c)# inspect sip sample_map
hostname(config-pmap-c)# service-policy sample_policy interface outside
 
   

Configuring SIP Timeout Values

The media connections are torn down within two minutes after the connection becomes idle. This is, however, a configurable timeout and can be set for a shorter or longer period of time. To configure the timeout for the SIP control connection, use the following command:

hostname(config)# timeout sip hh:mm:ss
 
   

This command configures the idle timeout after which a SIP control connection is closed.

To configure the timeout for the SIP disconnect, use the following command:

hostname(config)# timeout sip_disconnect hh:mm:ss
 
   

This command configures the idle timeout after which SIP media is deleted and media xlates are closed. Range is from 1 to 10 minutes.

To configure the timeout for the SIP invite, use the following command:

hostname(config)# timeout sip_invite hh:mm:ss
 
   

In the absence of the EXPIRE field in the SIP header, this command configures the idle timeout after which pinholes for provisional responses and media xlates are closed. Range is from 1 to 30 minutes. Default is 30 minutes.

To configure the timeout for the SIP media timer, use the following command:

hostname(config)# timeout sip_media hh:mm:ss
 
   

This command modifies the SIP media idle timer, which determines the time after which the SIP RTP/RTCP connections are torn down due to inactivity. This command overrides the UDP inactivity timeout timeout udp command for SIP media connections only. Default timeout value is 2 minutes. Minimum timeout value is 1 minute. Maximum timeout value is 1193 hours. Value 0 causes SIP media connections not to timeout.

SIP Inspection Enhancement

The SIP inspection enhancement removes media connections after receiving 200 OK for the BYE SIP message, 200 OK for the CANCEL SIP message, and 200 OK for 4xx/5xx/6xx SIP messages, instead of waiting for the idle timeout.

Figure 20-13 Media Connection Clear on BYE Message

In Figure 20-13, when 200 OK is not received for the BYE message, media connections are removed after the timeout sip-disconnect occurs.

Figure 20-14 Media Connection Clear on CANCEL Message

In Figure 20-14, the media connection is cleared after 200 OK is received for the CANCEL message. If 200 OK is not received for the CANCEL SIP message, the media connection is cleared after the timeout sip-disconnect occurs.

Figure 20-15 Media Connection Clear on 4xx/5xx/6xx SIP Messages

In Figure 20-15, the media connections are cleared immediately when 200 OK is received in response for 4xx/5xx/6xx SIP messages. If 200 OK is not received, the media connection is cleared after the timeout sip-disconnect occurs.

It is possible to extend the timeout for provisional responses. The timeout for pinholes receiving 1xx/2xx responses is configurable, or configured based on the EXPIRE field. When the EXPIRE field exists in the SIP INVITE message, and is less than 30 minutes, the timeout for pinholes for receiving 1xx/2xx responses is set to the EXPIRE field value. If the EXPIRE field value in the SIP INVITE header is greater than 30 minutes, the timeout for provisional responses is set to 30 minutes. In the absence of the EXPIRE field in the SIP INVITE message, the timeout for provisional responses is set to the value configured using the timeout sip-invite command.

Figure 20-16 Extending Timeout for Provisional Responses

Restrictions include:

SIP media connections are not cleared when 200 OK is received for the BYE message, CANCEL message, or 4xx/5xx/6xx SIP message for those SIP sessions established prior to failover. SIP sessions established after failover are cleared.

Pinholes opened for SIP responses are not cleared along with SIP media connections when 200 OK is received for the BYE SIP message, CANCEL SIP message, or 4xx/5xx/6xx SIP message. Instead, pinhole connections are cleared eventually due to timeout.

Verifying and Monitoring SIP Inspection

The show sip command assists in troubleshooting SIP inspection engine issues and is described with the inspect protocol sip udp 5060 command. The show timeout sip command displays the timeout value of the designated protocol.

The show sip command displays information for SIP sessions established across the FWSM. Along with the debug sip and show local-host commands, this command is used for troubleshooting SIP inspection engine issues.


Note We recommend that you configure the pager command before entering the show sip command. If there are a lot of SIP session records and the pager command is not configured, it takes a while for the show sip command output to reach its end.


The following is sample output from the show sip command:

hostname# show sip
Total: 2
call-id c3943000-960ca-2e43-228f@10.130.56.44
    state Call init, idle 0:00:01
call-id c3943000-860ca-7e1f-11f7@10.130.56.45
    state Active, idle 0:00:06
 
   

This sample shows two active SIP sessions on the FWSM (as shown in the Total field). Each call-id represents a call.

The first session, with the call-id c3943000-960ca-2e43-228f@10.130.56.44, is in the state Call Init, which means the session is still in call setup. Call setup is not complete until a final response to the call has been received. For instance, the caller has already sent the INVITE, and maybe received a 100 Response, but has not yet seen the 200 OK, so the call setup is not complete yet. Any non-1xx response message is considered a final response. This session has been idle for 1 second.

The second session is in the state Active, in which call setup is complete and the endpoints are exchanging media. This session has been idle for 6 seconds.

SIP Sample Configurations

This section includes the following sample configurations:

SIP Inspection Example

SIP IP Address Privacy Example

SIP Inspection Example

The following is a sample configuration for SIP inspection:

Figure 20-17 SIP Inspection Setup

Configuring inside VLAN (VLAN 50) which connects to inside Cisco 7960 SIP IP Phone:

hostname(config)# hostname FWSM
hostname(config)# interface Vlan50
hostname(config-if)# nameif inside
hostname(config-if)# security-level 100
hostname(config-if)# ip address 50.100.100.1 255.255.255.0
hostname(config-if)# exit
 
   

Configuring VLAN100 which connects to CallManager 5.0.4.2000-1:

hostname(config)# interface Vlan100
hostname(config-if)# nameif callmgr
hostname(config-if)# security-level 75
hostname(config-if)# ip address 100.100.100.1 255.255.255.0  
hostname(config-if)# exit
 
   

Configuring outside VLAN (VLAN150) which connects to outside Cisco 7960 SIP IP Phone:

hostname(config)# interface Vlan150
hostname(config-if)# nameif outside
hostname(config-if)# security-level 0
hostname(config-if)# ip address 150.100.100.1 255.255.255.0 
 
   

Configuring access list to enable TFTP download of configuration files from Cisco CallManager to Cisco IP Phones and to allow SIP traffic to pass to Cisco CallManager from IP Phones:

hostname(config-if)# access-list voice extended permit udp any host 100.100.100.100 eq 
tftp
hostname(config)# access-list voice extended permit udp any host 100.100.100.100 eq sip
 
   

Applying the previously configured access list on configured interfaces:

hostname(config)# access-group voice in interface inside
hostname(config)# access-group voice in interface callmgr
hostname(config)# access-group voice in interface outside
 
   

The following is the show conn output from a call made from an inside phone to an outside phone:

hostname# show conn
13 in use, 21 most used
 Network Processor 1 connections 
 Network Processor 2 connections 
UDP out 100.100.100.100:5060 in 50.100.100.111:50074 idle 0:01:15 Bytes 5153 FLAGS - T
UDP out 100.100.100.100:5060 in 50.100.100.111:50081 idle 0:03:09 Bytes 313 FLAGS - T
UDP out 100.100.100.100:5060 in 50.100.100.111:50082 idle 0:03:05 Bytes 427 FLAGS - T
UDP out 100.100.100.100:5060 in 50.100.100.111:50083 idle 0:03:02 Bytes 427 FLAGS - T
UDP out 150.100.100.116:50879 in 100.100.100.100:5060 idle 0:00:51 Bytes 3646 FLAGS - T
UDP out 150.100.100.116:50881 in 100.100.100.100:5060 idle 0:02:46 Bytes 313 FLAGS - T
UDP out 150.100.100.116:0 in 100.100.100.100:5060 idle 0:02:35 Bytes 18 FLAGS - t
UDP out 150.100.100.116:29392 in 50.100.100.111:26674 idle 0:00:00 Bytes 3345882 FLAGS - m
UDP out 100.100.100.100:0 in 50.100.100.111:5060 idle 0:01:15 Bytes 18 FLAGS - t
UDP out 150.100.100.116:5060 in 100.100.100.100:0 idle 0:00:51 Bytes 18 FLAGS - t
 
   
Multicast sessions:
 Network Processor 1 connections 
 Network Processor 2 connections 
IPv6 connections:
 
   

SIP IP Address Privacy Example

The following is a sample configuration for SIP IP Address Privacy setup:

Figure 20-18 SIP IP Address Privacy Setup

See the following configuration for this example:

hostname(config)# interface Vlan12
hostname(config-if)# nameif outside
hostname(config-if)# security-level 0
hostname(config-if)# ip address 12.0.0.10 255.0.0.0
hostname(config-if)# !
 
   

Vlan 12 is an outside Vlan that routes all packets to 30.x.x.x network back to the FWSM with the next hop IP address set to 12.0.0.10. This is done by configuring policy-based routing at the up-stream router.

hostname(config-if)# interface Vlan50
hostname(config-if)# nameif inside
hostname(config-if)# security-level 100
hostname(config-if)# ip address 50.100.100.7 255.255.255.0
 
   

The two phones 4085260002 and 4085260008 are used in the same 50.100.100.0 subnet.

hostname(config)# access-list voice extended permit udp any any eq sip
hostname(config)# access-list voice extended permit tcp any any eq sip
hostname(config)# access-list voice extended permit udp any any eq tftp
hostname(config)# !
hostname(config)# sip-map privacy
hostname(config-if)# ip-address-privacy
hostname(config)# !
hostname(config)# nat-control
hostname(config)# static (inside, outside) 30.100.100.115 50.100.100.115 netmask 
255.255.255.255
hostname(config)# static (inside, outside) 30.100.100.118 50.100.100.118 netmask 
255.255.255.255
 
   

Each phone IP address is translated to an external dummy IP address that is not in a network connected to the FWSM. The translated IP address should not be in a network connected to the FWSM.

hostname(config)# access-group voice in interface outside
hostname(config)# access-group voice in interface inside
hostname(config)# route outside 30.0.0.0 255.0.0.0 12.0.0.5 1
 
   

Configure route to 30.0.0.0 via 12.0.0.5 (IP address of the next hop router):

hostname(config)# route outside 100.0.0.0 255.0.0.0 12.0.0.5 1
hostname(config)# !
hostname(config)# policy-map global_policy
hostname(config-pmap)# class inspection_default
hostname(config-pmap-c)# inspect dns maximum-length 512
hostname(config-pmap-c)# inspect ftp
hostname(config-pmap-c)# inspect h323 h225
hostname(config-pmap-c)# inspect h323 ras
hostname(config-pmap-c)# inspect rsh
hostname(config-pmap-c)# inspect smtp
hostname(config-pmap-c)# inspect sqlnet
hostname(config-pmap-c)# inspect skinny
hostname(config-pmap-c)# inspect sunrpc
hostname(config-pmap-c)# inspect xdmcp
hostname(config-pmap-c)# inspect netbios
hostname(config-pmap-c)# inspect tftp
hostname(config-pmap-c)# inspect sip privacy

Router configuration:

hostname(config)# interface GigabitEthernet0/2
hostname(config-if)# ip address 12.0.0.5 255.0.0.0
hostname(config-if)# ip policy route-map privacy
hostname(config-if)# duplex auto
hostname(config-if)# speed auto
hostname(config-if)# media-type rj45
hostname(config-if)# no negotiation auto
hostname(config-if)# !
hostname(config)# interface GigabitEthernet0/3
hostname(config-if)# ip address 100.100.100.1 255.0.0.0
hostname(config-if)# duplex auto
hostname(config-if)# speed auto
hostname(config-if)# media-type rj45
hostname(config-if)# no negotiation auto
hostname(config-if)# !
hostname(config-if)# ip route 30.0.0.0 255.0.0.0 12.0.0.10
hostname(config-if)# ip route 50.0.0.0 255.0.0.0 12.0.0.10
 
   

Configured route to 30.0.0.0 and 50.0.0.0 reachable via 12.0.0.10 (IP address of FWSM).

hostname(config)# access-list 10 permit ip any 30.0.0.0 0.255.255.255
hostname(config)# !
hostname(config)# route-map privacy permit 10
hostname(config-if)# match ip address 100
hostname(config-if)# set ip next-hop 12.0.0.10

Route map is configured to capture any packets destined for 30.0.0.0 network to be sent to 12.0.0.10 (IP address of FWSM).

The show conn output at the FWSM shows that voice traffic is getting switched via the FWSM module and hiding each phone IP address. RTP traffic is not switched via the same subnet. Instead it is getting routed via the FWSM.

hostname(config)# show conn
6 in use, 28 most used
	Network Processor 1 connections
UDP out 100.100.100.100:5060 in 50.100.100.118:5060 idle 0:00:21 Bytes 67358 FLAGS - T
UDP out 30.100.100.115:16384 in 50.100.100.118:16384 idle 0:00:00 Bytes 6042324 FLAGS - m
UDP out 100.100.100.100:0 in 50.100.100.118:5060 idle 0:00:21 Bytes 18 FLAGS - t
 Network Processor 2 connections 
UDP out 100.100.100.100:5060 in 50.100.100.115:5060 idle 0:00:25 Bytes 80181 FLAGS - T
UDP out 30.100.100.118:16384 in 50.100.100.115:16384 idle 0:00:00 Bytes 6047556 FLAGS - m
UDP out 100.100.100.100:0 in 50.100.100.115:5060 idle 0:00:25 Bytes 33 FLAGS - t
Multicast sessions:
 Network Processor 1 connections 
 Network Processor 2 connections 
IPv6 connections:
 
   
hostname(config)# show xlate
2 in use, 2 most used
Global 30.100.100.115 Local 50.100.100.115
Global 30.100.100.118 Local 50.100.100.118
 
   

Skinny (SCCP) Inspection

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

SCCP Inspection Overview

Supporting Cisco IP Phones

Restrictions and Limitations

Configuring and Enabling SCCP Inspection

Verifying and Monitoring SCCP Inspection

SCCP (Skinny) Sample Configuration

SCCP Inspection Overview

Skinny (SCCP) is a simplified protocol used in VoIP networks. Cisco IP Phones using SCCP can coexist in an H.323 environment. When used with Cisco CallManager, the SCCP client can interoperate with H.323 compliant terminals. Application layer functions in the FWSM recognize SCCP Version 3.3. There are 5 versions of the SCCP protocol: 2.4, 3.0.4, 3.1.1, 3.2, and 3.3.2. The FWSM supports all versions through Version 3.3.2.

The FWSM supports PAT and NAT for SCCP. PAT is necessary if you have more IP phones than global IP addresses for the IP phones to use. By supporting NAT and PAT of SCCP Signaling packets, Skinny application inspection ensures that all SCCP signalling and media packets can traverse the FWSM.

Normal traffic between Cisco CallManager and Cisco IP Phones uses SCCP and is handled by SCCP inspection without any special configuration. The FWSM also supports DHCP options 150 and 66, which it accomplishes by sending the location of a TFTP server to Cisco IP Phones and other DHCP clients. Cisco IP Phones might also include DHCP option 3 in their requests, which sets the default route. For more information, see the "Using Cisco IP Phones with a DHCP Server" section.

Supporting Cisco IP Phones

In topologies where Cisco CallManager is located on the higher security interface with respect to the Cisco IP Phones, if NAT is required for the Cisco CallManager IP address, the mapping must be static because a Cisco IP Phone requires the Cisco CallManager IP address to be specified explicitly in its configuration. A static identity entry allows the Cisco CallManager on the higher security interface to accept registrations from the Cisco IP Phones. Cisco IP Phones require access to a TFTP server to download the configuration information they need to connect to the Cisco CallManager server.

When the Cisco IP Phones are on a lower security interface compared to the TFTP server, you must use an access list to connect to the protected TFTP server on UDP port 69. While you do need a static identity entry for the TFTP server, this does not have to be an identity static entry. When you use NAT, a static identity entry maps to the same IP address. When you use PAT, it maps to the same IP address and port.

When the Cisco IP Phones are on a higher security interface compared to the TFTP server and Cisco CallManager, no access list or static identity entry is required to allow the Cisco IP Phones to initiate the connection.

Restrictions and Limitations

The following are limitations that apply to the current version of PAT and NAT support for SCCP:

PAT does not work with configurations containing the alias command.

Outside NAT or PAT is not supported.

If the address of an internal Cisco CallManager is configured for NAT or PAT to a different IP address or port, registrations for external Cisco IP Phones fail because the FWSM currently does not support NAT or PAT for the file content transferred over TFTP. Although the FWSM supports NAT of TFTP messages and opens a pinhole for the TFTP file, the FWSM cannot translate the Cisco CallManager IP address and port embedded in the Cisco IP Phone configuration files that are transferred by TFTP during phone registration.


Note The FWSM supports stateful failover of SCCP calls except for calls that are in the middle of call setup.


Configuring and Enabling SCCP Inspection

SCCP inspection is enabled by default.

To enable SCCP inspection or change the default port used for receiving SCCP 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 sccp_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 2000
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 2000-2010
 
   

To assign more than one non-contiguous port for SCCP inspection, enter the access-list extended command and define an ACE to match each port. Then enter the match command to associate the access lists with the SCCP 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 sccp_port traffic class to the current policy map:

hostname(config-pmap)# class sccp_port
 
   

The CLI enters the policy map class configuration mode and the prompt changes accordingly, as follows:

hostname(config-pmap-c)# 
 
   

Step 5 (Optional) To change the default port used by the FWSM for receiving SCCP traffic, enter the following command:

hostname(config-pmap-c)# inspect skinny 
 
   

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 FWSM interfaces:

hostname(config)# service-policy sample_policy global
 
   

You enable the SCCP inspection engine as shown in Example 20-14, which creates a class map to match SCCP traffic on the default port (2000). The service policy is then applied to the outside interface.

Example 20-14 Enabling SCCP Application Inspection

hostname(config)# class-map sccp_port
hostname(config-cmap)# match port tcp eq 2000
hostname(config-cmap)# exit
hostname(config)# policy-map sample_policy 
hostname(config-pmap)# class sccp_port
hostname(config-pmap-c)# inspect skinny
hostname(config-pmap-c)# exit
hostname(config)# service-policy sample_policy interface outside

Verifying and Monitoring SCCP Inspection

The show skinny command assists in troubleshooting SCCP (Skinny) inspection engine issues. The following is sample output from the show skinny command under the following conditions. There are two active Skinny sessions set up across the FWSM. The first one is an audio connection established between an internal Cisco IP Phone at local address 10.0.0.11 and an external Cisco CallManager at 172.18.1.33. TCP port 2000 is the CallManager. The second one is a video connection established between another internal Cisco IP Phone at local address 10.0.0.22 and the same Cisco CallManager.

hostname# show skinny
        LOCAL                   FOREIGN                 STATE
---------------------------------------------------------------
1       10.0.0.11/52238         172.18.1.33/2000                1
  AUDIO 10.0.0.11/22948         172.18.1.22/20798
2       10.0.0.22/52232         172.18.1.33/2000                1
  VIDEO 10.0.0.22/20798         172.18.1.11/22948
 
   

The output indicates that a call has been established between two internal Cisco IP Phones. The RTP listening ports of the first and second phones are UDP 22948 and 20798 respectively.

The following is sample output from the show xlate debug command for these Skinny connections:

hostname# show xlate debug
2 in use, 2 most used
Flags:  D - DNS, d - dump, I - identity, i - inside, n - no random,
        r - portmap, s - static
NAT from inside:10.0.0.11 to outside:172.18.1.11 flags si idle 0:00:16 timeout 0:05:00
NAT from inside:10.0.0.22 to outside:172.18.1.22 flags si idle 0:00:14 timeout 0:05:00
 
   

SCCP (Skinny) Sample Configuration

The following is a sample configuration for SCCP (Skinny) inspection:

Figure 20-19 SCCP (Skinny) Inspection Setup

See the following configuration for this example:

hostname(config)# interface Vlan100
hostname(config-if)# nameif outside
hostname(config-if)# security-level 0
hostname(config-if)# ip address 100.100.100.2 255.0.0.0
hostname(config-if)# !
hostname(config-if)# interface Vlan50
hostname(config-if)# nameif inside
hostname(config-if)# security-level 100
hostname(config-if)# ip address 50.100.100.2 255.0.0.0
hostname(config-if)# !
hostname(config-if)# interface Vlan90
hostname(config-if)# nameif callmgr
hostname(config-if)# security-level 75
hostname(config-if)# ip address 150.0.0.254 255.0.0.0
 
   

TFTP port is enabled for the IP address of the CallManager so that phones on the inside and outside can download configuration files from the CallManager for initial setup. TCP Port 2000 is enabled for the IP address of the CallManager so that skinny signaling can pass the module between the phone and the CallManager through firewall module.

hostname(config-if)# access-list voice extended permit udp any host 150.0.0.210 eq tftp
hostname(config)# access-list voice extended permit tcp any host 150.0.0.210 eq 2000
 
   

Apply the above access lists on the inside and outside interfaces for incoming traffic:

hostname(config)# access-group voice in interface outside
hostname(config)# access-group voice in interface inside
 
   

Configure SCCP (Skinny) inspection:

hostname(config)# policy-map global_policy
hostname(config-pmap)# class inspection_default

hostname(config-pmap-c)# inspect skinny

Output of show skinny when Skinny phone call through the firewall module is active:

hostname(config)# show skinny
		LOCAL 						FOREIGN 						STATE
---------------------------------------------------------------------
1			50.0.0.2/49723						150.0.0.210/2000							1
	AUDIO		50.0.0.2/24002						100.0.0.211/19212
2			150.0.0.210/2000						100.0.0.211/49692							1
	AUDIO		50.0.0.2/24002						100.0.0.211/19212
 
   

Output of show conn when there is one active phone call between Skinny phones, each reachable through inside and outside interfaces. Skinny connections are marked by a k flag.

hostname(config)# show conn
3 in use, 26 most used
	Network Processor 1 connections
TCP out 150.0.0.210:2000 in 50.0.0.2:49723 idle 0:00:07 Bytes 10232 FLAGS - UOI
	Network Processor 2 connections
TCP out 150.0.0.211:49692 in 150.0.0.210:49723 idle 0:00:27 Bytes 12394 FLAGS - UBOI
UDP out 150.0.0.211:19212 in 50.0.0.2:24002 idle 0:00:00 Bytes 3575654 FLAGS - K
Multicast sessions:
	Network Processor 1 connections
	Network Processor 2 connections
IPV6 connections:
 
   

SMTP and Extended SMTP Inspection

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

SMTP and Extended SMTP Inspection Overview

Configuring and Enabling SMTP and Extended SMTP Application Inspection

SMTP and Extended SMTP Inspection Overview

The FWSM supports application inspection for SMTP and ESMTP. Application inspection for these protocols protects against attacks by restricting the types of SMTP or ESMTP commands that can pass through the FWSM and by adding monitoring capabilities.

ESMTP is an enhancement to the SMTP protocol and is similar to SMTP. For convenience, the term SMTP is used in this document to refer to both SMTP and ESMTP. The application inspection process for ESMTP includes support for SMTP sessions. Most commands used in an ESMTP session are the same as those used in an SMTP session but an ESMTP session is considerably faster and offers more options related to reliability and security, such as delivery status notification.

The inspect smtp command supports seven RFC 821 commands (DATA, HELO, MAIL, NOOP, QUIT, RCPT, RSET). The inspect esmtp command supports those seven commands and supports the following extended SMTP commands: AUTH, HELP, EHLO, ETRN, SAML, SEND, SOML and VRFY.

Other SMTP or ESMTP commands and private extensions to ESMTP and are not supported. Unsupported commands are translated into Xs, which are rejected by the SMTP server protected by the FWSM. This results in a message such as "500 Command unknown: 'XXX'." Incomplete commands are discarded.

SMTP application inspection, as enabled by the inspect smtp command, occurs in fast path processing; therefore, it occurs on one of the three network processors on the FWSM. ESMTP application inspection, as enabled by the inspect esmtp command, occurs in control plane path processing; therefore, it occurs on the single, general purpose processor on the FWSM.


Note If a policy map contains both the inspect smtp command and the inspect esmtp command, only the first command listed in the policy map is applied to matching traffic.


Inspection changes the characters in the server SMTP banner to asterisks except for the "2", "0", "0" characters. Carriage return (CR) and linefeed (LF) characters are ignored.

With SMTP inspection enabled, a Telnet session used for interactive SMTP may hang if the following rules are not observed: SMTP commands must be at least four characters in length; must be terminated with carriage return and line feed; and must wait for a response before issuing the next reply.

An SMTP server responds to client requests with numeric reply codes and optional human-readable strings. SMTP application inspection controls and reduces the commands that the user can use as well as the messages that the server returns. SMTP inspection performs three primary tasks:

Restricts SMTP requests to seven basic SMTP commands and eight extended commands.

Monitors the SMTP command-response sequence.

Generates an audit trail—Audit record 108002 is generated when invalid character embedded in the mail address is replaced. For more information, see RFC 821.

SMTP inspection monitors the command and response sequence for the following anomalous signatures:

Truncated commands.

Incorrect command termination (not terminated with <CR><LR>).

The MAIL and RCPT commands specify who are the sender and the receiver of the mail. Mail addresses are scanned for strange characters. The pipeline character (|) is deleted (changed to a blank space) and "<" ‚">" are only allowed if they are used to define a mail address (">" must be preceded by "<").

Unexpected transition by the SMTP server.

For unknown commands, the FWSM changes all the characters in the packet to X. In this case, the server generates an error code to the client. Because of the change in the packed, the TCP checksum has to be recalculated or adjusted.

TCP stream editing.

Command pipelining.


Note FWSM supports SMTP and Extended SMTP Inspection for inbound traffic only; namely, FWSM supports inspection of traffic from a lower security level to a higher security level.


Configuring and Enabling SMTP and Extended SMTP Application Inspection

SMTP inspection is enabled by default.

To enable SMTP or extended SMTP inspection, perform the following steps:


Step 1 Determine the ports that SMTP servers behind the FWSM listen to for SMTP traffic. The default port is TCP port 25 but your SMTP servers may be configured to listen to other ports.

Step 2 Create a class map or modify an existing class map to identify SMTP traffic. Use the class-map command to do so, as follows:

hostname(config)# class-map class_map_name
hostname(config-cmap)#
 
   

where class_map_name is the name of the traffic class. When you enter the class-map command, the CLI enters class map configuration mode.

Step 3 Use a match command to identify traffic sent to the SMTP ports you determined in Step 1.

If the port mapper process listens to a single port, you can use the match port command to identify traffic sent to that port, as follows:

hostname(config-cmap)# match port tcp eq port_number
 
   

where port_number is the port to which the port mapper process listens. If you need to assign a range of contiguous ports, use the range keyword, as in the following example:

hostname(config-cmap)# match port tcp range begin_port_number end_port_number
 
   

Tip To identify two or more non-contiguous ports, enter the access-list extended command and define an ACE to match each port. Then, rather than the match port command, use the match access-list command to associate the access list with the SMTP traffic class.


Step 4 Create a policy map that you want to use to apply the SMTP inspection engine to the SMTP traffic. To do so, use the policy-map command, as follows:

hostname(config-cmap)# policy-map policy_map_name
hostname(config-pmap)# 
 
   

where policy_map_name is the name of the policy map. The CLI enters the policy map configuration mode and the prompt changes accordingly.

Step 5 Specify the class map, created in Step 2, that identifies the SMTP traffic. Use the class command to do so, as follows:

hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)# 
 
   

where class_map_name is the name of the class map you created in Step 2. The CLI enters the policy map class configuration mode and the prompt changes accordingly.

Step 6 Do one of the following:

a. To enable extended SMTP application inspection, enter the following command:

hostname(config-pmap-c)# inspect esmtp
 
   

b. To enable SMTP application inspection, enter the following command:

hostname(config-pmap-c)# inspect smtp
 
   

Note For information about the differences between the inspect smtp and inspect esmtp commands, see the "SMTP and Extended SMTP Inspection Overview" section.


Step 7 Use the service-policy command to apply the policy map globally or to a specific interface, as follows:

hostname(config-pmap-c)# service-policy policy_map_name [global | interface interface_ID]
hostname(config)#
 
   

where policy_map_name is the policy map you configured in Step 4. If you want to apply the policy map to traffic on all the interfaces, use the global option. If you want to apply the policy map to traffic on a specific interface, use the interface interface_ID option, where interface_ID is the name assigned to the interface with the nameif command.

The FWSM begins inspecting SMTP traffic, as specified.


Example 20-15 Configuring and Enabling ESMTP Inspection

hostname(config)# class-map smtp_port
hostname(config-cmap)# match port tcp eq 25
hostname(config-cmap)# policy-map sample_policy
hostname(config-pmap)# class smtp_port
hostname(config-pmap-c)# inspect esmtp
hostname(config-pmap-c)# service-policy sample_policy interface outside
hostname(config)#
 
   

SNMP Inspection

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

SNMP Inspection Overview

Enabling and Configuring SNMP Application Inspection

SNMP Inspection Overview

SNMP application inspection lets you restrict SNMP traffic to a specific version of SNMP. Earlier versions of SNMP are less secure; therefore, denying certain SNMP versions may be required by your security policy. The FWSM can deny SNMP versions 1, 2, 2c, or 3. You control the versions permitted by using the deny version command in SNMP map configuration mode.

Enabling and Configuring SNMP Application Inspection

To change the default configuration for SNMP inspection, perform the following steps:


Step 1 Determine the ports that network devices behind the FWSM listen to for SNMP traffic. The default ports are TCP ports 161 and 162.

Step 2 Create a class map or modify an existing class map to identify SNMP traffic. Use the class-map command to do so, as follows:

hostname(config)# class-map class_map_name
hostname(config-cmap)#
 
   

where class_map_name is the name of the traffic class. When you enter the class-map command, the CLI enters class map configuration mode.

Step 3 Use a match command to identify traffic sent to the SNMP ports you determined in Step 1.

If you need to assign a range of contiguous ports, use the range keyword, as in the following example:

hostname(config-cmap)# match port tcp range begin_port_number end_port_number
 
   

where begin_port_number is the lowest port in the range of SNMP ports and end_port_number is the highest port.


Tip To identify two or more non-contiguous ports, enter the access-list extended command and define an ACE to match each port. Then, rather than the match port command, use the match access-list command to associate the access list with the SNMP traffic class.


Step 4 Create an SNMP map that will contain the parameters of SNMP inspection. Use the snmp-map command to do so, as follows:

hostname(config-cmap)# snmp-map map_name
hostname(config-snmp-map)#
 
   

where map_name is the name of the SNMP map. The CLI enters SNMP map configuration mode.

Step 5 Specify the versions of SNMP permitted by the SNMP map. To do so, use the deny version command to disallow the versions that you do not want to permit, as follows:

hostname(config-snmp-map)# deny version version
hostname(config-snmp-map)#
 
   

where version with an SNMP version that you want to restrict. Valid values of version are 1, 2, 2c, and 3. You can enter as many deny version commands as needed.

Step 6 Create a policy map or modify an existing policy map that you want to use to apply the SNMP inspection engine to the SNMP traffic. To do so, use the policy-map command, as follows:

hostname(config-cmap)# policy-map policy_map_name
hostname(config-pmap)# 
 
   

where policy_map_name is the name of the policy map. The CLI enters the policy map configuration mode and the prompt changes accordingly.

Step 7 Specify the class map, created in Step 2, that identifies the SNMP traffic. Use the class command to do so, as follows:

hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)# 
 
   

where class_map_name is the name of the class map you created in Step 2. The CLI enters the policy map class configuration mode and the prompt changes accordingly.

Step 8 Enable SNMP application inspection. To do so, use the inspect snmp command, as follows:

hostname(config-pmap-c)# inspect snmp snmp_map_name
hostname(config-pmap-c)#
 
   

where snmp_map_name is the SNMP map that you created in Step 4.

Step 9 Use the service-policy command to apply the policy map globally or to a specific interface, as follows:

hostname(config-pmap-c)# service-policy policy_map_name [global | interface interface_ID]
hostname(config)#
 
   

where policy_map_name is the policy map you configured in Step 6. If you want to apply the policy map to traffic on all the interfaces, use the global option. If you want to apply the policy map to traffic on a specific interface, use the interface interface_ID option, where interface_ID is the name assigned to the interface with the nameif command.

The FWSM begins inspecting SNMP traffic, as specified.


Example 20-16 enables SNMP application inspection on traffic sent to TCP ports 161 and 162 from the outside interface:

Example 20-16 Configuring SNMP Application Inspection

hostname(config)# class-map snmp_port
hostname(config-cmap)# match port tcp range 161 162
hostname(config-cmap)# snmp-map sample_map
hostname(config-snmp-map)# deny version 1
hostname(config-snmp-map)# deny version 2
hostname(config-snmp-map)# policy-map sample_policy 
hostname(config-pmap)# class snmp_port
hostname(config-pmap-c)# inspect snmp sample_map
hostname(config-pmap-c)# service-policy sample_policy interface outside
hostname(config)#
 
   

SQL*Net Inspection

SQL*Net inspection is enabled by default.

For information about SQL*Net inspection, see the inspect sqlnet command page in the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.

Sun RPC Inspection

This section describes how to enable Sun RPC application inspection, change the default port configuration, and manage the Sun RPC service table. This section includes the following topics:

Sun RPC Inspection Overview

Enabling and Configuring Sun RPC Inspection

Managing Sun RPC Services

Verifying and Monitoring Sun RPC Inspection

Sun RPC Inspection Overview

To enable Sun RPC application inspection or to change the ports to which the FWSM listens, use the inspect sunrpc command in policy map class configuration mode, which is accessible by using the class command within policy map configuration mode. To remove the configuration, use the no form of this command.

The inspect sunrpc command enables or disables application inspection for the Sun RPC protocol. Sun RPC is used by NFS and NIS. Sun RPC services can run on any port. When a client attempts to access an Sun RPC service on a server, it must learn the port that service is running on. It does this by querying the port mapper process, usually rpcbind, on the well-known port of 111.

The client sends the Sun RPC program number of the service and the port mapper process responds with the port number of the service. The client sends its Sun RPC queries to the server, specifying the port identified by the port mapper process. When the server replies, the FWSM intercepts this packet and opens both embryonic TCP and UDP connections on that port.


Note Sun RPC Inspection is not supported with the XLATE BYPASS feature because Sun RPC Inspection relies on XLATES for functionality and the XLATE BYPASS feature can prevent Sun RPC Inspection from functioning correctly. For more information about the xlate-bypass command, see the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.



Note NAT or PAT of Sun RPC payload information is not supported.


Enabling and Configuring Sun RPC Inspection

Sun RPC inspection is enabled by default.


Note To enable or configure Sun RPC inspection over UDP, you do not have to define a separate traffic class or a new policy map. You simply add the inspect sunrpc command into a policy map whose traffic class is defined by the default traffic class. An example of this configuration is shown in Example 20-18.


To enable Sun RPC inspection or change the default port used for receiving Sun RPC traffic using TCP, perform the following steps:


Step 1 Determine the port or ports that the port mapper process listens to. While this is most often port 111, it can differ between operating systems and implementations.

Step 2 Create a class map or modify an existing class map to identify Sun RPC traffic. Use the class-map command to do so, as follows:

hostname(config)# class-map class_map_name
hostname(config-cmap)#
 
   

where class_map_name is the name of the traffic class. When you enter the class-map command, the CLI enters class map configuration mode.

Step 3 Use a match command to identify traffic sent to the port or ports that you determined in Step 1.

If the port mapper process listens to a single port, you can use the match port command to identify traffic sent to that port, as follows:

hostname(config-cmap)# match port tcp eq port_number
 
   

where port_number is the port to which the port mapper process listens. If you need to assign a range of contiguous ports, use the range keyword, as in the following example:

hostname(config-cmap)# match port tcp range begin_port_number end_port_number
 
   

Tip To identify two or more non-contiguous ports, enter the access-list extended command and define an ACE to match each port. Then, rather than the match port command, use the match access-list command to associate the access list with the Sun RPC traffic class.


Step 4 Create a policy map or modify an existing policy map that you want to use to apply the Sun RPC inspection engine to the Sun RPC traffic. To do so, use the policy-map command, as follows:

hostname(config-cmap)# policy-map policy_map_name
hostname(config-pmap)# 
 
   

where policy_map_name is the name of the policy map. The CLI enters the policy map configuration mode and the prompt changes accordingly.

Step 5 Specify the class map, created in Step 2, that identifies the Sun RPC traffic. Use the class command to do so, as follows:

hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)# 
 
   

where class_map_name is the name of the class map you created in Step 2. The CLI enters the policy map class configuration mode and the prompt changes accordingly.

Step 6 Enable Sun RPC application inspection. To do so, enter the following command:

hostname(config-pmap-c)# inspect sunrpc
hostname(config-pmap-c)#
 
   

Step 7 Use the service-policy command to apply the policy map globally or to a specific interface, as follows:

hostname(config-pmap-c)# service-policy policy_map_name [global | interface interface_ID]
hostname(config)#
 
   

where policy_map_name is the policy map you configured in Step 4. If you want to apply the policy map to traffic on all the interfaces, use the global option. If you want to apply the policy map to traffic on a specific interface, use the interface interface_ID option, where interface_ID is the name assigned to the interface with the nameif command.

The FWSM begins inspecting Sun RPC traffic, as specified.


Example 20-17 Enabling and Configuring TCP-based Sun RPC Inspection

The following example enables Sun RPC application inspection on traffic sent to TCP port 111 from the outside interface:

hostname(config)# class-map sunrpc_port
hostname(config-cmap)# match port tcp eq 111
hostname(config-cmap)# policy-map sample_policy
hostname(config-pmap)# class sunrpc_port
hostname(config-pmap-c)# inspect sunrpc
hostname(config-pmap-c)# service-policy sample_policy interface outside
hostname(config)#
 
   

Example 20-18 enables Sun RPC over UDP, which you do by adding the inspect sunrpc command to a policy map that applies actions to the default traffic class:

Example 20-18 Enabling and Configuring UDP-based Sun RPC Inspection

hostname(config)# policy-map asa_global_fw_policy
hostname(config-pmap)# class inspection_default
hostname(config-pmap-c)# inspect sunrpc
hostname(config-pmap-c)#
 
   

Managing Sun RPC Services

The FWSM maintains a Sun RPC services table to control established Sun RPC sessions. To create entries in the Sun RPC services table, use the sunrpc-server command in global configuration mode.

You can use the sunrpc-server command to specify the timeout after which the FWSM closes a pinhole opened by Sun RPC application inspection. For example, to create a timeout of 30 minutes for the Sun RPC server with the IP address 192.168.100.2, enter the following command:

hostname(config)# sunrpc-server inside 192.168.100.2 255.255.255.255 service 100003 
protocol tcp 111 timeout 00:30:00
 
   

This command specifies that the pinhole that was opened by Sun RPC application inspection will be closed after 30 minutes. In this example, the Sun RPC server is on the inside interface using TCP port 111. You can also specify UDP, a different port number, or a range of ports. To specify a range of ports, separate the starting and ending port numbers in the range with a hyphen (for example, 111-113).

The service type identifies the mapping between a specific service type and the port number used for the service. To determine the service type, which in this example is 100003, use the sunrpcinfo command at the UNIX or Linux command line on the Sun RPC server machine.

To clear the Sun RPC configuration, enter the following command.

hostname(config)# clear configure sunrpc-server
 
   

This removes the configuration performed using the sunrpc-server command. The sunrpc-server command allows pinholes to be created with a specified timeout.

To clear the active Sun RPC services, enter the following command:

hostname(config)# clear sunrpc-server active
 
   

This clears the pinholes open because Sun RPC application inspection enabled the traffic based on service requests to the port mapper service.


Note FWSM does not support fragmented Sun RPC traffic at the application layer. Pinholes are opened only for ports that appear in the first fragment.


Verifying and Monitoring Sun RPC Inspection

The sample output in this section is for a Sun RPC server with an IP address of 192.168.100.2 on the inside interface and a Sun RPC client with an IP address of 209.168.200.5 on the outside interface.

To view information about the current Sun RPC connections, enter the show conn command. The following is sample output from the show conn command:

hostname# show conn
15 in use, 21 most used
UDP out 209.165.200.5:800 in 192.168.100.2:2049 idle 0:00:04 flags -
UDP out 209.165.200.5:714 in 192.168.100.2:111 idle 0:00:04 flags -
UDP out 209.165.200.5:712 in 192.168.100.2:647 idle 0:00:05 flags -
UDP out 192.168.100.2:0 in 209.165.200.5:714 idle 0:00:05 flags i
hostname(config)#
 
   

To display the information about the Sun RPC service table configuration, enter the show running-config sunrpc-server command. The following is sample output from the show running-config sunrpc-server command:

hostname(config)# show running-config sunrpc-server
sunrpc-server inside 192.168.100.2 255.255.255.255 service 100003 protocol UDP port 111 
timeout 0:30:00
sunrpc-server inside 192.168.100.2 255.255.255.255 service 100005 protocol UDP port 111 
timeout 0:30:00
 
   

This output shows that a timeout interval of 30 minutes is configured on UDP port 111 for the Sun RPC server with the IP address 192.168.100.2 on the inside interface.

To display the pinholes open for Sun RPC services, enter the show sunrpc-server active command. The following is sample output from show sunrpc-server active command:

hostname# show sunrpc-server active
LOCAL FOREIGN SERVICE TIMEOUT
-----------------------------------------------
1 209.165.200.5/0 192.168.100.2/2049 100003 0:30:00
2 209.165.200.5/0 192.168.100.2/2049 100003 0:30:00
3 209.165.200.5/0 192.168.100.2/647 100005 0:30:00
4 209.165.200.5/0 192.168.100.2/650 100005 0:30:00
 
   

The entry in the LOCAL column shows the IP address of the client or server on the inside interface, while the value in the FOREIGN column shows the IP address of the client or server on the outside interface.

To view information about the Sun RPC services running on a Sun RPC server, enter the rpcinfo -p command from the Linux or UNIX server command line. The following is sample output from the rpcinfo -p command:

sunrpcserver:~ # rpcinfo -p 
program vers proto port 
100000 2 tcp 111 portmapper 
100000 2 udp 111 portmapper 
100024 1 udp 632 status 
100024 1 tcp 635 status 
100003 2 udp 2049 nfs 
100003 3 udp 2049 nfs 
100003 2 tcp 2049 nfs 
100003 3 tcp 2049 nfs 
100021 1 udp 32771 nlockmgr 
100021 3 udp 32771 nlockmgr 
100021 4 udp 32771 nlockmgr 
100021 1 tcp 32852 nlockmgr 
100021 3 tcp 32852 nlockmgr 
100021 4 tcp 32852 nlockmgr 
100005 1 udp 647 mountd 
100005 1 tcp 650 mountd 
100005 2 udp 647 mountd 
100005 2 tcp 650 mountd 
100005 3 udp 647 mountd 
100005 3 tcp 650 mountd
 
   

In this output, port 647 corresponds to the mountd daemon running over UDP. The mountd process would more commonly be using port 32780, but it uses TCP port 650 in this example.

TFTP Inspection

TFTP inspection is enabled by default.

For information about TFTP inspection, see the inspect tftp command page in the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.

XDMCP Inspection

XDMCP inspection is enabled by default; however, the XDMCP inspection engine is dependent upon proper configuration of the established command.

For information about XDMCP inspection, see the established and inspect pptp and command pages in the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.