-
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide, 4.0
-
About This Guide
-
Quick Start Steps
-
Getting Started and General Information
-
Introduction to the Firewall Services Module
-
Configuring the Switch for the Firewall Services Module
-
Getting Started
-
Managing Security Contexts
-
Configuring the Firewall Mode
-
Configuring Interface Parameters
-
Configuring Basic Settings
-
Configuring IP Routing and DHCP Services
-
Configuring Multicast Routing
-
Configuring IPv6
-
Configuring AAA Servers and the Local Database
-
Configuring Certificates
-
Identifying Traffic with Access Lists
-
Configuring Failover
-
- Configuring the Security Policy
- System Administration
- Reference
-
Glossary
-
Index
-
Feedback
Table Of Contents
Applying Application Layer Protocol Inspection
When to Use Application Protocol Inspection
Configuring Application Inspection
Enabling and Configuring CTIQBE Inspection
Verifying and Monitoring CTIQBE Inspection
Configuring a DCERPC Inspection Policy Map for Additional Inspection Control
How DNS Application Inspection Works
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
Verifying and Monitoring DNS Inspection
Configuring an ESMTP Inspection Policy Map for Additional Inspection Control
The request-command deny Command
Verifying and Monitoring FTP Inspection
Enabling and Configuring GTP Inspection
Verifying and Monitoring GTP Inspection
Topologies Requiring H.225 Configuration
Enabling and Configuring H.323 Inspection
Configuring H.323 and H.225 Timeout Values
Verifying and Monitoring H.323 Inspection
Configuring an HTTP Inspection Policy Map for Additional Inspection Control
Configuring MGCP Call Agents and Gateways
Configuring and Enabling MGCP Inspection
Configuring MGCP Timeout Values
Verifying and Monitoring MGCP Inspection
Enabling and Configuring RTSP Inspection
Configuring a SIP Inspection Policy Map for Additional Inspection Control
Configuring SIP Timeout Values
Verifying and Monitoring SIP Inspection
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
Enabling and Configuring SNMP Application Inspection
Enabling and Configuring Sun RPC Inspection
Verifying and Monitoring Sun RPC Inspection
Applying Application Layer Protocol Inspection
This chapter describes how to configure application layer protocol inspection. Inspection engines are required for services that embed IP addressing information in the user data packet or that open secondary channels on dynamically assigned ports. These protocols require the FWSM to perform a deep packet inspection instead of passing the packet through the accelerated path (see the "Stateful Inspection Overview" section on page 1-9 for more information about the accelerated path). As a result, inspection engines can affect overall throughput.
Several common inspection engines are enabled on the FWSM by default, but you might need to enable others depending on your network. This chapter includes the following sections:
•
Configuring Application Inspection
•
Inspection Engine Overview
This section includes the following topics:
•
When to Use Application Protocol Inspection
When a user establishes a connection, the FWSM checks the packet against access lists, creates an address translation, and creates an entry for the session in the accelerated path, so that further packets can bypass time-consuming checks. However, the accelerated path relies on predictable port numbers and does not perform address translations inside a packet.
Many protocols open secondary TCP or UDP ports. The initial session on a well-known port is used to negotiate dynamically-assigned port numbers.
Other applications embed an IP address in the packet that needs to match the source address that is normally translated when it goes through the FWSM.
If you use applications like these, then you need to enable application inspection.
When you enable application inspection for a service that embeds IP addresses, the FWSM translates embedded addresses and updates any checksum or other fields that are affected by the translation.
When you enable application inspection for a service that uses dynamically assigned ports, the FWSM monitors sessions to identify the dynamic port assignments, and permits data exchange on these ports for the duration of the specific session.
How Inspection Engines Work
As illustrated in Figure 21-2, the FWSM uses three databases for its basic operation:
•
•
•
Figure 21-1 How Inspection Engines Work
In Figure 21-2, operations are numbered in the order they occur, and are described as follows:
1.
2.
3.
4.
5.
6.
7.
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
See the following limitations for application protocol inspection:
•
•
•
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.
•
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:
–
–
–
•
Default Inspection Policy
By default, the configuration includes a policy that matches all default application inspection traffic and applies inspection to the traffic on all interfaces (a global policy). Default application inspection traffic includes traffic to the default ports for each protocol. You can only apply one global policy, so if you want to alter the global policy, for example, to apply inspection to non-standard ports, or to add inspections that are not enabled by default, you need to either edit the default policy or disable it and apply a new one.
Table 21-1 lists all inspections supported, the default ports used in the default class map, and the inspection engines that are on by default, shown in bold. This table also notes any NAT limitations.
Table 21-1 Supported Application Inspection Engines
CTIQBE
TCP/2748
—
—
—
DCERPC
TCP/135
—
—
Supports the map and lookup operations of the EPM for clients.
DNS over UDP
UDP/53
Only forward NAT.
No NAT support is available for name resolution through WINS.
RFC 1123
No PTR records are changed.
Default maximum packet length is 512 bytes.
ESMTP
TCP/25
—
RFC 821, 1123
—
FTP
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
UDP/3386 (V0)
UDP/2123 (V1)No NAT or PAT.
—
Requires a special license.
H.323
TCP/1720 UDP/1718
UDP (RAS) 1718-1719No NAT on same security interfaces.
No static PAT.
ITU-T H.323, H.245, H225.0, Q.931, Q.932
By default, both RAS and H.225 inspection are enabled.
HTTP
TCP/80
—
RFC 2616
Beware of MTU limitations stripping ActiveX and Java. If the MTU is too small to allow the Java or ActiveX tag to be included in one packet, stripping may not occur.
ICMP
—
—
—
All ICMP traffic is matched in the default class map.
ICMP ERROR
—
—
—
All ICMP traffic is matched in the default class map.
ILS (LDAP)
TCP/389
No PAT.
—
—
MGCP
UDP/2427, 2727
—
RFC 2705bis-05
—
NetBIOS Datagram Service / UDP
UDP/138
—
—
NetBIOS Name Service / UDP
UDP/137
No NAT
No PAT
—
No WINS support.
PPTP
TCP/1723
—
RFC 2637
—
RSH
TCP/514
No PAT
Berkeley UNIX
—
RTSP
TCP/554
No outside NAT.
RFC 2326, 2327, 1889
No handling for HTTP cloaking.
SIP
TCP/5060
UDP/5060No outside NAT.
No NAT on same security interfaces.
RFC 3261
—
SKINNY (SCCP)
TCP/2000
No outside NAT.
No NAT on same security interfaces.
—
Does not handle TFTP uploaded Cisco IP Phone configurations under certain circumstances.
SMTP
TCP/25
—
RFC 821, 1123
—
SNMP
UDP/161, 162
No NAT or PAT.
RFC 1155, 1157, 1212, 1213, 1215
v.2 RFC 1902-1908; v.3 RFC 2570-2580.
SQL*Net
TCP/1521
—
—
v.1 and v.2.
SunRPC
UDP/111 TCP/111
No PAT.
Payload not NATed.
—
The default class map includes UDP port 111; if you want to enable Sun RPC inspection for TCP port 111, you need to create a new class map that matches TCP port 111, add the class to the policy, and then apply the inspect sunrpc command to that class.
TFTP
TCP/69 UDP/69
Payload not NATed.
RFC 1530
—
WAAS
TCP
—
—
Enables the TCP option 33 parsing.
XDCMP
UDP/177
No NAT or PAT.
—
—
1 Inspection engines that are enabled by default for the default port are in bold.
2 The FWSM is in compliance with these standards, but it does not enforce compliance on packets being inspected. For example, FTP commands are supposed to be in a particular order, but the FWSM does not enforce the order.
The default policy configuration includes the following commands:
class-map inspection_defaultmatch default-inspection-trafficpolicy-map global_policyclass inspection_defaultinspect dns maximum-length 512inspect ftpinspect h323 h225inspect h323 rasinspect netbiosinspect rshinspect skinnyinspect sqlnetinspect sunrpcinspect tftpinspect sipinspect xdmcpservice-policy global_policy globalConfiguring Application Inspection
This feature uses Modular Policy Framework, so that implementing application inspection consists of the following:
1.
2.
For some applications, you can perform special actions when you enable inspection.
3.
See Chapter 19, "Using Modular Policy Framework," for more information about Modular Policy Framework.
Inspection is enabled by default for some applications. See the "Default Inspection Policy" section section for more information. Use this section to modify your inspection policy.
To configure application inspection, perform the following steps:
Step 1
The default Layer 3/4 class map for through traffic is called "inspection_default." It matches traffic using a special match command, match default-inspection-traffic, to match the default ports for each application protocol.
You can specify a match access-list command along with the match default-inspection-traffic command to narrow the matched traffic to specific IP addresses. Because the match default-inspection-traffic command specifies the ports to match, any ports in the access list are ignored.
If you want to match non-standard ports, then you need to create a new class map for the non-standard ports. See the "Default Inspection Policy" section for the standard ports for each inspection engine. You can combine multiple class maps in the same policy if desired, so you can create one class map to match certain traffic, and another to match different traffic. However, if traffic matches a class map that contains an inspection command, and then matches another class map that also has an inspection command, only the first matching class is used. For example, SNMP matches the inspection_default class. To enable SNMP inspection, enable SNMP inspection for the default class in Step 5. Do not add another class that matches SNMP.
For example, to limit inspection to traffic from 10.1.1.0 to 192.168.1.0 using the default class map, enter the following commands:
hostname(config)# access-list inspect extended permit ip 10.1.1.0 255.255.255.0 192.168.1.0 255.255.255.0hostname(config)# class-map inspection_defaulthostname(config-cmap)# match access-list inspectView the entire class map using the following command:
hostname(config-cmap)# show running-config class-map inspection_default!class-map inspection_defaultmatch default-inspection-trafficmatch access-list inspect!To inspect FTP traffic on port 21 as well as 1056 (a non-standard port), create an access list that specifies the ports, and assign it to a new class map:
hostname(config)# access-list ftp_inspect extended permit tcp any any eq 21hostname(config)# access-list ftp_inspect extended permit tcp any any eq 1056hostname(config)# class-map new_inspectionhostname(config-cmap)# match access-list ftp_inspectStep 2
•
•
•
•
•
•
•
•
•
Step 3
hostname(config)# policy-map namehostname(config-pmap)#The default policy map is called "global_policy." This policy map includes the default inspections listed in the "Default Inspection Policy" section. If you want to modify the default policy (for example, to add or delete an inspection, or to identify an additional class map for your actions), then enter global_policy as the name.
Step 4
hostname(config-pmap)# class class_map_namehostname(config-pmap-c)#If you are editing the default policy map, it includes the inspection_default class map. You can edit the actions for this class by entering inspection_default as the name. To add an additional class map to this policy map, identify a different name. You can combine multiple class maps in the same policy if desired, so you can create one class map to match certain traffic, and another to match different traffic. However, if traffic matches a class map that contains an inspection command, and then matches another class map that also has an inspection command, only the first matching class is used. For example, SNMP matches the inspection_default class map.To enable SNMP inspection, enable SNMP inspection for the default class in Step 5. Do not add another class that matches SNMP.
Step 5
hostname(config-pmap-c)# inspect protocolTable 21-2 lists the protocol values.
Table 21-2 Protocol Keywords
ctiqbe
—
dcerpc [policy_map_name]
If you added a DCERPC inspection policy map according to "Configuring a DCERPC Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
dns [map_name]
—
esmtp [policy_map_name]
If you added an ESMTP inspection policy map according to "Configuring an ESMTP Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
ftp [strict [map_name]]
Use the strict keyword to increase the security of protected networks by preventing web browsers from sending embedded commands in FTP requests. See the "Using the strict Option" section for more information.
If you added an FTP application map according to "The request-command deny Command" section, identify the map name in this command.
gtp [map_name]
If you added a GTP application map according to the "GTP Maps and Commands" section, identify the map name in this command.
h323 h225 [map_name]
If you added an H.225 application map according to "H.225 Map Commands" section, identify the map name in this command.
h323 ras [map_name]
—
http [policy_map_name]
If you added an HTTP inspection policy map according to the "Configuring an HTTP Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
icmp
—
icmp error
—
ils
—
mgcp [map_name]
If you added an MGCP inspection policy map according to "Configuring and Enabling MGCP Inspection" section, identify the map name in this command.
netbios
—
pptp
—
rsh
—
rtsp
—
sip [policy_map_name]
If you added a SIP inspection policy map according to "Configuring a SIP Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
skinny
—
snmp [map_name]
If you added an SNMP application map according to "Enabling and Configuring SNMP Application Inspection" section, identify the map name in this command.
sqlnet
—
sunrpc
The default class map includes UDP port 111; if you want to enable Sun RPC inspection for TCP port 111, you need to create a new class map that matches TCP port 111, add the class to the policy, and then apply the inspect sunrpc command to that class.
tftp
—
waas
—
xdmcp
—
Step 6
hostname(config)# service-policy policymap_name {global | interface interface_name}Where global applies the policy map to all interfaces, and interface applies the policy to one interface. By default, the default policy map, "global_policy," is applied globally. Only one global policy is allowed. You can override the global policy on an interface by applying a service policy to that interface. You can only apply one policy map to each interface.
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
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:
•
•
•
The following summarizes special considerations when using CTIQBE application inspection in specific scenarios:
•
•
•
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
hostname(config)# class-map class_map_namehostname(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
hostname(config-cmap)# match port tcp eq 2748Step 3
hostname(config-cmap)# policy-map policy_map_namehostname(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
hostname(config-pmap)# class class_map_namehostname(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
hostname(config-pmap-c)# inspect ctiqbeStep 6
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 21-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_porthostname(config-cmap)# match port tcp eq 2748hostname(config-cmap)# policy-map sample_policyhostname(config-pmap)# class ctiqbe_porthostname(config-pmap-c)# inspect ctiqbehostname(config-pmap-c)# service-policy sample_policy interface outsidehostname(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 209.165.201.2, where TCP port 2748 is the Cisco CallManager. The heartbeat interval for the session is 120 seconds.
hostname# # show ctiqbeTotal: 1LOCAL FOREIGN STATE HEARTBEAT---------------------------------------------------------------1 10.0.0.99/1117 209.165.201.2/2748 1 120----------------------------------------------RTP/RTCP: PAT xlates: mapped to 209.165.201.2(1028 - 1029)----------------------------------------------MEDIA: Device ID 27 Call ID 0Foreign 209.165.201.2 (1028 - 1029)Local 209.165.201.3 (26822 - 26823)----------------------------------------------The CTI device has already registered with the CallManager. The device internal address and RTP listening port is PATed to 209.165.201.2 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 209.165.201.3. 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 debug3 in use, 3 most usedFlags: D - DNS, d - dump, I - identity, i - inside, n - no random,r - portmap, s - staticTCP PAT from inside:10.0.0.99/1117 to outside:209.165.201.2/1025 flags ri idle 0:00:22 timeout 0:00:30UDP PAT from inside:10.0.0.99/16908 to outside:209.165.201.2/1028 flags ri idle 0:00:00 timeout 0:04:10UDP PAT from inside:10.0.0.99/16909 to outside:209.165.201.2/1029 flags ri idle 0:00:23 timeout 0:04:10The 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 ctiqbe1 in use, 10 most usedhostname# show conn state ctiqbe detail1 in use, 10 most usedFlags: 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 - upCTIQBE Sample Configurations
The following figure shows a sample configuration for a single transparent firewall for Cisco IP SoftPhone (Figure 21-2).
Figure 21-2 Single Transparent Firewall for Cisco IP SoftPhone (Virtual Conference)
See the following configuration for this example:
firewall transparent!interface Vlan50nameif insidebridge-group 1security-level 100!interface Vlan100nameif outsidebridge-group 1security-level 0!interface BVI1ip address 10.0.0.30 255.0.0.0!access-list voice extended permit tcp any any eq ctiqbeaccess-list voice extended permit tcp any any eq 1503!access-group voice in interface insideaccess-group voice in interface outside!policy-map global_policyclass inspection_defaultinspect ctiqbe!
Note
The following figure shows a sample configuration for a single transparent firewall for Cisco IP SoftPhone with NetMeeting enabled (Figure 21-3). Cisco IP SoftPhone is configured with the collaboration setting of NetMeeting.
Figure 21-3 Single Transparent Firewall for Cisco IP SoftPhone (Virtual Conference) with NetMeeting
See the following configuration for this example:
firewall transparent!interface Vlan50nameif insidebridge-group 1security-level 100!interface Vlan100nameif outsidebridge-group 1security-level 0!interface BVI1ip address 10.0.0.30 255.0.0.0!access-list voice extended permit tcp any any eq ctiqbeaccess-list voice extended permit tcp any any eq h323access-list voice extended permit tcp any any eq 1503!access-group voice in interface insideaccess-group voice in interface outside!policy-map global_policyclass inspection_defaultinspect ctiqbe
!
Note
The following is sample output for the show conn detail command:
hostname# show conn detail25 in use, 33 most usedFlags: A - awaiting inside ACK to SYN,a - awaiting outside ACK to SYNB - 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 - upNetwork Processor 1 connectionTCP out 10.0.0.101:2748 in 10.0.0.23:3598 idle 0:00:09 Bytes 103065 FLAGS - UOIUDP out 10.0.0.21:30504 in 10.0.0.23:3650 idle 0:00:00 Bytes 4810406FLAGS - CUDP out 10.0.0.21:1436 in 10.0.0.23:19972 idle 0:00:00 Bytes 4813240FLAGS - CTCP out 10.0.0.21:1437 in 10.0.0.23:1720 idle 0:07:04 Bytes 1027 FLAGS - UBOIhUDP out 10.0.0.21:49608 in 10.0.0.23:49608 idle 0:00:10 Bytes 241836FLAGS - HUDP out 10.0.0.21:49609 in 10.0.0.23:49609 idle 0:00:01 Bytes 17480FLAGS - HTCP out 10.0.0.21:1440 in 10.0.0.23:1503 idle 0:06:58 Bytes 4488 FLAGS - UBOITCP out 10.0.0.21:1441 in 10.0.0.23:1503 idle 0:04:50 Bytes 17888 FLAGS - UBOITCP out 10.0.0.21:1442 in 10.0.0.23:1503 idle 0:04:50 Bytes 471135 FLAGS - UBOINetwork Processor 2 connectionsMulticast sessions:Network Processor 1 connectionsNetwork Processor 2 connectionsIPv6 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. Because a client may attempt multiple connections to the server port returned by EPM, multiple use of pinholes are allowed, which have user configurable timeouts.
Configuring a DCERPC Inspection Policy Map for Additional Inspection Control
To specify additional DCERPC inspection parameters, create a DCERPC inspection policy map. You can then apply the inspection policy map when you enable DCERPC inspection according to the "Configuring Application Inspection" section.
To create a DCERPC inspection policy map, perform the following steps:
Step 1
hostname(config)# policy-map type inspect dcerpc policy_map_namehostname(config-pmap)#Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration mode.
Step 2
hostname(config-pmap)# description stringStep 3
a.
hostname(config-pmap)# parametershostname(config-pmap-p)#b.
hostname(config-pmap-p)# timeout pinhole hh:mm:ssWhere the hh:mm:ss argument is the timeout for pinhole connections. Value is between 0:0:1 and 1193:0:0.
c.
hostname(config-pmap-p)# endpoint-mapper [epm-service-only] [lookup-operation [timeout hh:mm:ss]]Where the hh:mm:ss argument is the timeout for pinholes generated from the lookup operation. If no timeout is configured for the lookup operation, the timeout pinhole command or the default is used. The epm-service-only keyword enforces endpoint mapper service during binding so that only its service traffic is processed. The lookup-operation keyword enables the lookup operation of the endpoint mapper service.
The following example shows how to define a DCERPC inspection policy map with the timeout configured for DCERPC pinholes.
hostname(config)# policy-map type inspect dcerpc dcerpc_maphostname(config-pmap)# timeout pinhole 0:10:00hostname(config)# class-map dcerpchostname(config-cmap)# match port tcp eq 135hostname(config)# policy-map global-policyhostname(config-pmap)# class dcerpchostname(config-pmap-c)# inspect dcerpc dcerpc-maphostname(config)# service-policy global-policy globalDNS Inspection
This section describes how to manage DNS application inspection. This section includes the following topics:
•
•
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:
•
Note
•
Note
•
•
•
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:
•
•
In Figure 21-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.201.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 21-2. For configuration instructions for scenarios similar to this one, see the "Configuring DNS Rewrite with Two NAT Zones" section.
Figure 21-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:
•
•
•
•
•
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-addressThe 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
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 dnsThe following example specifies that the address 192.168.100.10 on the inside interface is translated into 209.165.201.5 on the outside interface:
hostname(config)# static (inside,outside) 209.165.200.225 192.168.100.10 dns
Note
Configuring DNS Rewrite with Two NAT Zones
To implement a DNS Rewrite scenario similar to the one shown in Figure 21-4, perform the following steps:
Step 1
hostname(config)# static (inside,outside) mapped-address real-address netmask 255.255.255.255 dnswhere the arguments are as follows:
•
•
•
•
Step 2
hostname(config)# access-list acl-name permit tcp any host mapped-address eq portwhere 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
hostname(config)# access-group acl-name in interface outsideStep 4
Step 5
domain-qualified-hostname. IN A mapped-addresswhere 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 21-4. It assumes DNS inspection is already enabled.
Example 21-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 dnshostname(config)# access-list 101 permit tcp any host 209.165.200.225 eq wwwhostname(config)# access-group 101 in interface outsideThis configuration requires the following A-record on the DNS server:
server.example.com. IN A 209.165.200.225DNS Rewrite with Three NAT Zones
Figure 21-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 21-5 DNS Rewrite with Three NAT Zones
In Figure 21-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:
•
•
•
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.
2.
3.
4.
5.
When a web client on the inside network attempts to access http://server.example.com, the sequence of events is as follows:
1.
2.
3.
4.
a.
static (dmz,outside) 209.165.200.225 192.168.100.10 dnsb.
[outside]:209.165.200.225 --> [dmz]:192.168.100.10
Note
c.
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.
Configuring DNS Rewrite with Three NAT Zones
To enable the NAT policies for the scenario in Figure 21-5, perform the following steps:
Step 1
hostname(config)# static (dmz,outside) mapped-address real-address dnswhere the arguments are as follows:
•
•
•
•
Step 2
hostname(config)# access-list acl-name permit tcp any host mapped-address eq portwhere 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
hostname(config)# access-group acl-name in interface outsideStep 4
Step 5
domain-qualified-hostname. IN A mapped-addresswhere 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 21-5. It assumes DNS inspection is already enabled.
Example 21-3 DNS Rewrite with Three NAT Zones
hostname(config)# static (dmz,outside) 209.165.200.225 192.168.100.10 dnshostname(config)# access-list 101 permit tcp any host 209.165.200.225 eq wwwhostname(config)# access-group 101 in interface outsideThis configuration requires the following A-record on the DNS server:
server.example.com. IN A 209.165.200.225Configuring 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
hostname(config)# class-map class_map_namehostname(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
hostname(config-cmap)# match port udp eq 53Step 3
hostname(config-cmap)# policy-map policy_map_namehostname(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
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
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 21-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_porthostname(config-cmap)# match port udp eq 53hostname(config-cmap)# policy-map sample_policyhostname(config-pmap)# class dns_porthostname(config-pmap-c)# inspect dns maximum-length 1500hostname(config-pmap-c)# service-policy sample_policy interface outsideVerifying and Monitoring DNS Inspection
To view information about the current DNS connections, enter the following command:
hostname# show connFor 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-policyInterface outside:Service-policy: sample_policyClass-map: dns_portInspect: dns maximum-length 1500, packet 0, drop 0, reset-drop 0DNS Guard
When a client sends a DNS request to an external DNS server, only the first response is accepted by the FWSM. All additional responses from other DNS servers are dropped by the FWSM.
After the client issues a DNS request, a dynamic hole allows UDP packets to return from the DNS server. When the FWSM receives a response from the first DNS server, the connection that was created in the accelerated path is dropped so that subsequent responses from other DNS servers are dropped by the FWSM. The UDP DNS connection is deleted immediately rather than marking the connection for deletion.
The FWSM creates a session-lookup key based on the source and destination IP address along with the protocol and the DNS ID instead of the source and destination ports.
If the DNS client and DNS server use TCP for DNS, the connection is cleared like a normal TCP connection.
However, if clients receive DNS responses from multiple DNS servers, you can disable the default DNS behavior on a per context basis. When DNS Guard is disabled, a response from the first DNS server does not delete the connection and the connection is treated as a normal UDP connection.
DNS Guard is enabled by default.
To disable DNS Guard, enter the following commands:
hostname(config)# no dns-guardhostname(config)# show running-config | inc dns-guardno dns-guardhostname(config)#ESMTP Inspection
ESMTP inspection detects attacks, including spam, phising, malformed message attacks, buffer overflow/underflow attacks. It also provides support for application security and protocol conformance, which enforce the sanity of the ESMTP messages as well as detect several attacks, block senders/receivers, and block mail relay.
Configuring an ESMTP Inspection Policy Map for Additional Inspection Control
To specify actions when a message violates a parameter, create an ESMTP inspection policy map. You can then apply the inspection policy map when you enable ESMTP inspection according to the "Configuring Application Inspection" section.
To create an ESMTP inspection policy map, perform the following steps:
Step 1
Step 2
Step 3
hostname(config)# policy-map type inspect esmtp policy_map_namehostname(config-pmap)#Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration mode.
Step 4
hostname(config-pmap)# description stringStep 5
a.
b.
hostname(config-pmap-c)# {[drop [send-protocol-error] | drop-connection [send-protocol-error]| mask | reset] [log] | rate-limit message_rate}Not all options are available for each match or class command. See the CLI help or the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference for the exact options available.
The drop keyword drops all packets that match.
The send-protocol-error keyword sends a protocol error message.
The drop-connection keyword drops the packet and closes the connection.
The mask keyword masks out the matching portion of the packet.
The reset keyword drops the packet, closes the connection, and sends a TCP reset to the server and/or client.
The log keyword, which you can use alone or with one of the other keywords, sends a system log message.
The rate-limit message_rate argument limits the rate of messages.
You can specify multiple class or match commands in the policy map. For information about the order of class and match commands, see the "Defining Actions in an Inspection Policy Map" section on page 19-7.
Step 6
a.
hostname(config-pmap)# parametershostname(config-pmap-p)#b.
hostname(config-pmap-p)# mail-relay domain-name action [drop-connection | log]]Where the drop-connection action closes the connection. The log action sends a system log message when this policy map matches traffic.
c.
hostname(config-pmap-p)# mask-bannerd.
hostname(config-pmap-p)# special-character action [drop-connection | log]]Using this command detects pipe (|), backquote (`) and null characters.
e.
hostname(config-pmap-p)# match body [line] length gt lengthWhere length is the length of the message body or the length of a line in the message body.
f.
hostname(config-pmap-p)# match cmd verb verbWhere verb is any of the following ESMTP commands:
AUTH|DATA|EHLO|ETRN||HELO|HELP|MAIL|NOOP|QUIT|RCPT|RSET|SAML|SOML|VRFYg.
hostname(config-pmap-p)# match cmd RCPT count gt countWhere count is the number of recipient addresses.
h.
hostname(config-pmap-p)# match cmd line length gt lengthWhere length is the command line length.
i.
hostname(config-pmap-p)# match ehlo-reply-parameter extensionsWhere extensions are the ESMTP service extensions sent by the server in response to the EHLO message from the client. These extensions are implemented as a new command or as parameters to an existing command. extensions can be any of the following.
8bitmime|binarymime|checkpoint|dsn|ecode|etrn|others|pipelining|size|vrfyj.
hostname(config-pmap-p)# match header [line] length gt lengthWhere length is the number of characters in the header or line.
k.
hostname(config-pmap-p)# match header to-fields count gt countWhere count is the number of recipients in the to-field of the header.
l.
hostname(config-pmap-p)# match invalid-recipients count gt countWhere count is the number of invalid recipients.
m.
hostname(config-pmap-p)# match mime encoding [7bit|8bit|base64|binary|others| quoted-printable]n.
hostname(config-pmap-p)# match mime filename length gt lengthWhere length is the length of the filename in the range 1 to 1000.
o.
hostname(config-pmap-p)# match mime filetype regex [name | class name]Where name or class name is the regular expression that matches a file type or a class map. The regular expression used to match a class map can select multiple file types.
p.
hostname(config-pmap-p)# match sender-address regex [name | class name]Where name or class name is the regular expression that matches a sender address or a class map. The regular expression used to match a class map can select multiple sender addresses.
q.
hostname(config-pmap-p)# match sender-address length gt lengthWhere length is the number of characters in the sender's address.
The following example shows how to define an ESMTP inspection policy map.
hostname(config)# regex user1 "user1@cisco.com"hostname(config)# regex user2 "user2@cisco.com"hostname(config)# regex user3 "user3@cisco.com"hostname(config)# class-map type regex senders_black_listhostname(config-cmap)# description "Regular expressions to filter out undesired senders"hostname(config-cmap)# match regex user1hostname(config-cmap)# match regex user2hostname(config-cmap)# match regex user3hostname(config)# policy-map type inspect esmtp advanced_esmtp_maphostname(config-pmap)# match sender-address regex class senders_black_listhostname(config-pmap-c)# drop-connection loghostname(config)# policy-map outside_policyhostname(config-pmap)# class inspection_defaulthostname(config-pmap-c)# inspect esmtp advanced_esmtp_maphostname(config)# service-policy outside_policy interface outsideFTP 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
The FTP application inspection inspects the FTP sessions and performs four tasks:
•
•
•
•
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
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
After you enable the strict option on an interface, FTP inspection enforces the following behavior:
•
•
•
Caution
If the strict option is enabled, each ftp command and response sequence is tracked for the following anomalous activity:
•
•
•
•
•
•
•
•
•
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 21-3 lists the FTP commands that you can disallow by using the request-command deny command.
.
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:
•
•
•
To configure FTP inspection, perform the following steps:
Step 1
Step 2
hostname(config)# class-map class_map_namehostname(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
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_1hostname(config)# access-list acl-name any any tcp eq port_number_2hostname(config)# class-map class_map_namehostname(config-cmap)# match access-list acl-nameIf you need to identify a single port, use the match port command, as follows:
hostname(config-cmap)# match port tcp port_numberwhere 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_numberwhere begin_port_number is the lowest port in the range of FTP ports and end_port_number is the highest port.
Step 4
•
•
then create and configure an FTP map. To do so, perform the following steps.
a.
hostname(config-cmap)# ftp-map map_namehostname(config-ftp-map)#where map_name is the name of the FTP map. The CLI enters FTP map configuration mode.
b.
hostname(config-ftp-map)# no mask-syst-replyhostname(config-ftp-map)#
Note
c.
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 21-3 for a list of the FTP commands that you can restrict.
Step 5
hostname(config-cmap)# policy-map policy_map_namehostname(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
hostname(config-pmap)# class class_map_namehostname(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
•
hostname(config-pmap-c)# inspect ftp strict•
hostname(config-pmap-c)# inspect ftp strict ftp_map_name•
hostname(config-pmap-c)# inspect ftpStep 8
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 21-5 Enabling and Configuring Strict FTP Inspection
hostname(config)# class-map ftp_porthostname(config-cmap)# match port tcp eq 21hostname(config-cmap)# ftp-map sample_maphostname(config-ftp-map)# request-command deny put stou appehostname(config-ftp-map)# policy-map sample_policyhostname(config-pmap)# class ftp_porthostname(config-pmap-c)# inspect ftp strict sample_maphostname(config-pmap-c)# service-policy sample_policy interface outsideVerifying and Monitoring FTP Inspection
FTP application inspection generates the following log messages:
•
•
•
•
•
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:
•
•
Note
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 21-6).
Figure 21-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
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:
•
•
•
•
•
•
•
Table 21-4 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.
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
To enable or change GTP configuration, perform the following steps:
Step 1
hostname(config)# access-list acl-name permit {udp | tcp} any any eq portwhere acl-name is the name you assign to the access list and port is the GTP port that the ACE identifies.
Step 2
hostname(config)# class-map class_map_namehostname(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
hostname(config-cmap)# match access-list acl-nameStep 4
a.
hostname(config-cmap)# gtp-map map_namehostname(config-gtp-map)#where map_name is the name of the GTP map. The CLI enters GTP map configuration mode.
b.
Step 5
hostname(config-cmap)# policy-map policy_map_namehostname(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
hostname(config-pmap)# class class_map_namehostname(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
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
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.
Example 21-6 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 21-6 Enabling and Configuring GTP Inspection
hostname(config)# access-list gtp_acl permit udp any any eq 3386hostname(config)# access-list gtp_acl permit udp any any eq 2123hostname(config)# class-map gtp-traffichostname(config-cmap)# match access-list gtp_aclhostname(config-cmap)# gtp-map sample_maphostname(config-gtp-map)# request-queue 300hostname(config-gtp-map)# permit mcc 111 mnc 222hostname(config-gtp-map)# message-length min 20 max 300hostname(config-gtp-map)# drop message 20hostname(config-gtp-map)# tunnel-limit 10000hostname(config)# policy-map sample_policyhostname(config-pmap)# class gtp-traffichostname(config-pmap-c)# inspect gtp sample_maphostname(config)# service-policy sample_policy outsideVerifying 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 statisticsGPRS GTP Statistics:version_not_support 0 msg_too_short 0unknown_msg 0 unexpected_sig_msg 0unexpected_data_msg 0 ie_duplicated 0mandatory_ie_missing 0 mandatory_ie_incorrect 0optional_ie_incorrect 0 ie_unknown 0ie_out_of_order 0 ie_unexpected 0total_forwarded 0 total_dropped 0signalling_msg_dropped 0 data_msg_dropped 0signalling_msg_forwarded 0 data_msg_forwarded 0total created_pdp 0 total deleted_pdp 0total created_pdpmcb 0 total deleted_pdpmcb 0pdp_non_existent 0You 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 detail1 in use, 1 most used, timeout 0:00:00Version TID MS Addr SGSN Addr Idle APNv1 1234567890123425 10.0.1.1 10.0.0.2 0:00:13 gprs.example.comuser_name (IMSI): 214365870921435 MS address: 10.5.1.1primary pdp: Y nsapi: 2sgsn_addr_signal: 10.0.0.2 sgsn_addr_data: 10.0.0.2ggsn_addr_signal: 10.1.1.1 ggsn_addr_data: 10.1.1.1sgsn control teid: 0x000001d1 sgsn data teid: 0x000001d3ggsn control teid: 0x6306ffa0 ggsn data teid: 0x6305f9fcseq_tpdu_up: 0 seq_tpdu_down: 0signal_sequence: 0upstream_signal_flow: 0 upstream_data_flow: 0downstream_signal_flow: 0 downstream_data_flow: 0RAupdate_flow: 0The 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 gsnGGSN 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
hostname(config)# object-group network GSN-pool-namehostname(config)#where GSN-pool-name is the object group name for GGSNs.Step 2
hostname(config)# network-object host IP-addresshostname(config)#where IP-address is the IP address of the host.Step 3
a.
hostname(config)# object-group network SGSN-namehostname(config)#where SGSN-name is the SGSN network object group name.
b.
hostname(config)# network-object host IP-addresshostname(config)#where IP-address is the SGSN.
Step 4
hostname(config)# gtp-map map_namehostname(config-gtp-map)# permit response to-object-group SGSN-name from-object-group GSN-pool-namewhere 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 21-7 Enabling and Configuring GGSN Load Balancing
hostname(config)# object-group network GGSNShostname(config-network)# network-object 10.1.1.0 255.255.255.0hostname(config)# object-group network SGSNShostname(config-network)# network-object hjost 192.168.1.1hostname(config)# gtp-map GTPMAPhostname(config-gtp-map)# permit response to-object-group SGSNS from-object-group GGSNSFor 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
Figure 21-7 shows a sample GTP inspection configuration.
Figure 21-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).
See the following documentation for installation and configuration of the MWAM module on the Cisco Catalyst 6500 Series switch.
http://www.cisco.com/en/US/docs/wireless/mwam/user/guide/install.html
The following 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.
See the following documentation for configuration of load balancing on GGSNs:
http://www.cisco.com/en/US/docs/ios/12_4/12_4y/12_4_22ye/ggsn9_0/cfg/ggsnslb.html
As per Figure 21-6, two GGSNs (GGSN1 and GGSN2) are configured on the MWAM module:
firewall multiple-vlan-interfacesfirewall module 4 vlan-group 1firewall module 10 vlan-group 1firewall vlan-group 1 3-40,44,84,115,119,172,200-202,400-500,800-900mwam module 9 port 1 allowed-vlan 1,3-40,44,84,172,200-202,400-500,800-900mwam module 9 port 2 allowed-vlan 1,3-40,44,84,172,200-202,400-500,800-900mwam module 9 port 3 allowed-vlan 1,3-40,44,84,172,200-202,400-500,800-900ip subnet-zero!no ip domain-lookupip slb timers gtp gsn 40000ip slb probe PING ping!ip slb serverfarm GGSN-POOLnat serverprobe PING!real 10.4.1.32weight 1inservice!real 10.4.1.33weight 1inservice!ip slb serverfarm TGGSN-POOLnat serverprobe PING!real 10.4.1.34faildetect numconns 2inservice!real 10.4.1.35faildetect numconns 2inservice!ip slb vserver GTP-V0virtual 10.2.1.29 udp 3386 service gtpserverfarm GGSN-POOLinservice!ip slb vserver GTP-V1virtual 10.2.1.29 udp 2123 service gtpserverfarm GGSN-POOLinservice!ip slb vserver TGTP-V0virtual 10.2.1.28 udp 3386 service gtpserverfarm TGGSN-POOLinservice!ip slb vserver TGTP-V1virtual 10.2.1.28 udp 2123 service gtpserverfarm TGGSN-POOLinservice!ip slb dfp password 7 13061E010803agent 10.1.1.2 1111 30 0 10agent 10.1.1.3 1111 30 0 10agent 10.1.1.4 1111 30 0 10agent 10.1.1.5 1111 30 0 10!GGSN1 is configured as follows:
hostname# show running configBuilding 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.3service timestamps debug datetime msecservice timestamps log datetime msecno service password-encryptionservice gprs ggsn!hostname GGSN2ADCTX!boot-start-markerboot-end-marker!!no aaa new-model!resource policy!ip subnet-zeroip dfp agent gprsport 1111password ciscoinservice!ip cefno ip domain lookupip domain name cisco.comno ip dhcp use vrf connected!interface GigabitEthernet0/0no ip address!interface GigabitEthernet0/0.1!interface GigabitEthernet0/0.8encapsulation dot1Q 8ip address 10.1.1.2 255.255.255.0no snmp trap link-status!interface Virtual-Template1ip address 10.4.1.32 255.255.255.0encapsulation gtpgprs access-point-list gtp-test!ip local pool localpool1 10.1.1.101 10.1.1.110ip local pool localpool11 10.7.3.3 10.7.3.255ip classlessip route 0.0.0.0 0.0.0.0 10.1.1.1!no ip http server!gprs access-point-list gtp-testaccess-point 1access-point-name sj-gtp.cisco.comip-address-pool local localpool11!control-plane!line con 0line vty 0no loginline vty 1 4loginline vty 5 15login!endGGSN3 is configured as follows:
hostname# show running-configBuilding 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.3service timestamps debug datetime msecservice timestamps log datetime msecno service password-encryptionservice gprs ggsn!hostname GGSN3ADCTX!boot-start-markerboot-end-marker!!no aaa new-model!resource policy!ip subnet-zeroip dfp agent gprsport 1111password ciscoinservice!ip cefno ip domain lookupip domain name cisco.comno ip dhcp use vrf connected!interface GigabitEthernet0/0no ip address!interface GigabitEthernet0/0.3!interface GigabitEthernet0/0.8encapsulation dot1Q 8ip address 10.4.1.3 255.255.255.0no snmp trap link-status!interface Virtual-Template1ip address 10.1.1.33 255.255.255.0encapsulation gtpgprs access-point-list gtp-test!ip local pool localpool2 10.1.1.111 10.1.1.120ip local pool localpool22 10.8.4.4 10.8.4.254ip classlessip route 0.0.0.0 0.0.0.0 10.1.1.1!no ip http server!gprs maximum-pdp-context-allowed 50000gprs qos default-response requestedgprs access-point-list gtp-testaccess-point 1access-point-name sj-gtp.cisco.comip-address-pool local localpool22!control-plane!line con 0line vty 0no loginline vty 1 4loginline vty 5 15login!!endThe FWSM configuration for load balancing the GGSNs is as follows:
FWSM Version 3.2(0)45 <context>!hostname admindomain-name cisco.comenable password 9jNfZuG3TC5tCVH0 encryptedno names!interface Vlan172nameif mgmtsecurity-level 100ip address 172.21.64.35 255.255.255.128 standby 172.21.64.36!interface Vlan5nameif insidesecurity-level 100ip address 10.2.1.41 255.255.255.0 standby 10.2.1.40!interface Vlan9nameif outsidesecurity-level 0ip address 209.165.201.41 255.255.255.0 standby 209.165.201.40!passwd 2KFQnbNIdI.2KYOU encryptedsame-security-traffic permit inter-interfaceobject-group network GGSNS ================================configured object group to define GGSNsnetwork-object host 10.4.1.32network-object host 10.4.1.33object-group network SGSNS =================================configured object group to define SGSNsnetwork-object host 10.5.1.1object-group network serversnetwork-object 10.2.1.0 255.255.255.0network-object host 10.6.1.25network-object host 10.6.1.26network-object host 10.6.1.27network-object host 10.4.1.32network-object host 10.4.1.33object-group network clientsnetwork-object 10.6.1.0 255.255.255.0network-object host 10.5.1.1access-list gtpacl extended permit udp any any eq 2123access-list gtpacl extended permit udp any any eq 3386access-list gtpacl extended permit icmp any anyaccess-list gtpacl extended permit udp any anyaccess-list gtpacl extended permit tcp any any eq wwwaccess-list gtpacl extended permit tcp any any eq ftpaccess-list gtpacl extended permit tcp any any eq telnetaccess-list gtpacl extended permit tcp any any eq sshaccess-list 112 extended permit tcp object-group servers object-group clients eq wwwaccess-list 112 extended permit tcp object-group servers object-group clients eq httpsaccess-list 112 extended permit tcp object-group servers object-group clients eq ftpaccess-list 112 extended permit tcp object-group servers object-group clients eq telnetaccess-list 112 extended permit udp object-group servers object-group clients eq 3386access-list 112 extended permit udp object-group servers object-group clients eq 2123access-list 112 extended permit tcp object-group servers object-group clients eq ssh!gtp-map GTPMAP ============================================================configured GTP map to include the permit response clipermit response to-object-group SGSNS from-object-group GGSNSpermit errors!pager lines 24logging enablelogging timestamplogging buffered debuggingmtu mgmt 1500mtu inside 1500mtu outside 1500monitor-interface insidemonitor-interface outsideicmp permit any mgmticmp permit any insideicmp permit any outsideasdm history enablearp timeout 14400nat-controlno xlate-bypassstatic (outside,inside) 10.5.1.1 10.5.1.1 netmask 255.255.255.255static (inside,outside) 10.4.1.31 10.4.1.31 netmask 255.255.255.255static (inside,outside) 10.4.1.32 10.4.1.32 netmask 255.255.255.255static (inside,outside) 10.4.1.33 10.4.1.33 netmask 255.255.255.255access-group OO in interface mgmtaccess-group 111 in interface outside per-user-overrideroute inside 10.4.1.32 255.255.255.255 10.1.1.2 1route inside 10.4.1.33 255.255.255.255 10.1.1.3 1route outside 10.5.1.1 255.255.255.255 209.165.201.31 1timeout xlate 3:00:00timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00timeout mgcp-pat 0:05:00 sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00timeout uauth 0:05:00 absoluteusername cisco password 3USUcOPFUiMCO4Jk encryptedno snmp-server locationno snmp-server contacttelnet timeout 5ssh 171.69.42.198 255.255.255.255 mgmtssh timeout 5!class-map inspection_defaultmatch default-inspection-traffic!!policy-map global_policyclass inspection_defaultinspect dns maximum-length 512inspect ftpinspect h323 h225inspect h323 rasinspect httpinspect netbiosinspect rshinspect rtspinspect skinnyinspect smtpinspect sunrpcinspect tftpinspect xdmcpinspect icmpinspect gtp GTPMAP =========================================attached the GTP map to gtp inspection in service policy!service-policy global_policy globalCryptochecksum:3b1c3373e908cb9163d9aa1387478fa4: endH.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
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:
•
•
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.
•
•
•
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
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:
•
•
•
•
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 21-8).
Figure 21-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 21-5 lists the commands available in H.225 map configuration mode.
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
hostname(config)# access-list acl-name permit {udp | tcp} any any eq portwhere acl-name is the name you assign to the access list and port is the H.323 port that the ACE identifies.
The standard ports are UDP ports 1718 and 1719 and TCP port 1720.
Step 2
hostname(config)# class-map class_map_namehostname(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
hostname(config-cmap)# match access-list acl-nameStep 4
a.
hostname(config)# h225-map map_namehostname(config-h225-map)#The system enters H.225 map configuration mode and the CLI prompt changes accordingly.
b.
hostname(config-h225-map)# hsi-group group_IDhostname(config-h225-map-hsi-grp)#where group_ID is a number, from 0 to 2147483647, that identifies the HSI group.
Note
The system enters HSI group configuration mode and the CLI prompt changes accordingly.
c.
hostname(config-h225-map-hsi-grp)# hsi ip_addresswhere ip_address is the addresses of the HSI.
d.
hostname(config-h225-map-hsi-grp)# endpoint ip_address interfacewhere interface with the interface on the FWSM that is connected to the endpoint and ip_address is the addresses of the endpoint.
e.
Step 5
hostname(config-cmap)# policy-map policy_map_namehostname(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
hostname(config-pmap)# class class_map_namehostname(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
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
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 21-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 1718hostname(config)# access-list h323_acl permit udp any any eq 1719hostname(config)# access-list h323_acl permit tcp any any eq 1720hostname(config)# class-map h323-traffichostname(config-cmap)# match access-list h323_aclhostname(config-cmap)# policy-map sample_policyhostname(config-pmap)# class h323_porthostname(config-pmap-c)# inspect h323 rashostname(config-pmap-c)# inspect h323 h225hostname(config-pmap-c)# service-policy sample_policy interface outsidehostname(config)#Example 21-9 includes an H.225 map with two HSI groups, as part of the overall H.323 configuration.
Example 21-9 Configuring H.323 Inspection with an H.225 Map
hostname(config)# access-list h323_acl permit udp any any eq 1718hostname(config)# access-list h323_acl permit udp any any eq 1719hostname(config)# access-list h323_acl permit tcp any any eq 1720hostname(config)# class-map h323-traffichostname(config-cmap)# match access-list h323_aclhostname(config-cmap)# h225-map sample_maphostname(config-h225-map)# hsi-group 1hostname(config-h225-map-hsi-grp)# hsi 10.10.15.11hostname(config-h225-map-hsi-grp)# endpoint 10.3.6.1 insidehostname(config-h225-map-hsi-grp)# endpoint 10.10.25.5 outsidehostname(config-h225-map-hsi-grp)# policy-map sample_policyhostname(config-pmap)# class h323_porthostname(config-pmap-c)# inspect h323 rashostname(config-pmap-c)# inspect h323 h225 sample_maphostname(config-pmap-c)# service-policy sample_policy interface outsidehostname(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
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 h225Total H.323 Calls: 11 Concurrent Call(s) forLocal: 10.130.56.3/1040 Foreign: 172.30.254.203/17201. CRV 9861Local: 10.130.56.3/1040 Foreign: 172.30.254.203/17200 Concurrent Call(s) forLocal: 10.130.56.4/1050 Foreign: 172.30.254.205/1720This 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 h245Total: 1LOCAL TPKT FOREIGN TPKT1 10.130.56.3/1041 0 172.30.254.203/1245 0MEDIA: LCN 258 Foreign 172.30.254.203 RTP 49608 RTCP 49609Local 10.130.56.3 RTP 49608 RTCP 49609MEDIA: LCN 259 Foreign 172.30.254.203 RTP 49606 RTCP 49607Local 10.130.56.3 RTP 49606 RTCP 49607There 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-rasTotal: 1GK Caller172.30.254.214 10.130.56.14This 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 Configuration
Figure 21-9 illustrates an H.323 inspection topology configured with H.323 GUP support.
Figure 21-9 H.323 Inspection Configuration with H.323 GUP Support
The following configuration applies to Figure 21-9.
firewall transparenthostname FWSM!interface Vlan50nameif insidebridge-group 1security-level 100!interface Vlan100nameif outsidebridge-group 1security-level 0!interface BVI1ip address 10.0.0.8 255.255.255.0!access-list h323-gup-permit extended permit udp any any eq 1719access-group h323-gup-permit in interface insideaccess-group h323-gup-permit in interface outside
Note
Outside gatekeeper configuration (GK):
gatekeeperzone local GK cisco.com 10.0.0.6zone cluster local gup-cluster GKelement inGK 10.0.0.7 1719Inside gatekeeper configuration (inGK):
gatekeeperzone local inGK cisco.com 10.0.0.7zone cluster local gup-cluster inGKelement GK 10.0.0.6 1719When the H.323 GUP session is established in this configuration, the following is output from the show h323 gup command:
hostname(config)# show h323 gupNo. LOCAL FOREIGN1 inside:10.0.0.7/15970 Outside:209.165.201.6/22754The 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 conn3 in use, 37 most usedNetwork Processor 1 connectionUDP out 209.165.201.6:1719 in 10.0.0.7:1719 idle 0:00:45 Bytes 672FLAGS - HTCP out 209.165.201.6:22754 in 10.0.0.7:15970 idle 0:00:04 Bytes 1188 FLAGS - UBInNetwork Processor 2 connectionsMulticast sessions:Network Processor 1 connectionNetwork Processor 2 connectionsIPv6 connections:H.323 Sample Configuration
Figure 21-10 shows a sample configuration for H.323 inspection.
Figure 21-10 H.323 Inspection Setup
Configuration of the IOS H.323 Gateway (Router R2) on the outside interface:
hostname(config)#hostname R2hostname(config)#interface FastEthernet0/1hostname(config-if)# ip address 209.165.201.1 255.0.0.0hostname(config-if)#no shuthostname(config-if)#exithostname(config)#ip route 10.0.0.0 255.0.0.0 209.165.201.2hostname(config)#voice-port 1/0/0hostname(config-voiceport)#no shuthostname(config-voiceport)#exithostname(config)#gatewayhostname(config-gateway)#hostname(config-gateway)#exithostname(config)#ip cefhostname(config)#int f0/1hostname(config-if)#h323-gateway voip interfacehostname(config-if)#h323-gateway voip id inGK ipaddr 10.0.0.6hostname(config-if)#h323-gateway voip h323-id R2Configure dial peer to forward voice calls to destination number 408555010991 using the H.323 protocol:
hostname(config)#dial-peer voice 101 voiphostname(config-dial-peer)#destination-pattern 40855501099hostname(config-dial-peer)#session target rashostname(config-dial-peer)#exitConfigure dial peer to forward voice calls to 4085550100 to voice port 1/0/0 in router R2:
hostname(config)#dial-peer voice 102 potshostname(config-dial-peer)#destination-pattern 4085550100hostname(config-dial-peer)#port 1/0/0hostname(config-dial-peer)#exithostname(config)#exitConfiguration of the IOS H.323 gateway (router R1) on the inside interface:
hostname(config)#hostname R1hostname(config)#interface FastEthernet0/1hostname(config-if)# ip address 10.100.100.1 255.0.0.0hostname(config-if)#no shuthostname(config-if)#ip route 209.165.201.0 255.0.0.0 10.100.100.2hostname(config)#hostname(config)#voice-port 3/0/0hostname(config-voiceport)#no shuthostname(config-voiceport)#exithostname(config)#gatewayhostname(config-gateway)#exithostname(config)#ip cefhostname(config)#int fastethernet0/1hostname(config-if)#h323-gateway voip interfacehostname(config-if)#h323-gateway voip id inGK ipaddr 10.0.0.6hostname(config-if)#h323-gateway voip h323-id R1hostname(config-if)#exitForward all voice calls destined to 4085550100 using the H.323 protocol:
hostname(config)#dial-peer voice 101 voiphostname(config-dial-peer)#destination-pattern 4085550100hostname(config-dial-peer)#session target rasForward all voice calls destined to 4085550199 to voice port 3/0/0:
hostname(config)#dial-peer voice 102 potshostname(config-dial-peer)#destination-pattern 4085550199hostname(config-dial-peer)#port 3/0/0hostname(config-dial-peer)#^ZConfiguration of the IOS H.323 Gatekeeper (router inGK) on the inside interface:
hostname(config)#hostname inGKhostname(config)#interface FastEthernet0/1hostname(config-if)# ip address 10.0.0.6 255.0.0.0hostname(config-if)#no shuthostname(config-if)#exithostname(config)#gatekeeperhostname(config-gk)#zone local inGK cisco.com 10.0.0.6hostname(config-gk)#no shuthostname(config)#hostname(config)#ip route 209.165.201.0 255.0.0.0 10.100.100.2Configuration of the FWSM for H.323 inspection:
hostname# config thostname(config)# interface Vlan100hostname(config-if)# nameif outsidehostname(config-if)# security-level 0hostname(config-if)# ip address 209.165.201.2 255.0.0.0hostname(config-if)#hostname(config-if)# interface Vlan50hostname(config-if)# nameif insidehostname(config-if)# security-level 100hostname(config-if)# ip address 10.100.100.2 255.0.0.0hostname(config-if)#hostname(config-if)# access-list voice extended permit udp any any eq 1719hostname(config)# access-list voice extended permit tcp any any eq h323hostname(config)#hostname(config)# access-group voice in interface outsidehostname(config)# access-group voice in interface insidehostname(config)#hostname(config)# policy-map global_policyhostname(config-pmap)# class inspection_defaulthostname(config-pmap-c)# inspect h323 h225hostname(config-pmap-c)# inspect h323 rashostname(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 conn4 in use, 7 most usedNetwork Processor 1 connectionsUDP out 209.165.201.1:52906 in 10.0.0.6:1719 idle 0:00:07 Bytes 5162FLAGS - HTCP out 209.165.201.1:1720 in 10.100.100.1:12139 idle 0:00:54 Bytes 1307 FLAGS - UOIhUDP out 209.165.201.1:19253 in 10.100.100.1:17815 idle 0:00:03 Bytes 13012FLAGS - HUDP out 209.165.201.1:19252 in 10.100.100.1:17814 idle 0:00:00 Bytes 1370400FLAGS - HNetwork Processor 2 connectionsMulticast sessions:Network Processor 1 connectionsNetwork Processor 2 connectionsIPv6 connections:FWSM/admin# show h225Total: 11 Concurrent Call(s) forLocal: 10.100.100.1/12139 Foreign: 209.165.201.1/17200 CRV: 2Local: 10.100.100.1/12139 TPKT: 211 Foreign: 209.165.201.1/1720 TPKT: 113HTTP 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
Use the HTTP inspection engine to protect against specific attacks and other threats that may be associated with HTTP traffic. HTTP inspection performs several functions.
•
•
The second feature is configured in conjunction with the filter command. For more information about filtering, see Chapter 17, "Applying Filtering Services."
Note
The enhanced HTTP inspection feature, which is also known as an application firewall and is available when you configure an HTTP map (see "Configuring an HTTP Inspection Policy Map for Additional Inspection Control"), can help prevent attackers from using HTTP messages for circumventing network security policy. It verifies the following for all HTTP messages.
•
•
•
Configuring an HTTP Inspection Policy Map for Additional Inspection Control
To specify actions when a message violates a parameter, create an HTTP inspection policy map. You can then apply the inspection policy map when you enable HTTP inspection according to the "Configuring Application Inspection" section.
Note
To create an HTTP inspection policy map, perform the following steps:
Step 1
Step 2
Step 3
A class map groups multiple traffic matches. Traffic must match all of the match commands to match the class map. You can alternatively identify match commands directly in the policy map. The difference between creating a class map and defining the traffic match directly in the inspection policy map is that the class map lets you create more complex match criteria, and you can reuse class maps.
To specify traffic that should not match the class map, use the match not command. For example, if the match not command specifies the string "example.com," then any traffic that includes "example.com" does not match the class map.
For the traffic that you identify in this class map, you can specify actions such as drop, drop-connection, reset, mask, set the rate limit, and/or log the connection in the inspection policy map.
If you want to perform different actions for each match command, you should identify the traffic directly in the policy map.
a.
hostname(config)# class-map type inspect http [match-all | match-any] class_map_namehostname(config-cmap)#Where class_map_name is the name of the class map. The match-all keyword is the default, and specifies that traffic must match all criteria to match the class map. The match-any keyword specifies that the traffic matches the class map if it matches at least one of the criteria. The CLI enters class-map configuration mode, where you can enter one or more match commands.
b.
hostname(config-cmap)# description stringc.
hostname(config-cmap)# match [not] req-resp content-type mismatchd.
hostname(config-cmap)# match [not] request args regex [regex_name | class regex_class_name]Where the regex_name is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2.
e.
hostname(config-cmap)# match [not] request body {regex [regex_name | class regex_class_name] | length gt max_bytes}Where the regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2. The length gt max_bytes is the maximum message body length in bytes.
f.
hostname(config-cmap)# match [not] request header {[field] [regex [regex_name | class regex_class_name]] | [length gt max_length_bytes | count gt max_count_bytes]}Where the field is the predefined message header keyword. The regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2. The length gt max_bytes is the maximum message body length in bytes. The count gt max_count is the maximum number of header fields.
g.
hostname(config-cmap)# match [not] request method {[method] | [regex [regex_name | class regex_class_name]]Where the method is the predefined message method keyword. The regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2.
h.
hostname(config-cmap)# match [not] request uri {regex [regex_name | class regex_class_name] | length gt max_bytes}Where the regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2. The length gt max_bytes is the maximum message body length in bytes.
i.
hostname(config-cmap)# match [not] response body {[active-x] | [java-applet] | [regex [regex_name | class regex_class_name]] | length gt max_bytes}Where the regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2. The length gt max_bytes is the maximum message body length in bytes.
j.
hostname(config-cmap)# match [not] response header {[field] [regex [regex_name | class regex_class_name]] | [length gt max_length_bytes | count gt max_count]}Where the field is the predefined message header keyword. The regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2. The length gt max_bytes is the maximum message body length in bytes. The count gt max_count is the maximum number of header fields.
k.
hostname(config-cmap)# match [not] response status-line {regex [regex_name | class regex_class_name]}Where the regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2.
Step 4
hostname(config)# policy-map type inspect http policy_map_namehostname(config-pmap)#Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration mode.
Step 5
hostname(config-pmap)# description stringStep 6
a.
•
hostname(config-pmap)# class class_map_namehostname(config-pmap-c)#•
b.
hostname(config-pmap-c)# {[drop-connection [send-protocol-error]| reset] [log]}Not all options are available for each match or class command. See the CLI help or the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference for the exact options available.
The drop-connection keyword drops the packet and closes the connection.
The reset keyword drops the packet, closes the connection, and sends a TCP reset to the server and/or client.
The log keyword, which you can use alone or with one of the other keywords, sends a system log message.
You can specify multiple class or match commands in the policy map. For information about the order of class and match commands, see the "Defining Actions in an Inspection Policy Map" section on page 19-7.
Step 7
a.
hostname(config-pmap)# parametershostname(config-pmap-p)#b.
hostname(config-pmap-p)# protocol-violation [action [drop-connection | reset | log]]Where the drop-connection action closes the connection. The reset action closes the connection and sends a TCP reset to the client. The log action sends a system log message when this policy map matches traffic.
c.
hostname(config-pmap-p)# mask-bannerThe mask-banner command is the default when policy-map type inspect is configured, however no mask-banner can be entered to change the default.
d.
hostname(config-pmap-p)# spoof-server stringWhere the string argument is the string to substitute for the server header field. Note: WebVPN streams are not subject to the spoof-server command.
The following example shows how to define an HTTP inspection policy map that will allow and log any HTTP connection that attempts to access "www\.example.com/.*\.asp" or "www\.example[0-9][0-9]\.com" with methods "GET" or "PUT." All other URL/Method combinations will be silently allowed.
hostname(config)# regex url1 "www\.example.com/.*\.asp"hostname(config)# regex url2 "www\.example[0-9][0-9]\.com"hostname(config)# regex get "GET"hostname(config)# regex put "PUT"hostname(config)# class-map type regex match-any url_to_loghostname(config-cmap)# match regex url1hostname(config-cmap)# match regex url2hostname(config-cmap)# exithostname(config)# class-map type regex match-any methods_to_loghostname(config-cmap)# match regex gethostname(config-cmap)# match regex puthostname(config-cmap)# exithostname(config)# class-map type inspect http http_url_policyhostname(config-cmap)# match request uri regex class url_to_loghostname(config-cmap)# match request method regex class methods_to_loghostname(config-cmap)# exithostname(config)# policy-map type inspect http http_policyhostname(config-pmap)# class http_url_policyhostname(config-pmap-c)# logICMP 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
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.
•
•
•
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 21-11 illustrates how NAT can be used with MGCP.
Figure 21-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.
•
•
•
•
•
•
•
•
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:
•
•
Note
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
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
Configuring and Enabling MGCP Inspection
To enable and configure MGCP application inspection, perform the following steps:
Step 1
hostname(config)# access-list acl-name permit udp any any eq port-1hostname(config)# access-list acl-name permit udp any any eq port-2where 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
hostname(config)# class-map class_map_namehostname(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
hostname(config-cmap)# match access-list acl-nameStep 4
a.
hostname(config-cmap)# mgcp-map map_namehostname(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.
hostname(config-mgcp-map)# call-agent ip_address group_idc.
hostname(config-mgcp-map)# gateway ip_address group_idd.
hostname(config-mgcp-map)# command-queue command_limitStep 5
hostname(config-cmap)# policy-map policy_map_namehostname(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
hostname(config-pmap)# class class_map_namehostname(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
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
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 21-10 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 21-10 Enabling and Configuring MGCP Inspection
hostname(config)# access-list mgcp_acl permit udp any any eq 2427hostname(config)# access-list mgcp_acl permit udp any any eq 2727hostname(config)# class-map mgcp-traffichostname(config-cmap)# match access-list mgcp_aclhostname(config-cmap)# mgcp-map sample_maphostname(config-mgcp-map)# call-agent 10.10.11.5 101hostname(config-mgcp-map)# call-agent 10.10.11.6 101hostname(config-mgcp-map)# call-agent 10.10.11.7 102hostname(config-mgcp-map)# call-agent 10.10.11.8 102hostname(config-mgcp-map)# gateway 10.10.10.115 101hostname(config-mgcp-map)# gateway 10.10.10.116 102hostname(config-mgcp-map)# gateway 10.10.10.117 102hostname(config-mgcp-map)# command-queue 150hostname(config-mgcp-map)# policy-map sample_policyhostname(config-pmap)# class mgcp_porthostname(config-pmap-c)# inspect mgcp sample_maphostname(config-pmap-c)# service-policy sample_policy interface outsideConfiguring 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 commands1 in use, 1 most used, 200 maximum allowedCRCX, gateway IP: host-pc-2, transaction ID: 2052, idle: 0:00:07The following is sample output from the show mgcp commands detail command:
hostname# show mgcp commands detail1 in use, 1 most used, 200 maximum allowedCRCX, idle: 0:00:10Gateway IP host-pc-2Transaction ID 2052Endpoint name aaln/1Call ID 9876543210abcdefConnection IDMedia IP 192.168.5.7Media port 6058The following is sample output from the show mgcp sessions command:
hostname# show mgcp sessions1 in use, 1 most usedGateway IP host-pc-2, connection ID 6789af54c9, active 0:00:11The following is sample output from the show mgcp sessions detail command:
hostname# show mgcp sessions detail1 in use, 1 most usedSession active 0:00:14Gateway IP host-pc-2Call ID 9876543210abcdefConnection ID 6789af54c9Endpoint name aaln/1Media lcl port 6166Media rmt IP 192.168.5.7Media rmt port 6058MGCP Sample Configuration
Figure 21-12 shows a sample configuration for MGCP inspection:
Figure 21-12 MGCP Inspection Setup
See the following configuration for this example:
hostname(config)# interface Vlan100hostname(config-if)# nameif outsidehostname(config-if)# security-level 0hostname(config-if)# ip address 209.165.201.2 255.0.0.0hostname(config-if)# !hostname(config-if)# interface Vlan50hostname(config-if)# nameif insidehostname(config-if)# security-level 100hostname(config-if)# ip address 10.100.100.2 255.0.0.0hostname(config-if)# !hostname(config-if)# interface Vlan90hostname(config-if)# nameif callmgrhostname(config-if)# security-level 75hostname(config-if)# ip address 10.0.0.254 255.0.0.0TFTP 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 10.0.0.210 eq 2428hostname(config)# access-list mgcp extended permit udp any any eq 2427hostname(config)# access-list mgcp extended permit udp any any eq tftpApply the above access lists on the inside and outside interfaces for incoming traffic:
hostname(config)# access-group mgcp in interface outsidehostname(config)# access-group mgcp in interface insideConfigure 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-inspecthostname(config-mgcp-map)# call-agent 15.0.0.210 101hostname(config-mgcp-map)# gateway 10.100.100.1 101hostname(config-mgcp-map)# gateway 209.165.201.1 101hostname(config-mgcp-map)# command-queue 150hostname(config-mgcp-map)# exitApply MGCP inspection with MGCP map:
hostname(config)# policy-map global_policyhostname(config-pmap)# class inspection_defaulthostname(config-pmap-c)# inspect mgcp mgcp-inspectOutput of show conn in admin context, which shows the connections established between IOS MGCP gateways and call agents:
hostname(config)# show conn6in use, 48 most usedNetwork Processor 1 connectionsNetwork Processor 2 connectionsUDP out 15.0.0.210:2427 in 10.100.100.1:2427 idle 0:00:04 Bytes 5790 FLAGS - gUDP out 209.165.201.1:2427 in 10.0.0.210:2427 idle 0:00:00 Bytes 8221 FLAGS - gUDP out 209.165.201.1:18199 in 10.100.100.1:19247 idle 0:00:03 Bytes 14080 FLAGS - gUDP out 209.165.201.1:18199 in 10.100.100.1:19246 idle 0:00:00 Bytes 4030838 FLAGS - gTCP out 10.0.0.210:2428 in 10.100.100.1:12695 idle 0:00:04 Bytes 1346 FLAGS - UOITCP out 209.165.201.1:15954 in 10.0.0.210:2428 idle 0:00:00 Bytes 1346 FLAGS - UBOIMulticast sessions:Network Processor 1 connectionsNetwork Processor 2 connectionsIPV6 connections:IOS MGCP gateway configuration of router R2:
hostname(config)# interface FastEthernet 0/1hostname(config-if)# ip address 209.165.201.1 255.0.0.0hostname(config-if)# no shuthostname(config-if)# ip host FWSM-CCM-14 10.0.0.210hostname(config-if)# exithostname(config)# ip route 10.0.0.0 255.0.0.0 209.165.201.2hostname(config)# mgcphostname(config)# mgcp call-agent FWSM-CCM-14hostname(config)# mgcp dtmf-relay voip codec all mode out-of-bandhostname(config)# ccm-manager mgcphostname(config)# ccm-manager config server 10.0.0.210hostname(config)# ccm-manager confighostname(config)# dial-peer voice 100 potshostname(config-dial-peer)# application mgcpapphostname(config-dial-peer)# port 1/0/0hostname(config-dial-peer)# no shutIOS MGCP gateway configuration of router R1:
hostname(config)# interface FastEthernet 0/1hostname(config-if)# ip address 10.100.100.1 255.0.0.0hostname(config-if)# no shuthostname(config-if)# exithostname(config)# ip route 10.0.0.0 255.0.0.0 10.100.100.2hostname(config)# ccm-manager mgcphostname(config)# ccm-manager music-on-holdhostname(config)# ccm-manager config server 10.0.0.210hostname(config)# ccm-manager confighostname(config)# mgcphostname(config)# mgcp call-agent FWSM-CCM-14hostname(config)# mgcp dtmf-relay voip codec all mode out-of-bandhostname(config)# dial-peer voice 101 potshostname(config-dial-peer)# application mgcpapphostname(config-dial-peer)# port 3/0/0NetBIOS 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
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
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:
•
•
•
•
•
Enabling and Configuring RTSP Inspection
To enable or configure RTSP application inspection, perform the following steps:
Step 1
Step 2
hostname(config)# access-list acl-name any any tcp eq port_number
Tip
Step 3
hostname(config)# class-map class_map_namehostname(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
hostname(config-cmap)# match access-list acl-nameStep 5
hostname(config-cmap)# policy-map policy_map_namehostname(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
hostname(config-pmap)# class class_map_namehostname(config-pmap-c)#where class_map_name is the name of the class map you created. The CLI enters the policy map class configuration mode and the prompt changes accordingly.
Step 7
hostname(config-pmap-c)# inspect rtsphostname(config-pmap-c)#Step 8
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 21-11 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 21-11 Enabling and Configuring RTSP Inspection
hostname(config)# access-list rtsp_acl permit tcp any any eq 554hostname(config)# access-list rtsp_acl permit tcp any any eq 8554hostname(config)# class-map rtsp-traffichostname(config-cmap)# match access-list rtsp_aclhostname(config-cmap)# policy-map sample_policyhostname(config-pmap)# class rtsp_porthostname(config-pmap-c)# inspect rtsphostname(config-pmap-c)# service-policy sample_policy interface outsideSIP 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, 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.
•
•
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 5060), 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:
•
–
–
–
•
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.
•
•
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
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.
Configuring a SIP Inspection Policy Map for Additional Inspection Control
To specify actions when a message violates a parameter, create a SIP inspection policy map. You can then apply the inspection policy map when you enable SIP inspection according to the "Configuring Application Inspection" section.
To create a SIP inspection policy map, perform the following steps:
Step 1
Step 2
Step 3
A class map groups multiple traffic matches. Traffic must match all of the match commands to match the class map if match-all is specified. Traffic must match any one of the match commands to match the class map if the match-any keyword is used.
You can alternatively identify match commands directly in the policy map. The difference between creating a class map and defining the traffic match directly in the inspection policy map is that the class map lets you create more complex match criteria, and you can reuse class maps.
To specify traffic that should not match the class map, use the match not command. For example, if the match not command specifies the string "example.com," then any traffic that includes "example.com" does not match the class map.
For the traffic that you identify in this class map, you can specify actions such as drop-connection, reset, drop, drop-connection log, reset log, and/or log the connection in the inspection policy map.
If you want to perform different actions for each match command, you should identify the traffic directly in the policy map.
a.
hostname(config)# class-map type inspect sip [match-all | match-any] class_map_namehostname(config-cmap)#Where the class_map_name is the name of the class map. The name can be a string up to 40 characters. The match-all keyword is the default, and specifies that traffic must match all criteria to match the class map if match-all is specified. The match-any keyword specifies that the traffic matches the class map if any of the match commands in the class map is matched.
The CLI enters class-map configuration mode, where you can enter one or more match commands.
b.
hostname(config-cmap)# description stringWhere string is the description of the class map (up to 200 characters).
c.
hostname(config-cmap)# match [not] called-party regex {class class_name | regex_name}Where the regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2.
d.
hostname(config-cmap)# match [not] calling-party regex {class class_name | regex_name}Where the regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2.
e.
hostname(config-cmap)# match [not] content length gt lengthWhere length is the number of bytes the content length is greater than. 0 to 65536.
f.
hostname(config-cmap)# match [not] content type {sdp | regex {class class_name | regex_name}}Where the regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2.
g.
hostname(config-cmap)# match [not] im-subscriber regex {class class_name | regex_name}Where the regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2.
h.
hostname(config-cmap)# match [not] message-path regex {class class_name | regex_name}Where the regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2.
i.
hostname(config-cmap)# match [not] request-method methodWhere method is the type of method to match (ack, bye, cancel, info, invite, message, notify, options, prack, refer, register, subscribe, unknown, update).
j.
hostname(config-cmap)# match [not] third-party-registration regex {class class_name | regex_name}Where the regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2.
k.
hostname(config-cmap)# match [not] uri {sip | tel} length gt lengthWhere length is the number of bytes the URI is greater than. 0 to 65536.Step 4
hostname(config)# policy-map type inspect sip policy_map_namehostname(config-pmap)#Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration mode.
Step 5
hostname(config-pmap)# description stringThe string for the description can contain up to 200 characters.
Step 6
a.
•
hostname(config-pmap)# class class_map_namehostname(config-pmap-c)#•
b.
hostname(config-pmap-c)# {[drop | drop-connection | mask | reset] [log]}Not all options are available for each match or class command. See the CLI help or the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference for the exact options available.
The drop keyword drops all packets that match.
The drop-connection keyword drops the packet and closes the connection.
The mask keyword masks out the matching portion of the packet.
The reset keyword drops the packet, closes the connection, and sends a TCP reset to the server and/or client.
The log keyword, which you can use alone or with one of the other keywords, sends a system log message.
You can specify multiple class or match commands in the policy map. For information about the order of class and match commands, see the "Defining Actions in an Inspection Policy Map" section on page 19-7.
Step 7
a.
hostname(config-pmap)# parametershostname(config-pmap-p)#b.
hostname(config-pmap-p)# imc.
hostname(config-pmap-p)# ip-address-privacyd.
hostname(config-pmap-p)# max-forwards-validation action {drop | drop-connection | reset | log} [log]e.
hostname(config-pmap-p)# rtp-conformance [enforce-payloadtype]Where the enforce-payloadtype keyword enforces the payload type to be audio or video based on the signaling exchange.
f.
hostname(config-pmap-p)# software-version action {mask | log} [log]Where the mask keyword removes the SIP header containing the software version and the Alert-Info and Call-Info header fields in the SIP messages.
g.
hostname(config-pmap-p)# state-checking action {drop | drop-connection | reset | log} [log]h.
hostname(config-pmap-p)# strict-header-validation action {drop | drop-connection | reset | log} [log]
Note
When the security level is different on the inside and outside interfaces, the reset is sent to the inside host only. To send the reset to the outside, you must configure the service resetinbound command and enter the reset log keywords for the strict-header-validation command.i.
hostname(config-pmap-p)# traffic-non-sipj.
hostname(config-pmap-p)# uri-non-sip action {mask | log} [log]The following example shows how to disable instant messaging over SIP:
hostname(config)# policy-map type inspect sip mymaphostname(config-pmap)# parametershostname(config-pmap-p)# no imhostname(config)# policy-map global_policyhostname(config-pmap)# class inspection_defaulthostname(config-pmap-c)# no inspect siphostname(config-pmap-c)# inspect sip mymaphostname(config)# service-policy global_policy globalConfiguring 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:ssThis 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:ssThis 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:ssIn 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:ssThis 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 21-13 Media Connection Clear on BYE Message
In Figure 21-13, when 200 OK is not received for the BYE message, media connections are removed after the timeout sip-disconnect occurs.
Figure 21-14 Media Connection Clear on CANCEL Message
In Figure 21-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 21-15 Media Connection Clear on 4xx/5xx/6xx SIP Messages
In Figure 21-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 21-16 Extending Timeout for Provisional Responses
Restrictions include:
•
•
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, show local-host, and show service-policy inspect sip commands, this command is used for troubleshooting SIP inspection engine issues.
Note
The following is sample output from the show sip command:
hostname# show sipTotal: 2call-id c3943000-960ca-2e43-228f@10.130.56.44state Call init, idle 0:00:01call-id c3943000-860ca-7e1f-11f7@10.130.56.45state Active, idle 0:00:06This 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 Configuration
Figure 21-17 shows a sample configuration for SIP inspection:
Figure 21-17 SIP IP Address Privacy Setup
See the following configuration for this example:
hostname(config)# interface Vlan12hostname(config-if)# nameif outsidehostname(config-if)# security-level 0hostname(config-if)# ip address 10.2.0.10 255.0.0.0hostname(config-if)# !Vlan 12 is an outside Vlan that routes all packets to 10.x.x.x network back to the FWSM with the next hop IP address set to 10.2.0.10. This is done by configuring policy-based routing at the up-stream router.
hostname(config-if)# interface Vlan50hostname(config-if)# nameif insidehostname(config-if)# security-level 100hostname(config-if)# ip address 10.100.100.7 255.255.255.0The two phones 4085550100 and 4085550199 are used in the same 209.165.201.0 subnet.
hostname(config)# access-list voice extended permit udp any any eq siphostname(config)# access-list voice extended permit tcp any any eq siphostname(config)# access-list voice extended permit udp any any eq tftphostname(config)# !hostname(config)# sip-map privacyhostname(config-if)# ip-address-privacyhostname(config)# !hostname(config)# nat-controlhostname(config)# static (inside, outside) 10.3.100.115 209.165.201.115 netmask 255.255.255.255hostname(config)# static (inside, outside) 10.3.100.118 209.165.201.118 netmask 255.255.255.255Each 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 outsidehostname(config)# access-group voice in interface insidehostname(config)# route outside 10.3.0.0 255.0.0.0 10.2.0.5 1Configure route to10.3.0.0 via 10.2.0.5 (IP address of the next hop router):
hostname(config)# route outside 209.165.201.0 255.0.0.0 10.2.0.5 1hostname(config)# !hostname(config)# policy-map global_policyhostname(config-pmap)# class inspection_defaulthostname(config-pmap-c)# inspect dns maximum-length 512hostname(config-pmap-c)# inspect ftphostname(config-pmap-c)# inspect h323 h225hostname(config-pmap-c)# inspect h323 rashostname(config-pmap-c)# inspect rshhostname(config-pmap-c)# inspect smtphostname(config-pmap-c)# inspect sqlnethostname(config-pmap-c)# inspect skinnyhostname(config-pmap-c)# inspect sunrpchostname(config-pmap-c)# inspect xdmcphostname(config-pmap-c)# inspect netbioshostname(config-pmap-c)# inspect tftphostname(config-pmap-c)# inspect sip privacyRouter configuration:
hostname(config)# interface GigabitEthernet0/2hostname(config-if)# ip address 10.2.0.5 255.0.0.0hostname(config-if)# ip policy route-map privacyhostname(config-if)# duplex autohostname(config-if)# speed autohostname(config-if)# media-type rj45hostname(config-if)# no negotiation autohostname(config-if)# !hostname(config)# interface GigabitEthernet0/3hostname(config-if)# ip address 209.165.201.1 255.0.0.0hostname(config-if)# duplex autohostname(config-if)# speed autohostname(config-if)# media-type rj45hostname(config-if)# no negotiation autohostname(config-if)# !hostname(config-if)# ip route 10.3.0.0 255.0.0.0 10.2.0.10hostname(config-if)# ip route 50.0.0.0 255.0.0.0 12.0.0.10Configured route to 10.3.0.0 and 209.165.201.0 reachable via 10.2.0.10 (IP address of FWSM).
hostname(config)# access-list 10 permit ip any 10.3.0.0 0.255.255.255hostname(config)# !hostname(config)# route-map privacy permit 10hostname(config-if)# match ip address 100hostname(config-if)# set ip next-hop 10.2.0.10Route map is configured to capture any packets destined for 10.3.0.0 network to be sent to 10.2.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 conn6 in use, 28 most usedNetwork Processor 1 connectionsUDP out 209.165.201.100:5060 in 209.165.201.118:5060 idle 0:00:21 Bytes 67358 FLAGS - TUDP out 10.3.100.115:16384 in 209.165.201.118:16384 idle 0:00:00 Bytes 6042324 FLAGS - mUDP out 209.165.201.100:0 in 209.165.201.118:5060 idle 0:00:21 Bytes 18 FLAGS - tNetwork Processor 2 connectionsUDP out 209.165.201.100:5060 in 209.165.201.115:5060 idle 0:00:25 Bytes 80181 FLAGS - TUDP out 10.3.100.118:16384 in 209.165.201.115:16384 idle 0:00:00 Bytes 6047556 FLAGS - mUDP out 209.165.201.100:0 in 209.165.201.115:5060 idle 0:00:25 Bytes 33 FLAGS - tMulticast sessions:Network Processor 1 connectionsNetwork Processor 2 connectionsIPv6 connections:hostname(config)# show xlate2 in use, 2 most usedGlobal 30.100.100.115 Local 209.165.201.115Global 30.100.100.118 Local 209.165.201.118Skinny (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
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. The FWSM supports all versions through Version 17 including:
•
•
The following actions are not supported:
•
•
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 on page 8-38.
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:
•
•
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.
The following is not supported for SCCP version 17 phones:
•
•
Note
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
hostname(config)# class-map class_map_nameReplace class_map_name with the name of the traffic class, for example:
hostname(config)# class-map sccp_portWhen 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
hostname(config-cmap)# match port tcp eq 2000hostname(config-cmap)# exithostname(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-2010To 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
hostname(config)# policy-map policy_map_nameReplace policy_map_name with the name of the policy map, as in the following example:
hostname(config)# policy-map sample_policyThe CLI enters the policy map configuration mode and the prompt changes accordingly, as follows:
hostname(config-pmap)#Step 4
hostname(config-pmap)# class class_map_nameFor example, the following command assigns the sccp_port traffic class to the current policy map:
hostname(config-pmap)# class sccp_portThe CLI enters the policy map class configuration mode and the prompt changes accordingly, as follows:
hostname(config-pmap-c)#Step 5
hostname(config-pmap-c)# inspect skinnyStep 6
hostname(config-pmap-c)# exithostname(config-pmap)#Step 7
hostname(config-pmap)# exithostname(config)#Step 8
hostname(config)# service-policy policy_map_name [global | interface interface_IDReplace 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 outsideThe following command applies the sample_policy to the all the FWSM interfaces:
hostname(config)# service-policy sample_policy globalYou enable the SCCP inspection engine as shown in Example 21-12, 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 21-12 Enabling SCCP Application Inspection
hostname(config)# class-map sccp_porthostname(config-cmap)# match port tcp eq 2000hostname(config-cmap)# exithostname(config)# policy-map sample_policyhostname(config-pmap)# class sccp_porthostname(config-pmap-c)# inspect skinnyhostname(config-pmap-c)# exithostname(config)# service-policy sample_policy interface outsideVerifying 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 skinnyLOCAL FOREIGN STATE---------------------------------------------------------------1 10.0.0.11/52238 172.18.1.33/2000 1AUDIO 10.0.0.11/22948 172.18.1.22/207982 10.0.0.22/52232 172.18.1.33/2000 1VIDEO 10.0.0.22/20798 172.18.1.11/22948The 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 debug2 in use, 2 most usedFlags: D - DNS, d - dump, I - identity, i - inside, n - no random,r - portmap, s - staticNAT from inside:10.0.0.11 to outside:172.18.1.11 flags si idle 0:00:16 timeout 0:05:00NAT from inside:10.0.0.22 to outside:172.18.1.22 flags si idle 0:00:14 timeout 0:05:00SCCP (Skinny) Sample Configuration
Figure 21-18 shows a sample configuration for SCCP (Skinny) inspection:
Figure 21-18 SCCP (Skinny) Inspection Setup
See the following configuration for this example:
hostname(config)# interface Vlan100hostname(config-if)# nameif outsidehostname(config-if)# security-level 0hostname(config-if)# ip address 209.165.201.2 255.0.0.0hostname(config-if)# !hostname(config-if)# interface Vlan50hostname(config-if)# nameif insidehostname(config-if)# security-level 100hostname(config-if)# ip address 10.100.100.2 255.0.0.0hostname(config-if)# !hostname(config-if)# interface Vlan90hostname(config-if)# nameif callmgrhostname(config-if)# security-level 75hostname(config-if)# ip address 209.165.201.254 255.0.0.0TFTP 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 209.165.201.210 eq tftphostname(config)# access-list voice extended permit tcp any host 209.165.201.210 eq 2000Apply the above access lists on the inside and outside interfaces for incoming traffic:
hostname(config)# access-group voice in interface outsidehostname(config)# access-group voice in interface insideConfigure SCCP (Skinny) inspection:
hostname(config)# policy-map global_policyhostname(config-pmap)# class inspection_defaulthostname(config-pmap-c)# inspect skinny
Output of show skinny when Skinny phone call through the firewall module is active:
hostname(config)# show skinnyLOCAL FOREIGN STATE---------------------------------------------------------------------1 10.0.0.2/49723 209.165.201.210/2000 1AUDIO 209.165.201.2/24002 209.165.201.211/192122 209.165.201.210/2000 209.165.201.211/49692 1AUDIO 10.0.0.2/24002 209.165.201.211/19212Output 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 conn3 in use, 26 most usedNetwork Processor 1 connectionsTCP out 209.165.201.210:2000 in 10.0.0.2:49723 idle 0:00:07 Bytes 10232 FLAGS - UOINetwork Processor 2 connectionsTCP out 209.165.201.211:49692 in 209.165.201.210:49723 idle 0:00:27 Bytes 12394 FLAGS - UBOIUDP out 209.165.201.211:19212 in 10.0.0.2:24002 idle 0:00:00 Bytes 3575654 FLAGS - KMulticast sessions:Network Processor 1 connectionsNetwork Processor 2 connectionsIPV6 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
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
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:
•
•
•
SMTP inspection monitors the command and response sequence for the following anomalous signatures:
•
•
•
•
•
•
•
Note
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
Step 2
hostname(config)# class-map class_map_namehostname(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
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_numberwhere 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
Step 4
hostname(config-cmap)# policy-map policy_map_namehostname(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
hostname(config-pmap)# class class_map_namehostname(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
a.
hostname(config-pmap-c)# inspect esmtpb.
hostname(config-pmap-c)# inspect smtp
Note
Step 7
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 21-13 Configuring and Enabling ESMTP Inspection
hostname(config)# class-map smtp_porthostname(config-cmap)# match port tcp eq 25hostname(config-cmap)# policy-map sample_policyhostname(config-pmap)# class smtp_porthostname(config-pmap-c)# inspect esmtphostname(config-pmap-c)# service-policy sample_policy interface outsidehostname(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
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
Step 2
hostname(config)# class-map class_map_namehostname(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
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_numberwhere begin_port_number is the lowest port in the range of SNMP ports and end_port_number is the highest port.
Tip
Step 4
hostname(config-cmap)# snmp-map map_namehostname(config-snmp-map)#where map_name is the name of the SNMP map. The CLI enters SNMP map configuration mode.
Step 5
hostname(config-snmp-map)# deny version versionhostname(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
hostname(config-cmap)# policy-map policy_map_namehostname(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
hostname(config-pmap)# class class_map_namehostname(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
hostname(config-pmap-c)# inspect snmp snmp_map_namehostname(config-pmap-c)#where snmp_map_name is the SNMP map that you created in Step 4.
Step 9
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 21-14 enables SNMP application inspection on traffic sent to TCP ports 161 and 162 from the outside interface:
Example 21-14 Configuring SNMP Application Inspection
hostname(config)# class-map snmp_porthostname(config-cmap)# match port tcp range 161 162hostname(config-cmap)# snmp-map sample_maphostname(config-snmp-map)# deny version 1hostname(config-snmp-map)# deny version 2hostname(config-snmp-map)# policy-map sample_policyhostname(config-pmap)# class snmp_porthostname(config-pmap-c)# inspect snmp sample_maphostname(config-pmap-c)# service-policy sample_policy interface outsidehostname(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
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
Note
Enabling and Configuring Sun RPC Inspection
Sun RPC inspection is enabled by default.
Note
To enable Sun RPC inspection or change the default port used for receiving Sun RPC traffic using TCP, perform the following steps:
Step 1
Step 2
hostname(config)# class-map class_map_namehostname(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
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_numberwhere 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
Step 4
hostname(config-cmap)# policy-map policy_map_namehostname(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
hostname(config-pmap)# class class_map_namehostname(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
hostname(config-pmap-c)# inspect sunrpchostname(config-pmap-c)#Step 7
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 21-15 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_porthostname(config-cmap)# match port tcp eq 111hostname(config-cmap)# policy-map sample_policyhostname(config-pmap)# class sunrpc_porthostname(config-pmap-c)# inspect sunrpchostname(config-pmap-c)# service-policy sample_policy interface outsidehostname(config)#Example 21-16 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 21-16 Enabling and Configuring UDP-based Sun RPC Inspection
hostname(config)# policy-map asa_global_fw_policyhostname(config-pmap)# class inspection_defaulthostname(config-pmap-c)# inspect sunrpchostname(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:00This 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-serverThis 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 activeThis clears the pinholes open because Sun RPC application inspection enabled the traffic based on service requests to the port mapper service.
Note
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.165.201.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 conn15 in use, 21 most usedUDP 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.168.201.5:714 idle 0:00:05 flags ihostname(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-serversunrpc-server inside 192.168.100.2 255.255.255.255 service 100003 protocol UDP port 111 timeout 0:30:00sunrpc-server inside 192.168.100.2 255.255.255.255 service 100005 protocol UDP port 111 timeout 0:30:00This 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 activeLOCAL FOREIGN SERVICE TIMEOUT-----------------------------------------------1 209.165.201.5/0 192.168.100.2/2049 100003 0:30:002 209.165.201.5/0 192.168.100.2/2049 100003 0:30:003 209.165.201.5/0 192.168.100.2/647 100005 0:30:004 209.165.201.5/0 192.168.100.2/650 100005 0:30:00The 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 -pprogram vers proto port100000 2 tcp 111 portmapper100000 2 udp 111 portmapper100024 1 udp 632 status100024 1 tcp 635 status100003 2 udp 2049 nfs100003 3 udp 2049 nfs100003 2 tcp 2049 nfs100003 3 tcp 2049 nfs100021 1 udp 32771 nlockmgr100021 3 udp 32771 nlockmgr100021 4 udp 32771 nlockmgr100021 1 tcp 32852 nlockmgr100021 3 tcp 32852 nlockmgr100021 4 tcp 32852 nlockmgr100005 1 udp 647 mountd100005 1 tcp 650 mountd100005 2 udp 647 mountd100005 2 tcp 650 mountd100005 3 udp 647 mountd100005 3 tcp 650 mountdIn 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.
