Cisco PIX OS version 7.0/8.21新特性

network

Firewall Mode Overview

This chapter describes how the firewall works in each firewall mode. To set the firewall mode, see the "Setting Transparent or Routed Firewall Mode" section on page 2-5.
This chapter includes the following sections:
• Routed Mode Overview
• Transparent Mode Overview
Routed Mode Overview In routed mode, the security appliance is considered to be a router hop in the network. It can use OSPF or RIP (in single context mode). Routed mode supports many interfaces. Each interface is on a different subnet. You can share interfaces between contexts.
This section includes the following topics:
• IP Routing Support
• How Data Moves Through the Security Appliance in Routed Firewall Mode
IP Routing Support The security appliance acts as a router between connected networks, and each interface requires an IP address on a different subnet. In single context mode, the routed firewall supports OSPF and RIP. Multiple context mode supports static routes only. We recommend using the advanced routing capabilities of the upstream and downstream routers instead of relying on the security appliance for extensive routing needs.
How Data Moves Through the Security Appliance in Routed Firewall Mode This section describes how data moves through the security appliance in routed firewall mode, and includes the following topics:
• An Inside User Visits a Web Server
• An Outside User Visits a Web Server on the DMZ
• An Inside User Visits a Web Server on the DMZ
• An Outside User Attempts to Access an Inside Host
• A DMZ User Attempts to Access an Inside Host
An Inside User Visits a Web Server Figure 15-1 shows an inside user accessing an outside web server.
Figure 15-1 Inside to Outside

The following steps describe how data moves through the security appliance (see Figure 15-1):
1. The user on the inside network requests a web page from www.example.com.
2. The security appliance receives the packet and because it is a new session, the security appliance verifies that the packet is allowed according to the terms of the security policy (access lists, filters, AAA).
For multiple context mode, the security appliance first classifies the packet according to either a unique interface or a unique destination address associated with a context; the destination address is associated by matching an address translation in a context. In this case, the interface would be unique; the www.example.com IP address does not have a current address translation in a context.
3. The security appliance translates the local source address (10.1.2.27) to the global address 209.165.201.10, which is on the outside interface subnet.
The global address could be on any subnet, but routing is simplified when it is on the outside interface subnet.
4. The security appliance then records that a session is established and forwards the packet from the outside interface.
5. When www.example.com responds to the request, the packet goes through the security appliance, and because the session is already established, the packet bypasses the many lookups associated with a new connection. The security appliance performs NAT by translating the global destination address to the local user address, 10.1.2.27.
6. The security appliance forwards the packet to the inside user.
An Outside User Visits a Web Server on the DMZ Figure 15-2 shows an outside user accessing the DMZ web server.
Figure 15-2 Outside to DMZ

The following steps describe how data moves through the security appliance (see Figure 15-2):
1. A user on the outside network requests a web page from the DMZ web server using the global destination address of 209.165.201.3, which is on the outside interface subnet.
2. The security appliance receives the packet and because it is a new session, the security appliance verifies that the packet is allowed according to the terms of the security policy (access lists, filters, AAA).
For multiple context mode, the security appliance first classifies the packet according to either a unique interface or a unique destination address associated with a context; the destination address is associated by matching an address translation in a context. In this case, the classifier "knows" that the DMZ web server address belongs to a certain context because of the server address translation.
3. The security appliance translates the destination address to the local address 10.1.1.3.
4. The security appliance then adds a session entry to the fast path and forwards the packet from the DMZ interface.
5. When the DMZ web server responds to the request, the packet goes through the security appliance and because the session is already established, the packet bypasses the many lookups associated with a new connection. The security appliance performs NAT by translating the local source address to 209.165.201.3.
6. The security appliance forwards the packet to the outside user.
An Inside User Visits a Web Server on the DMZ Figure 15-3 shows an inside user accessing the DMZ web server.
Figure 15-3 Inside to DMZ

The following steps describe how data moves through the security appliance (see Figure 15-3):
1. A user on the inside network requests a web page from the DMZ web server using the destination address of 10.1.1.3.
2. The security appliance receives the packet and because it is a new session, the security appliance verifies that the packet is allowed according to the terms of the security policy (access lists, filters, AAA).
For multiple context mode, the security appliance first classifies the packet according to either a unique interface or a unique destination address associated with a context; the destination address is associated by matching an address translation in a context. In this case, the interface is unique; the web server IP address does not have a current address translation.
3. The security appliance then records that a session is established and forwards the packet out of the DMZ interface.
4. When the DMZ web server responds to the request, the packet goes through the fast path, which lets the packet bypass the many lookups associated with a new connection.
5. The security appliance forwards the packet to the inside user.
An Outside User Attempts to Access an Inside Host Figure 15-4 shows an outside user attempting to access the inside network.
Figure 15-4 Outside to Inside

The following steps describe how data moves through the security appliance (see Figure 15-4):
1. A user on the outside network attempts to reach an inside host (assuming the host has a routable IP address).
If the inside network uses private addresses, no outside user can reach the inside network without NAT. The outside user might attempt to reach an inside user by using an existing NAT session.
2. The security appliance receives the packet and because it is a new session, the security appliance verifies if the packet is allowed according to the security policy (access lists, filters, AAA).
3. The packet is denied, and the security appliance drops the packet and logs the connection attempt.
If the outside user is attempting to attack the inside network, the security appliance employs many technologies to determine if a packet is valid for an already established session.
A DMZ User Attempts to Access an Inside Host Figure 15-5 shows a user in the DMZ attempting to access the inside network.
Figure 15-5 DMZ to Inside

The following steps describe how data moves through the security appliance (see Figure 15-5):
1. A user on the DMZ network attempts to reach an inside host. Because the DMZ does not have to route the traffic on the Internet, the private addressing scheme does not prevent routing.
2. The security appliance receives the packet and because it is a new session, the security appliance verifies if the packet is allowed according to the security policy (access lists, filters, AAA).
3. The packet is denied, and the security appliance drops the packet and logs the connection attempt.
Transparent Mode Overview Traditionally, a firewall is a routed hop and acts as a default gateway for hosts that connect to one of its screened subnets. A transparent firewall, on the other hand, is a Layer 2 firewall that acts like a "bump in the wire," or a "stealth firewall," and is not seen as a router hop to connected devices.
This section describes transparent firewall mode, and includes the following topics:
• Transparent Firewall Network
• Allowing Layer 3 Traffic
• Allowed MAC Addresses
• Passing Traffic Not Allowed in Routed Mode
• MAC Address vs. Route Lookups
• Using the Transparent Firewall in Your Network
• Transparent Firewall Guidelines
• Unsupported Features in Transparent Mode
• How Data Moves Through the Transparent Firewall
Transparent Firewall Network The security appliance connects the same network on its inside and outside interfaces. Because the firewall is not a routed hop, you can easily introduce a transparent firewall into an existing network.
Allowing Layer 3 Traffic IPv4 traffic is allowed through the transparent firewall automatically from a higher security interface to a lower security interface, without an access list. ARPs are allowed through the transparent firewall in both directions without an access list. ARP traffic can be controlled by ARP inspection. For Layer 3 traffic travelling from a low to a high security interface, an extended access list is required on the low security interface. See the "Adding an Extended Access List" section for more information.
Allowed MAC Addresses The following destination MAC addresses are allowed through the transparent firewall. Any MAC address not on this list is dropped.
•TRUE broadcast destination MAC address equal to FFFF.FFFF.FFFF
•IPv4 multicast MAC addresses from 0100.5E00.0000 to 0100.5EFE.FFFF
•IPv6 multicast MAC addresses from 3333.0000.0000 to 3333.FFFF.FFFF
•BPDU multicast address equal to 0100.0CCC.CCCD
•Appletalk multicast MAC addresses from 0900.0700.0000 to 0900.07FF.FFFF
Passing Traffic Not Allowed in Routed Mode In routed mode, some types of traffic cannot pass through the security appliance even if you allow it in an access list. The transparent firewall, however, can allow almost any traffic through using either an extended access list (for IP traffic) or an EtherType access list (for non-IP traffic).

Note The transparent mode security appliance does not pass CDP packets or IPv6 packets, or any packets that do not have a valid EtherType greater than or equal to 0x600. For example, you cannot pass IS-IS packets. An exception is made for BPDUs, which are supported.
For example, you can establish routing protocol adjacencies through a transparent firewall; you can allow OSPF, RIP, EIGRP, or BGP traffic through based on an extended access list. Likewise, protocols like HSRP or VRRP can pass through the security appliance.
Non-IP traffic (for example AppleTalk, IPX, BPDUs, and MPLS) can be configured to go through using an EtherType access list.
For features that are not directly supported on the transparent firewall, you can allow traffic to pass through so that upstream and downstream routers can support the functionality. For example, by using an extended access list, you can allow DHCP traffic (instead of the unsupported DHCP relay feature) or multicast traffic such as that created by IP/TV.
MAC Address vs. Route Lookups When the security appliance runs in transparent mode without NAT, the outgoing interface of a packet is determined by performing a MAC address lookup instead of a route lookup. Route statements can still be configured, but they only apply to security appliance-originated traffic. For example, if your syslog server is located on a remote network, you must use a static route so the security appliance can reach that subnet.
An exception to this rule is when you use voice inspections and the endpoint is at least one hop away from the security appliance. For example, if you use the transparent firewall between a CCM and an H.323 gateway, and there is a router between the transparent firewall and the H.323 gateway, then you need to add a static route on the security appliance for the H.323 gateway for successful call completion.
If you use NAT, then the security appliance uses a route lookup instead of a MAC address lookup. In some cases, you will need static routes. For example, if the real destination address is not directly-connected to the security appliance, then you need to add a static route on the security appliance for the real destination address that points to the downstream router.
Using the Transparent Firewall in Your Network Figure 15-6 shows a typical transparent firewall network where the outside devices are on the same subnet as the inside devices. The inside router and hosts appear to be directly connected to the outside router.
Figure 15-6 Transparent Firewall Network

Transparent Firewall Guidelines Follow these guidelines when planning your transparent firewall network:
•A management IP address is required; for multiple context mode, an IP address is required for each context.
Unlike routed mode, which requires an IP address for each interface, a transparent firewall has an IP address assigned to the entire device. The security appliance uses this IP address as the source address for packets originating on the security appliance, such as system messages or AAA communications.
The management IP address must be on the same subnet as the connected network. You cannot set the subnet to a host subnet (255.255.255.255).
You can configure an IP address for the Management 0/0 management-only interface. This IP address can be on a separate subnet from the main management IP address.
•The transparent security appliance uses an inside interface and an outside interface only. If your platform includes a dedicated management interface, you can also configure the management interface or subinterface for management traffic only.
In single mode, you can only use two data interfaces (and the dedicated management interface, if available) even if your security appliance includes more than two interfaces.
•Each directly connected network must be on the same subnet.
•Do not specify the security appliance management IP address as the default gateway for connected devices; devices need to specify the router on the other side of the security appliance as the default gateway.
•For multiple context mode, each context must use different interfaces; you cannot share an interface across contexts.
•For multiple context mode, each context typically uses a different subnet. You can use overlapping subnets, but your network topology requires router and NAT configuration to make it possible from a routing standpoint.
Unsupported Features in Transparent Mode Table 15-1 lists the features are not supported in transparent mode.

Table 15-1 Unsupported Features in Transparent Mode
Feature
Description
Dynamic DNS
—
DHCP relay
The transparent firewall can act as a DHCP server, but it does not support the DHCP relay commands. DHCP relay is not required because you can allow DHCP traffic to pass through using two extended access lists: one that allows DCHP requests from the inside interface to the outside, and one that allows the replies from the server in the other direction.
Dynamic routing protocols
You can, however, add static routes for traffic originating on the security appliance. You can also allow dynamic routing protocols through the security appliance using an extended access list.
IPv6
You also cannot allow IPv6 using an EtherType access list.
Multicast
You can allow multicast traffic through the security appliance by allowing it in an extended access list.
QoS
—
VPN termination for through traffic
The transparent firewall supports site-to-site VPN tunnels for management connections only. It does not terminate VPN connections for traffic through the security appliance. You can pass VPN traffic through the security appliance using an extended access list, but it does not terminate non-management connections. WebVPN is also not supported.

How Data Moves Through the Transparent Firewall Figure 15-7 shows a typical transparent firewall implementation with an inside network that contains a public web server. The security appliance has an access list so that the inside users can access Internet resources. Another access list lets the outside users access only the web server on the inside network.
Figure 15-7 Typical Transparent Firewall Data Path

This section describes how data moves through the security appliance, and includes the following topics:
• An Inside User Visits a Web Server
• An Inside User Visits a Web Server Using NAT
• An Outside User Visits a Web Server on the Inside Network
• An Outside User Attempts to Access an Inside Host
An Inside User Visits a Web Server Figure 15-8 shows an inside user accessing an outside web server.
Figure 15-8 Inside to Outside

The following steps describe how data moves through the security appliance (see Figure 15-8):
1. The user on the inside network requests a web page from www.example.com.
2. The security appliance receives the packet and adds the source MAC address to the MAC address table, if required. Because it is a new session, it verifies that the packet is allowed according to the terms of the security policy (access lists, filters, AAA).
For multiple context mode, the security appliance first classifies the packet according to a unique interface.
3. The security appliance records that a session is established.
4. If the destination MAC address is in its table, the security appliance forwards the packet out of the outside interface. The destination MAC address is that of the upstream router, 209.186.201.2.
If the destination MAC address is not in the security appliance table, the security appliance attempts to discover the MAC address by sending an ARP request and a ping. The first packet is dropped.
5. The web server responds to the request; because the session is already established, the packet bypasses the many lookups associated with a new connection.
6. The security appliance forwards the packet to the inside user.
An Inside User Visits a Web Server Using NAT Figure 15-8 shows an inside user accessing an outside web server.
Figure 15-9 Inside to Outside with NAT

The following steps describe how data moves through the security appliance (see Figure 15-8):
1. The user on the inside network requests a web page from www.example.com.
2. The security appliance receives the packet and adds the source MAC address to the MAC address table, if required. Because it is a new session, it verifies that the packet is allowed according to the terms of the security policy (access lists, filters, AAA).
For multiple context mode, the security appliance first classifies the packet according to a unique interface.
3. The security appliance translates the real address (10.1.2.27) to the mapped address 209.165.201.10.
Because the mapped address is not on the same network as the outside interface, then be sure the upstream router has a static route to the mapped network that points to the security appliance.
4. The security appliance then records that a session is established and forwards the packet from the outside interface.
5. If the destination MAC address is in its table, the security appliance forwards the packet out of the outside interface. The destination MAC address is that of the upstream router, 209.165.201.2.
If the destination MAC address is not in the security appliance table, the security appliance attempts to discover the MAC address by sending an ARP request and a ping. The first packet is dropped.
6. The web server responds to the request; because the session is already established, the packet bypasses the many lookups associated with a new connection.
7. The security appliance performs NAT by translating the mapped address to the real address, 10.1.2.27.
An Outside User Visits a Web Server on the Inside Network Figure 15-10 shows an outside user accessing the inside web server.
Figure 15-10 Outside to Inside

The following steps describe how data moves through the security appliance (see Figure 15-10):
1. A user on the outside network requests a web page from the inside web server.
2. The security appliance receives the packet and adds the source MAC address to the MAC address table, if required. Because it is a new session, it verifies that the packet is allowed according to the terms of the security policy (access lists, filters, AAA).
For multiple context mode, the security appliance first classifies the packet according to a unique interface.
3. The security appliance records that a session is established.
4. If the destination MAC address is in its table, the security appliance forwards the packet out of the inside interface. The destination MAC address is that of the downstream router, 209.186.201.1.
If the destination MAC address is not in the security appliance table, the security appliance attempts to discover the MAC address by sending an ARP request and a ping. The first packet is dropped.
5. The web server responds to the request; because the session is already established, the packet bypasses the many lookups associated with a new connection.
6. The security appliance forwards the packet to the outside user.
An Outside User Attempts to Access an Inside Host Figure 15-11 shows an outside user attempting to access a host on the inside network.
Figure 15-11 Outside to Inside

The following steps describe how data moves through the security appliance (see Figure 15-11):
1. A user on the outside network attempts to reach an inside host.
2. The security appliance receives the packet and adds the source MAC address to the MAC address table, if required. Because it is a new session, it verifies if the packet is allowed according to the terms of the security policy (access lists, filters, AAA).
For multiple context mode, the security appliance first classifies the packet according to a unique interface.
3. The packet is denied, and the security appliance drops the packet.
4. If the outside user is attempting to attack the inside network, the security appliance employs many technologies to determine if a packet is valid for an already established session.

network

Configuring IPSec and ISAKMP This chapter describes how to configure the IPSec and ISAKMP standards to build Virtual Private Networks. It includes the following sections:
• Tunneling Overview
• IPSec Overview
• Configuring ISAKMP
• Configuring Certificate Group Matching
• Configuring IPSec
• Clearing Security Associations
• Clearing Crypto Map Configurations
• Supporting the Nokia VPN Client
Tunneling Overview Tunneling makes it possible to use a public TCP/IP network, such as the Internet, to create secure connections between remote users and a private corporate network. Each secure connection is called a tunnel.
The security appliance uses the ISAKMP and IPSec tunneling standards to build and manage tunnels. ISAKMP and IPSec accomplish the following:
•Negotiate tunnel parameters
•Establish tunnels
•Authenticate users and data
•Manage security keys
•Encrypt and decrypt data
•Manage data transfer across the tunnel
•Manage data transfer inbound and outbound as a tunnel endpoint or router
The security appliance functions as a bidirectional tunnel endpoint. It can receive plain packets from the private network, encapsulate them, create a tunnel, and send them to the other end of the tunnel where they are unencapsulated and sent to their final destination. It can also receive encapsulated packets from the public network, unencapsulate them, and send them to their final destination on the private network.
IPSec Overview IPSec provides the most complete architecture for VPN tunnels, and it is perceived as the most secure protocol. IPSec provides authentication and encryption services to prevent unauthorized viewing or modification of data within your network or as it travels over an unprotected network, such as the public Internet. Our implementation of the IPSec standard uses the ESP security protocol to provide authentication, encryption, and anti-replay services.
The security appliance implements IPSec in two types of configurations:
•LAN-to-LAN configurations are between two IPSec security gateways, such as security appliance units or other protocol-compliant VPN devices. A LAN-to-LAN VPN connects networks in different geographic locations.
•Remote access configurations provide secure remote access for Cisco VPN clients, such as mobile users. A remote access VPN lets remote users securely access centralized network resources. The Cisco VPN client complies with the IPSec protocol and is specifically designed to work with the security appliance. However, the security appliance can establish IPSec connections with many protocol-compliant clients.
In IPSec LAN-to-LAN connections, the security appliance can function as initiator or responder. In IPSec remote access connections, the security appliance functions only as responder. Initiators propose SAs; responders accept, reject, or make counter-proposals—all in accordance with configured security association (SA) parameters. To establish a connection, both entities must agree on the SAs.
In IPSec terminology, a peer is a remote-access client or another secure gateway.
Configuring ISAKMP This section describes the Internet Key Exchange protocol which is also called the Internet Security Association and Key Management Protocol. The security appliance IKE commands use ISAKMP as a keyword, which this guide echoes. ISAKMP works with IPSec to make VPNs more scalable. This section includes the following topics:
• ISAKMP Overview
• Configuring ISAKMP Policies
• Enabling ISAKMP on the Outside Interface
• Disabling ISAKMP in Aggressive Mode
• Determining an ID Method for ISAKMP Peers
• Enabling IPSec over NAT-T
• Enabling IPSec over TCP
• Waiting for Active Sessions to Terminate Before Rebooting
• Alerting Peers Before Disconnecting
ISAKMP Overview IKE, also called ISAKMP, is the negotiation protocol that lets two hosts agree on how to build an IPSec security association. ISAKMP separates negotiation into two phases: Phase 1 and Phase 2.
Phase 1 creates the first tunnel, which protects later ISAKMP negotiation messages. Phase 2 creates the tunnel that protects data.
To set the terms of the ISAKMP negotiations, you create an ISAKMP policy, which includes the following:
•An authentication method, to ensure the identity of the peers.
•An encryption method, to protect the data and ensure privacy.
•A Hashed Message Authentication Codes (HMAC) method to ensure the identity of the sender, and to ensure that the message has not been modified in transit.
•A Diffie-Hellman group to determine the strength of the encryption-key-determination algorithm. The security appliance uses this algorithm to derive the encryption and hash keys.
•A limit to the time the security appliance uses an encryption key before replacing it.
Table 27-1 provides information about the ISAKMP policy keywords and their values.

Table 27-1 ISAKMP Policy Keywords for CLI Commands  
Command
Keyword
Meaning
Description
crypto isakmp policy authentication
rsa-sig
A digital certificate with keys generated by the RSA signatures algorithm
Specifies the authentication method the security appliance uses to establish the identity of each IPSec peer.
crack
Challenge/Response for Authenticated Cryptographic Keys
CRACK provides strong mutual authentication when the client authenticates using a legacy method such as RADIUS and the server uses public key authentication.
pre-share
(default)
Preshared keys
Preshared keys do not scale well with a growing network but are easier to set up in a small network.
crypto isakmp policy encryption
des
3des (default)
56-bit DES-CBC
168-bit Triple DES
Specifies the symmetric encryption algorithm that protects data transmitted between two IPSec peers. The default is 168-bit Triple DES.
aes
aes-192
aes-256
The Advanced Encryption Standard supports key lengths of 128, 192, 256 bits.
crypto isakmp policy hash
sha (default)
SHA-1 (HMAC variant)
Specifies the hash algorithm used to ensure data integrity. It ensures that a packet comes from where it says it comes from, and that it has not been modified in transit.
md5
MD5 (HMAC variant)
The default is SHA-1. MD5 has a smaller digest and is considered to be slightly faster than SHA-1. A successful (but extremely difficult) attack against MD5 has occurred; however, the HMAC variant IKE uses prevents this attack.
crypto isakmp policy group
1
Group 1 (768-bit)
Specifies the Diffie-Hellman group identifier, which the two IPSec peers use to derive a shared secret without transmitting it to each other.
With the exception of Group 7, the lower the Diffie-Hellman group no., the less CPU time it requires to execute. The higher the Diffie-Hellman group no., the greater the security.
Cisco VPN Client Version 3.x or higher requires a minimum of Group 2. (If you configure DH Group 1, the Cisco VPN Client cannot connect.)
AES support is available on security appliances licensed for VPN-3DES only. To support the large key sizes required by AES, ISAKMP negotiation should use Diffie-Hellman (DH) Group 5.
Designed for devices with low processing power, such as PDAs and mobile telephones, Group 7 provides the greatest security. The Certicom Movian Client requires Group 7.
2 (default)
Group 2 (1024-bit)
5
Group 5 (1536-bit)
7
Group 7 (Elliptical curve field size is 163 bits.)
crypto isakmp policy lifetime
integer value
(86400 = default)
120 to 2147483647 seconds
Specifies the SA lifetime. The default is 86,400 seconds or 24 hours. As a general rule, a shorter lifetime provides more secure ISAKMP negotiations (up to a point). However, with shorter lifetimes, the security appliance sets up future IPSec SAs more quickly.

Each configuration supports a maximum of 20 ISAKMP policies, each with a different set of values. Assign a unique priority to each policy you create. The lower the priority number, the higher the priority.
When ISAKMP negotiations begin, the peer that initiates the negotiation sends all of its policies to the remote peer, and the remote peer tries to find a match. The remote peer checks all of the peer's policies against each of its configured policies in priority order (highest priority first) until it discovers a match.
A match exists when both policies from the two peers contain the same encryption, hash, authentication, and Diffie-Hellman parameter values, and when the remote peer policy specifies a lifetime less than or equal to the lifetime in the policy the initiator sent. If the lifetimes are not identical, the security appliance uses the shorter lifetime. If no acceptable match exists, ISAKMP refuses negotiation and the SA is not established.
There is an implicit trade-off between security and performance when you choose a specific value for each parameter. The level of security the default values provide is adequate for the security requirements of most organizations. If you are interoperating with a peer that supports only one of the values for a parameter, your choice is limited to that value.

Note New ASA configurations do not have a default ISAKMP policy.
Configuring ISAKMP Policies To configure ISAKMP policies, in global configuration mode, use the crypto isakmp policy command with its various arguments. The syntax for ISAKMP policy commands is as follows:
crypto isakmp policy priority attribute_name [attribute_value | integer]
You must include the priority in each of the ISAKMP commands. The priority number uniquely identifies the policy, and determines the priority of the policy in ISAKMP negotiations.
To enable and configure ISAKMP, complete the following steps, using the examples as a guide:

Note If you do not specify a value for a given policy parameter, the default value applies.
Step 1 Specify the encryption algorithm. The default is Triple DES. This example sets encryption to DES.
crypto isakmp policy priority encryption [aes | aes-192 | aes-256 | des | 3des]


For example:
hostname(config)# crypto isakmp policy 2 encryption des


Step 2 Specify the hash algorithm. The default is SHA-1. This example configures MD5.
crypto isakmp policy priority hash [md5 | sha]


For example:
hostname(config)# crypto isakmp policy 2 hash md5


Step 3 Specify the authentication method. The default is preshared keys. This example configures RSA signatures.
crypto isakmp policy priority authentication [pre-share | crack | rsa-sig]


For example:
hostname(config)# crypto isakmp policy 2 authentication rsa-sig


Step 4 Specify the Diffie-Hellman group identifier. The default is Group 2. This example configures Group 5.
crypto isakmp policy priority group [1 | 2 | 5 | 7]


For example:
hostname(config)# crypto isakmp policy 2 group    5



Step 5 Specify the SA lifetime. This examples sets a lifetime of 4 hours (14400 seconds). The default is 86400 seconds (24 hours).
crypto isakmp policy priority lifetime seconds


For example:
hostname(config)# crypto isakmp policy 2 lifetime  14400


Enabling ISAKMP on the Outside Interface You must enable ISAKMP on the interface that terminates the VPN tunnel. Typically this is the outside, or public interface.
To enable ISAKMP, enter the following command:
crypto isakmp enable interface-name


For example:
hostname(config)# crypto isakmp enable outside
Disabling ISAKMP in Aggressive Mode Phase 1 ISAKMP negotiations can use either main mode or aggressive mode. Both provide the same services, but aggressive mode requires only two exchanges between the peers totaling 3 messages, rather than three exchanges totaling 6 messages. Aggressive mode is faster, but does not provide identity protection for the communicating parties. Therefore, the peers must exchange identification information prior to establishing a secure SA. Aggressive mode is enabled by default.
•Main mode is slower, using more exchanges, but it protects the identities of the communicating peers.
•Aggressive mode is faster, but does not protect the identities of the peers.
To disable ISAKMP in aggressive mode, enter the following command:
crypto isakmp am-disable


For example:
hostname(config)# crypto isakmp am-disable
If you have disabled aggressive mode, and want to revert to back to it, use the no form of the command. For example:
hostname(config)# no crypto isakmp am-disable

Note Disabling aggressive mode prevents Cisco VPN clients from using preshared key authentication to establish tunnels to the security appliance. However, they may use certificate-based authentication (that is, ASA or RSA) to establish tunnels.
Determining an ID Method for ISAKMP Peers During Phase I ISAKMP negotiations the peers must identify themselves to each other. You can choose the identification method from the following options:

Address	Uses the IP addresses of the hosts exchanging ISAKMP identity information.
Automatic	Determines ISAKMP negotiation by connection type: •IP address for preshared key. •Cert Distinguished Name for certificate authentication.
Hostname	Uses the fully qualified domain name of the hosts exchanging ISAKMP identity information (default). This name comprises the hostname and the domain name.
Key ID	Uses the string the remote peer uses to look up the preshared key.

The security appliance uses the Phase I ID to send to the peer. This is true for all VPN scenarios except LAN-to-LAN connections in main mode that authenticate with preshared keys.
The default setting is hostname.
To change the peer identification method, enter the following command:
crypto isakmp identity {address | hostname | key-id id-string
| auto}


For example, the following command sets the peer identification method to automatic:
hostname(config)# crypto isakmp identity auto
Enabling IPSec over NAT-T NAT-T lets IPSec peers establish a connection through a NAT device. It does this by encapsulating IPSec traffic in UDP datagrams, using port 4500, thereby providing NAT devices with port information. NAT-T auto-detects any NAT devices, and only encapsulates IPSec traffic when necessary. This feature is disabled by default.
With the exception of the home zone on the Cisco ASA 5505, the security appliance can simultaneously support standard IPSec, IPSec over TCP, NAT-T, and IPSec over UDP, depending on the client with which it is exchanging data. When both NAT-T and IPSec over UDP are enabled, NAT-T takes precedence. IPSec over TCP, if enabled, takes precedence over all other connection methods.
When you enable NAT-T, the security appliance automatically opens port 4500 on all IPSec enabled interfaces.
The security appliance supports multiple IPSec peers behind a single NAT/PAT device operating in one of the following networks, but not both:
•LAN-to-LAN
•Remote access
In a mixed environment, the remote access tunnels fail the negotiation because all peers appear to be coming from the same public IP address, that of the NAT device. Also, remote access tunnels fail in a mixed environment because they often use the same name as the LAN-to-LAN tunnel group (that is, the IP address of the NAT device). This match can cause negotiation failures among multiple peers in a mixed LAN-to-LAN and remote access network of peers behind the NAT device.
Using NAT-T To use NAT-T, you must perform the following tasks:
Step 1 Enter the following command to enable IPSec over NAT-T globally on the security appliance.
crypto isakmp nat-traversal natkeepalive
natkeepalive is in the range 10 to 3600 seconds. The default is 20 seconds.
For example, enter the following command to enable NAT-T and set the keepalive to one hour.
hostname(config)# crypto isakmp nat-traversal 3600


Step 2 Select the "before-fragmentation" option for the IPSec fragmentation policy.
This option lets traffic travel across NAT devices that do not support IP fragmentation. It does not impede the operation of NAT devices that do support IP fragmentation.
Enabling IPSec over TCP IPSec over TCP enables a Cisco VPN client to operate in an environment in which standard ESP or ISAKMP cannot function, or can function only with modification to existing firewall rules. IPSec over TCP encapsulates both the ISAKMP and IPSec protocols within a TCP-like packet, and enables secure tunneling through both NAT and PAT devices and firewalls. This feature is disabled by default.

Note This feature does not work with proxy-based firewalls.
IPSec over TCP works with remote access clients. You enable it globally, and it works on all ISAKMP enabled interfaces. It is a client to security appliance feature only. It does not work for LAN-to-LAN connections.
The security appliance can simultaneously support standard IPSec, IPSec over TCP, NAT-Traversal, and IPSec over UDP, depending on the client with which it is exchanging data. IPSec over TCP, if enabled, takes precedence over all other connection methods.
The VPN 3002 hardware client, which supports one tunnel at a time, can connect using standard IPSec, IPSec over TCP, NAT-Traversal, or IPSec over UDP.
You enable IPSec over TCP on both the security appliance and the client to which it connects.
You can enable IPSec over TCP for up to 10 ports that you specify. If you enter a well-known port, for example port 80 (HTTP) or port 443 (HTTPS), the system displays a warning that the protocol associated with that port no longer works on the public interface. The consequence is that you can no longer use a browser to manage the security appliance through the public interface. To solve this problem, reconfigure the HTTP/HTTPS management to different ports.
The default port is 10000.
You must configure TCP port(s) on the client as well as on the security appliance. The client configuration must include at least one of the ports you set for the security appliance.
To enable IPSec over TCP globally on the security appliance, enter the following command:
crypto isakmp ipsec-over-tcp [port port 1...port0]


This example enables IPSec over TCP on port 45:
hostname(config)# crypto isakmp ctcp port 45
Waiting for Active Sessions to Terminate Before Rebooting You can schedule a security appliance reboot to occur only when all active sessions have terminated voluntarily. This feature is disabled by default.
To enable waiting for all active sessions to voluntarily terminate before the security appliance reboots, enter the following command:
crypto isakmp reload-wait


For example:
hostname(config)# crypto isakmp reload-wait
Use the reload command to reboot the security appliance. If you set the reload-wait command, you can use the reload quick command to override the reload-wait setting. The reload and reload-wait commands are available in privileged EXEC mode; neither includes the isakmp prefix.
Alerting Peers Before Disconnecting Remote access or LAN-to-LAN sessions can drop for several reasons, such as: a security appliance shutdown or reboot, session idle timeout, maximum connection time exceeded, or administrator cut-off.
The security appliance can notify qualified peers (in LAN-to-LAN configurations), Cisco VPN clients and VPN 3002 hardware clients of sessions that are about to be disconnected. The peer or client receiving the alert decodes the reason and displays it in the event log or in a pop-up pane. This feature is disabled by default.
Qualified clients and peers include the following:
•Security appliances with Alerts enabled.
•Cisco VPN clients running version 4.0 or later software (no configuration required).
•VPN 3002 hardware clients running version 4.0 or later software, and with Alerts enabled.
•VPN 3000 series concentrators running version 4.0 or later software, with Alerts enabled.
To enable disconnect notification to IPSec peers, enter the crypto isakmp disconnect-notify command.


For example:
hostname(config)# crypto isakmp disconnect-notify
Configuring Certificate Group Matching Tunnel groups define user connection terms and permissions. Certificate group matching lets you match a user to a tunnel group using either the Subject DN or Issuer DN of the user certificate.
To match users to tunnel groups based on these fields of the certificate, you must first create rules that define a matching criteria, and then associate each rule with the desired tunnel group.
To create a certificate map, use the crypto ca certificate map command. To define a
tunnel group, use the tunnel-group command.
You must also configure a certificate group matching policy that sets one of the following methods for identifying the permission groups of certificate users:
•Match the group from the rules
•Match the group from the organizational unit (OU) field
•Use a default group for all certificate users
You can use any or all of these methods.
Creating a Certificate Group Matching Rule and Policy To configure the policy and rules by which certificate-based ISAKMP sessions map to tunnel groups, and to associate the certificate map entries with tunnel groups, enter the tunnel-group-map command in global configuration mode.
The syntax follows:
tunnel-group-map enable {rules | ou | ike-id | peer ip}
tunnel-group-map [rule-index]enable policy

policy

Specifies the policy for deriving the tunnel group name from the certificate. Policy can be one of the following: ike-id—Indicates that if a tunnel-group is not determined based on a rule lookup or taken from the ou, then the certificate-based ISAKMP sessions are mapped to a tunnel group based on the content of the phase1 ISAKMP ID. ou—Indicates that if a tunnel-group is not determined based on a rule lookup, then use the value of the OU in the subject distinguished name (DN). peer-ip—Indicates that if a tunnel-group is not determined based on a rule lookup or taken from the ou or ike-id methods, then use the peer IP address. rules—Indicates that the certificate-based ISAKMP sessions are mapped to a tunnel group based on the certificate map associations configured by this command.

rule index

(Optional) Refers to parameters specified by the crypto ca certificate map command. The values are 1 to 65535.

Be aware of the following:
•You can invoke this command multiple times as long as each invocation is unique and you do not reference a map index more than once.
•Rules cannot be longer than 255 characters.
•You can assign multiple rules to the same group. To do that, you add the rule priority and group first. Then you define as many criteria statements as you need for each group. When multiple rules are assigned to the same group, a match results for the first rule that tests true.
•Create a single rule if you want to require all criteria to match before assigning a user to a specific tunnel group. Requiring all criteria to match is equivalent to a logical AND operation. Alternatively, create one rule for each criterion if you want to require that only one match before assigning a user to a specific tunnel group. Requiring only one criterion to match is equivalent to a logical OR operation.
The following example enables mapping of certificate-based ISAKMP sessions to a tunnel group based on the content of the phase1 ISAKMP ID:
hostname(config)# tunnel-group-map enable ike-id
hostname(config)#


The following example enables mapping of certificate-based ISAKMP sessions to a tunnel group based on the IP address of the peer:
hostname(config)# tunnel-group-map enable peer-ip
hostname(config)#


The following example enables mapping of certificate-based ISAKMP sessions based on the organizational unit (OU) in the subject distinguished name (DN):
hostname(config)# tunnel-group-map enable ou
hostname(config)#


The following example enables mapping of certificate-based ISAKMP sessions based on established rules:
hostname(config)# tunnel-group-map enable rules
hostname(config)#
Using the Tunnel-group-map default-group Command This command specifies a default tunnel group to use when the configuration does not specify a tunnel group.
The syntax is tunnel-group-map [rule-index]default-group tunnel-group-name where the rule-index is the priority for the rule, and tunnel-group name must be for a tunnel group that already exists.
Configuring IPSec This section provides background information about IPSec and describes the procedures required to configure the security appliance when using IPSec to implement a VPN. It contains the following topics:
• Understanding IPSec Tunnels
• Understanding Transform Sets
• Defining Crypto Maps
• Applying Crypto Maps to Interfaces
• Using Interface Access Lists
• Changing IPSec SA Lifetimes
• Creating a Basic IPSec Configuration
• Using Dynamic Crypto Maps
• Providing Site-to-Site Redundancy
• Viewing an IPSec Configuration
Understanding IPSec Tunnels IPSec tunnels are sets of SAs that the security appliance establishes between peers. The SAs define the protocols and algorithms to apply to sensitive data, and also specify the keying material the peers use. IPSec SAs control the actual transmission of user traffic. SAs are unidirectional, but are generally established in pairs (inbound and outbound).
The peers negotiate the settings to use for each SA. Each SA consists of the following:
•Transform sets
•Crypto maps
•Access lists
•Tunnel groups
•Prefragmentation policies
Understanding Transform Sets A transform set is a combination of security protocols and algorithms that define how the security appliance protects data. During IPSec SA negotiations, the peers must identify a transform set that is the same at both peers. The security appliance then applies the matching transform set to create an SA that protects data flows in the access list for that crypto map.
The security appliance tears down the tunnel if you change the definition of the transform set used to create its SA. See " Clearing Security Associations" for further information.

Note If you clear or delete the only element in a transform set, the security appliance automatically removes the crypto map references to it.
Defining Crypto Maps Crypto maps define the IPSec policy to be negotiated in the IPSec SA. They include the following:
•Access list to identify the packets that the IPSec connection permits and protects.
•Peer identification
•Local address for the IPSec traffic (See "Applying Crypto Maps to Interfaces" for more details.)
•Up to six transform sets with which to attempt to match the peer security settings.
A crypto map set consists of one or more crypto maps that have the same map name. You create a crypto map set when you create its first crypto map. The following command syntax creates or adds to a crypto map:
crypto map map-name seq-num match address access-list-name


You can continue to enter this command to add crypto maps to the crypto map set. In the following example, "mymap" is the name of the crypto map set to which you might want to add crypto maps:
crypto map mymap 10 match address 101


The sequence number (seq-num) shown in the syntax above distinguishes one crypto map from another one with the same name. The sequence number assigned to a crypto map also determines its priority among the other crypto maps within a crypto map set. The lower the sequence number, the higher the priority. After you assign a crypto map set to an interface, the security appliance evaluates all IP traffic passing through the interface against the crypto maps in the set, beginning with the crypto map with the lowest sequence number.
The ACL assigned to a crypto map consists of all of the ACEs that have the same access-list-name, as shown in the following command syntax:
access-list access-list-name {deny | permit} ip source source-netmask destination destination-netmask


Each ACL consists of one or more ACEs that have the same access-list-name. You create an ACL when you create its first ACE. The following command syntax creates or adds to an ACL:
access-list access-list-name {deny | permit} ip source source-netmask destination destination-netmask
In the following example, the security appliance applies the IPSec protections assigned to the crypto map to all traffic flowing from the 10.0.0.0 subnet to the 10.1.1.0 subnet.
access-list 101 permit ip 10.0.0.0 255.255.255.0 10.1.1.0 255.255.255.0
The crypto map that matches the packet determines the security settings used in the SA negotiations. If the local security appliance initiates the negotiation, it uses the policy specified in the static crypto map to create the offer to send to the specified peer. If the peer initiates the negotiation, the security appliance attempts to match the policy to a static crypto map, and if that fails, any dynamic crypto maps in the crypto map set, to decide whether to accept or reject the peer offer.
For two peers to succeed in establishing an SA, they must have at least one compatible crypto map. To be compatible, a crypto map must meet the following criteria:
•The crypto map must contain compatible crypto ACLs (for example, mirror image ACLs). If the responding peer uses dynamic crypto maps, so must the security appliance as a requirement to apply IPSec.
•Each crypto map identifies the other peer (unless the responding peer uses dynamic crypto maps).
•The crypto maps have at least one transform set in common.
You can apply only one crypto map set to a single interface. Create more than one crypto map for a particular interface on the security appliance if any of the following conditions exist:
•You want specific peers to handle different data flows.
•You want different IPSec security to apply to different types of traffic.
For example, create a crypto map and assign an ACL to identify traffic between two subnets and assign one transform set. Create another crypto map with a different ACL to identify traffic between another two subnets and apply a transform set with different VPN parameters.
If you create more than one crypto map for an interface, specify a sequence number (seq-num) for each map entry to determine its priority within the crypto map set.
Each ACE contains a permit or deny statement. Table 27-2 explains the special meanings of permit and deny ACEs in ACLs applied to crypto maps.

Table 27-2 Special Meanings of Permit and Deny in Crypto Access Lists Applied to Outbound Traffic  
Result of Crypto Map Evaluation
Response
Match criterion in an ACE containing a permit statement
Halt further evaluation of the packet against the remaining ACEs in the crypto map set, and evaluate the packet security settings against those in the transform sets assigned to the crypto map. After matching the security settings to those in a transform set, the security appliance applies the associated IPSec settings. Typically for outbound traffic, this means that it decrypts, authenticates, and routes the packet.
Match criterion in an ACE containing a deny statement
Interrupt further evaluation of the packet against the remaining ACEs in the crypto map under evaluation, and resume evaluation against the ACEs in the next crypto map, as determined by the next seq-num assigned to it.
Fail to match all tested permit ACEs in the crypto map set
Route the packet without encrypting it.

ACEs containing deny statements filter out outbound traffic that does not require IPSec protection (for example, routing protocol traffic). Therefore, insert initial deny statements to filter outbound traffic that should not be evaluated against permit statements in a crypto access list.
For an inbound, encrypted packet, the security appliance uses the source address and ESP SPI to determine the decryption parameters. After the security appliance decrypts the packet, it compares the inner header of the decrypted packet to the permit ACEs in the ACL associated with the packet SA. If the inner header fails to match the proxy, the security appliance drops the packet. It the inner header matches the proxy, the security appliance routes the packet.
When comparing the inner header of an inbound packet that was not encrypted, the security appliance ignores all deny rules because they would prevent the establishment of a Phase 2 SA.

Note To route inbound, unencrypted traffic as clear text, insert deny ACEs before permit ACEs.
Figure 27-1 shows an example LAN-to-LAN network of security appliances.

Figure 27-1 Effect of Permit and Deny ACEs on Traffic (Conceptual Addresses)

The simple address notation shown in this figure and used in the following explanation is an abstraction. An example with real IP addresses follows the explanation.
The objective in configuring Security Appliances A, B, and C in this example LAN-to-LAN network is to permit tunneling of all traffic originating from one of the hosts shown in Figure 27-1 and destined for one of the other hosts. However, because traffic from Host A.3 contains sensitive data from the Human Resources department, it requires strong encryption and more frequent rekeying than the other traffic. So we want to assign a special transform set for traffic from Host A.3.
To configure Security Appliance A for outbound traffic, we create two crypto maps, one for traffic from Host A.3 and the other for traffic from the other hosts in Network A, as shown in the following example:
Crypto Map Seq_No_1
deny packets from A.3 to B
deny packets from A.3 to C
permit packets from A to B
permit packets from A to C
Crypto Map Seq_No_2
permit packets from A.3 to B
permit packets from A.3 to C


After creating the ACLs, you assign a transform set to each crypto map to apply the required IPSec to each matching packet.
Cascading ACLs involves the insertion of deny ACEs to bypass evaluation against an ACL and resume evaluation against a subsequent ACL in the crypto map set. Because you can associate each crypto map with different IPSec settings, you can use deny ACEs to exclude special traffic from further evaluation in the corresponding crypto map, and match the special traffic to permit statements in another crypto map to provide or require different security. The sequence number assigned to the crypto ACL determines its position in the evaluation sequence within the crypto map set.
Figure 27-2 shows the cascading ACLs created from the conceptual ACEs above. The meaning of each symbol in the figure follows.

	Crypto map within a crypto map set.
	(Gap in a straight line) Exit from a crypto map when a packet matches an ACE.
	Packet that fits the description of one ACE. Each size ball represents a different packet matching the respective ACE in the figure. The differences in size merely represent differences in the source and destination of each packet.
	Redirection to the next crypto map in the crypto map set.
	Response when a packet either matches an ACE or fails to match all of the permit ACEs in a crypto map set.

Figure 27-2 Cascading ACLs in a Crypto Map Set

Security Appliance A evaluates a packet originating from Host A.3 until it matches a permit ACE and attempts to assign the IPSec security associated with the crypto map. Whenever the packet matches a deny ACE, the security appliance ignores the remaining ACEs in the crypto map and resumes evaluation against the next crypto map, as determined by the sequence number assigned to it. So in the example, if Security Appliance A receives a packet from Host A.3, it matches the packet to a deny ACE in the first crypto map and resumes evaluation of the packet against the next crypto map. When it matches the packet to the permit ACE in that crypto map, it applies the associated IPSec security (strong encryption and frequent rekeying).
To complete the security appliance configuration in the example network, we assign mirror crypto maps to Security Appliances B and C. However, because security appliances ignore deny ACEs when evaluating inbound, encrypted traffic, we can omit the mirror equivalents of the deny A.3 B and deny A.3 C ACEs, and therefore omit the mirror equivalents of Crypto Map 2. So the configuration of cascading ACLs in Security Appliances B and C is unnecessary.
Table 27-3 shows the ACLs assigned to the crypto maps configured for all three security appliances in Figure 27-1.

Table 27-3 Example Permit and Deny Statements (Conceptual)
Security Appliance A
Security Appliance B
Security Appliance C
Crypto Map
Sequence
No.
ACE Pattern
Crypto Map
Sequence
No.
ACE Pattern
Crypto Map
Sequence
No.
ACE Pattern
1
deny A.3 B
1
permit B A
1
permit C A
deny A.3 C
permit A B
permit A C
permit B C
permit C B
2
permit A.3 B
permit A.3 C

Figure 27-3 maps the conceptual addresses shown in Figure 27-1 to real IP addresses.

Figure 27-3 Effect of Permit and Deny ACEs on Traffic (Real Addresses)

The tables that follow combine the IP addresses shown in Figure 27-3 to the concepts shown in Table 27-3. The real ACEs shown in these tables ensure that all IPSec packets under evaluation within this network receive the proper IPSec settings.

Table 27-4 Example Permit and Deny Statements for Security Appliance A
Security Appliance
Crypto Map
Sequence
No.
ACE Pattern
Real ACEs
A
1
deny A.3 B
deny 192.168.3.3 255.255.255.192 192.168.12.0 255.255.255.248
deny A.3 C
deny 192.168.3.3 255.255.255.192 192.168.201.0 255.255.255.224
permit A B
permit 192.168.3.0 255.255.255.192 192.168.12.0 255.255.255.248
permit A C
permit 192.168.3.0 255.255.255.192 192.168.201.0 255.255.255.224
2
permit A.3 B
permit 192.168.3.3 255.255.255.192 192.168.12.0 255.255.255.248
permit A.3 C
permit 192.168.3.3 255.255.255.192 192.168.201.0 255.255.255.224
B
None needed
permit B A
permit 192.168.12.0 255.255.255.248 192.168.3.0 255.255.255.192
permit B C
permit 192.168.12.0 255.255.255.248 192.168.201.0 255.255.255.224
C
None needed
permit C A
permit 192.168.201.0 255.255.255.224 192.168.3.0 255.255.255.192
permit C B
permit 192.168.201.0 255.255.255.224 192.168.12.0 255.255.255.248

You can apply the same reasoning shown in the example network to use cascading ACLs to assign different security settings to different hosts or subnets protected by a Cisco security appliance.

Note By default, the security appliance does not support IPSec traffic destined for the same interface from which it enters. (Names for this type of traffic include U-turn, hub-and-spoke, and hairpinning.) However, you might want IPSec to support U-turn traffic. To do so, insert an ACE to permit traffic to and from the network. For example, to support U-turn traffic on Security Appliance B, add a conceptual "permit B B" ACE to ACL1. The actual ACE would be as follows:
permit 192.168.12.0 255.255.255.248 192.168.12.0 255.255.255.248
Applying Crypto Maps to Interfaces You must assign a crypto map set to each interface through which IPSec traffic flows. The security appliance supports IPSec on all interfaces. Assigning the crypto map set to an interface instructs the security appliance to evaluate all the traffic against the crypto map set and to use the specified policy during connection or SA negotiation.
Assigning a crypto map to an interface also initializes run-time data structures, such as the SA database and the security policy database. Reassigning a modified crypto map to the interface resynchronizes the run-time data structures with the crypto map configuration. Also, adding new peers through the use of new sequence numbers and reassigning the crypto map does not tear down existing connections.
Using Interface Access Lists By default, the security appliance lets IPSec packets bypass interface ACLs. If you want to apply interface access lists to IPSec traffic, use the no form of the sysopt connection permit-ipsec command.
The crypto map access list bound to the outgoing interface either permits or denies IPSec packets through the VPN tunnel. IPSec authenticates and deciphers packets that arrive from an IPSec tunnel, and subjects them to evaluation against the ACL associated with the tunnel.
Access lists define which IP traffic to protect. For example, you can create access lists to protect all IP traffic between two subnets or two hosts. (These access lists are similar to access lists used with the access-group command. However, with the access-group command, the access list determines which traffic to forward or block at an interface.)
Before the assignment to crypto maps, the access lists are not specific to IPSec. Each crypto map references the access lists and determines the IPSec properties to apply to a packet if it matches a permit in one of the access lists.
Access lists assigned to IPSec crypto maps have four primary functions:
•Select outbound traffic to be protected by IPSec (permit = protect).
•Trigger an ISAKMP negotiation for data travelling without an established SA.
•Process inbound traffic to filter out and discard traffic that should have been protected by IPSec.
•Determine whether to accept requests for IPSec SAs when processing IKE negotiation from the peer. (Negotiation applies only to ipsec-isakmp crypto map entries.) The peer must "permit" a data flow associated with an ipsec-isakmp crypto map command entry to ensure acceptance during negotiation.
Regardless of whether the traffic is inbound or outbound, the security appliance evaluates traffic against the access lists assigned to an interface. You assign IPSec to an interface as follows:
Step 1 Create the access lists to be used for IPSec.
Step 2 Map the lists to one or more crypto maps, using the same crypto map name.
Step 3 Map the transform sets to the crypto maps to apply IPSec to the data flows.
Step 4 Apply the crypto maps collectively as a "crypto map set" by assigning the crypto map name they share to the interface.
In Figure 27-4, IPSec protection applies to traffic between Host 10.0.0.1 and Host 10.2.2.2 as the data exits the outside interface on Security Appliance A toward Host 10.2.2.2.
Figure 27-4 How Crypto Access Lists Apply to IPSec

Security Appliance A evaluates traffic from Host 10.0.0.1 to Host 10.2.2.2, as follows:
•source = host 10.0.0.1
•dest = host 10.2.2.2
Security Appliance A also evaluates traffic from Host 10.2.2.2 to Host 10.0.0.1, as follows:
•source = host 10.2.2.2
•dest = host 10.0.0.1
The first permit statement that matches the packet under evaluation determines the scope of the IPSec SA.

Note If you delete the only element in an access list, the security appliance also removes the associated crypto map.
If you modify an access list currently referenced by one or more crypto maps, use the crypto map interface command to reinitialize the run-time SA database. See the crypto map command for more information.
We recommend that for every crypto access list specified for a static crypto map that you define at the local peer, you define a "mirror image" crypto access list at the remote peer. The crypto maps should also support common transforms and refer to the other system as a peer. This ensures correct processing of IPSec by both peers.

Note Every static crypto map must define an access list and an IPSec peer. If either is missing, the crypto map is incomplete and the security appliance drops any traffic that it has not already matched to an earlier, complete crypto map. Use the show conf command to ensure that every crypto map is complete. To fix an incomplete crypto map, remove the crypto map, add the missing entries, and reapply it.
We discourage the use of the any keyword to specify source or destination addresses in crypto access lists because they cause problems. We strongly discourage the permit any any command statement because it does the following:
•Protects all outbound traffic, including all protected traffic sent to the peer specified in the corresponding crypto map.
•Requires protection for all inbound traffic.
In this scenario, the security appliance silently drops all inbound packets that lack IPSec protection.
Be sure that you define which packets to protect. If you use the any keyword in a permit statement, preface it with a series of deny statements to filter out traffic that would otherwise fall within that permit statement that you do not want to protect.
Changing IPSec SA Lifetimes You can change the global lifetime values that the security appliance uses when negotiating new IPSec SAs. You can override these global lifetime values for a particular crypto map.
IPSec SAs use a derived, shared, secret key. The key is an integral part of the SA; they time out together to require the key to refresh. Each SA has two lifetimes: "timed" and "traffic-volume." An SA expires after the respective lifetime and negotiations begin for a new one. The default lifetimes are 28,800 seconds (eight hours) and 4,608,000 kilobytes (10 megabytes per second for one hour).
If you change a global lifetime, the security appliance drops the tunnel. It uses the new value in the negotiation of subsequently established SAs.
When a crypto map does not have configured lifetime values and the security appliance requests a new SA, it inserts the global lifetime values used in the existing SA into the request sent to the peer. When a peer receives a negotiation request, it uses the smaller of either the lifetime value the peer proposes or the locally configured lifetime value as the lifetime of the new SA.
The peers negotiate a new SA before crossing the lifetime threshold of the existing SA to ensure that a new SA is ready when the existing one expires. The peers negotiate a new SA when about 5 to 15 percent of the lifetime of the existing SA remains.
Creating a Basic IPSec Configuration You can create basic IPSec configurations with static or dynamic crypto maps.
To create a basic IPSec configuration using a static crypto map, perform the following steps:
Step 1 To create an access list to define the traffic to protect, enter the following command:
access-list access-list-name {deny | permit} ip source source-netmask destination destination-netmask


For example:
access-list 101 permit ip 10.0.0.0 255.255.255.0 10.1.1.0 255.255.255.0


In this example, the permit keyword causes all traffic that matches the specified conditions to be protected by crypto.
Step 2 To configure a transform set that defines how to protect the traffic, enter the following command:
crypto ipsec transform-set transform-set-name
transform1
[tcansform2, transform3]


For example:
crypto ipsec transform-set myset1 esp-des esp-sha-hmac
crypto ipsec transform-set myset2 esp-3des esp-sha-hmac
crypto ipsec transform-set aes_set esp-md5-hmac esp-aes-256


In this example, "myset1" and "myset2" and "aes_set" are the names of the transform sets.
Step 3 To create a crypto map, perform the following steps:
a. Assign an access list to a crypto map:
crypto map map-name seq-num match address access-list-name


In the following example, "mymap" is the name of the crypto map set. The map set sequence number 10, which is used to rank multiple entries within one crypto map set. The lower the sequence number, the higher the priority.
crypto map mymap 10 match address 101


In this example, the access list named 101 is assigned to crypto map "mymap."
b. Specify the peer to which the IPSec protected traffic can be forwarded:
crypto map map-name seq-num set peer ip-address


For example:
crypto map mymap 10 set peer 192.168.1.100


The security appliance sets up an SA with the peer assigned the IP address 192.168.1.100. Specify multiple peers by repeating this command.
c. Specify which transform sets are allowed for this crypto map. List multiple transform sets in order of priority (highest priority first). You can specify up to 11 transform sets in a crypto map.
crypto map map-name seq-num set transform-set transform-set-name1
[transform-set-name2, ...transform-set-name6]


For example:
crypto map mymap 10 set transform-set myset1 myset2


In this example, when traffic matches access list 101, the SA can use either "myset1" (first priority) or "myset2" (second priority) depending on which transform set matches the transform set of the peer.
d. (Optional) Specify an SA lifetime for the crypto map if you want to override the global lifetime.
crypto map map-name seq-num set security-association lifetime {seconds seconds | kilobytes kilobytes}


For example:
crypto map mymap 10 set security-association lifetime seconds 2700
This example shortens the timed lifetime for the crypto map "mymap 10" to 2700 seconds
(45 minutes). The traffic volume lifetime is not changed.
e. (Optional) Specify that IPSec require perfect forward secrecy when requesting new SA for this crypto map, or require PFS in requests received from the peer:
crypto map map-name seq-num set pfs [group1 | group2 | group5 | group7]


For example:
crypto map mymap 10 set pfs group2


This example requires PFS when negotiating a new SA for the crypto map "mymap 10." The security appliance uses the 1024-bit Diffie-Hellman prime modulus group in the new SA.
Step 4 Apply a crypto map set to an interface for evaluating IPSec traffic:
crypto map map-name interface interface-name


For example:
crypto map mymap interface outside


In this example, the security appliance evaluates the traffic going through the outside interface against the crypto map "mymap" to determine whether it needs to be protected.
Using Dynamic Crypto Maps A dynamic crypto map is a crypto map without all of the parameters configured. It acts as a policy template where the missing parameters are later dynamically learned, as the result of an IPSec negotiation, to match the peer requirements. The security appliance applies a dynamic crypto map to let a peer negotiate a tunnel if its IP address is not already identified in a static crypto map. This occurs with the following types of peers:
•Peers with dynamically assigned public IP addresses.
Both LAN-to-LAN and remote access peers can use DHCP to obtain a public IP address. The security appliance uses this address only to initiate the tunnel.
•Peers with dynamically assigned private IP addresses.
Peers requesting remote access tunnels typically have private IP addresses assigned by the headend. Generally, LAN-to-LAN tunnels have a predetermined set of private networks that are used to configure static maps and therefore used to establish IPSec SAs.
As an administrator configuring static crypto maps, you might not know the IP addresses that are dynamically assigned (via DHCP or some other method), and you might not know the private IP addresses of other clients, regardless of how they were assigned. VPN clients typically do not have static IP addresses; they require a dynamic crypto map to allow IPSec negotiation to occur. For example, the headend assigns the IP address to a Cisco VPN client during IKE negotiation, which the client then uses to negotiate IPSec SAs.

Note A dynamic crypto map requires only the transform-set parameter.
Dynamic crypto maps can ease IPSec configuration and we recommend them for use in networks where the peers are not always predetermined. Use dynamic crypto maps for Cisco VPN clients (such as mobile users) and routers that obtain dynamically assigned IP addresses.

Tip Use care when using the any keyword in permit entries in dynamic crypto maps. If the traffic covered by such a permit entry could include multicast or broadcast traffic, insert deny entries for the appropriate address range into the access list. Remember to insert deny entries for network and subnet broadcast traffic, and for any other traffic that IPSec should not protect.
Dynamic crypto maps work only to negotiate SAs with remote peers that initiate the connection. The security appliance cannot use dynamic crypto maps to initiate connections to a remote peer. With a dynamic crypto map, if outbound traffic matches a permit entry in an access list and the corresponding SA does not yet exist, the security appliance drops the traffic.
A crypto map set may include a dynamic crypto map. Dynamic crypto map sets should be the lowest priority crypto maps in the crypto map set (that is, they should have the highest sequence numbers) so that the security appliance evaluates other crypto maps first. It examines the dynamic crypto map set only when the other (static) map entries do not match.
Similar to static crypto map sets, a dynamic crypto map set consists of all of the dynamic crypto maps with the same dynamic-map-name. The dynamic-seq-num differentiates the dynamic crypto maps in a set. If you configure a dynamic crypto map, insert a permit ACL to identify the data flow of the IPSec peer for the crypto access list. Otherwise the security appliance accepts any data flow identity the peer proposes.

Caution Do not assign static (default) routes for traffic to be tunneled to a security appliance interface configured with a dynamic crypto map set. To identify the traffic that should be tunneled, add the ACLs to the dynamic crypto map. Use care to identify the proper address pools when configuring the ACLs associated with remote access tunnels. Use Reverse Route Injection to install routes only after the tunnel is up.
The procedure for using a dynamic crypto map entry is the same as the basic configuration described in " Creating a Basic IPSec Configuration," except that instead of creating a static crypto map, you create a dynamic crypto map entry. You can also combine static and dynamic map entries within a single crypto map set.
Create a crypto dynamic map entry as follows:
Step 1 (Optional) Assign an access list to a dynamic crypto map:
crypto dynamic-map dynamic-map-name dynamic-seq-num match address access-list-name


This determines which traffic should be protected and not protected.
For example:
crypto dynamic-map dyn1 10 match address 101


In this example, access list 101 is assigned to dynamic crypto map "dyn1." The map sequence number is 10.
Step 2 Specify which transform sets are allowed for this dynamic crypto map. List multiple transform sets in order of priority (highest priority first).
crypto dynamic-map dynamic-map-name dynamic-seq-num set transform-set transform-set-name1, [transform-set-name2, ...transform-set-name9]


For example:
crypto dynamic-map dyn 10 set transform-set myset1 myset2


In this example, when traffic matches access list 101, the SA can use either "myset1" (first priority) or "myset2" (second priority), depending on which transform set matches the transform sets of the peer.
Step 3 (Optional) Specify the SA lifetime for the crypto dynamic map entry if you want to override the global lifetime value:
crypto dynamic-map dynamic-map-name
dynamic-seq-num set security-association lifetime {seconds seconds
| kilobytes kilobytes}


For example:
crypto dynamic-map dyn1 10 set security-association lifetime seconds 2700


This example shortens the timed lifetime for dynamic crypto map "dyn1 10" to 2700 seconds
(45 minutes). The time volume lifetime is not changed.
Step 4 (Optional) Specify that IPSec ask for PFS when requesting new SAs for this dynamic crypto map, or should demand PFS in requests received from the peer:
crypto dynamic-map dynamic-map-name dynamic-seq-num set pfs [group1 | group2 | group5 | group7]


For example:
crypto dynamic-map dyn1 10 set pfs group5


Step 5 Add the dynamic crypto map set into a static crypto map set.
Be sure to set the crypto maps referencing dynamic maps to be the lowest priority entries (highest sequence numbers) in a crypto map set.
crypto map   map-name seq-num ipsec-isakmp dynamic  dynamic-map-name


For example:
crypto map  mymap 200 ipsec-isakmp dynamic dyn1


Providing Site-to-Site Redundancy You can define multiple peers by using crypto maps to provide redundancy. This configuration is useful for site-to-site VPNs.
If one peer fails, the security appliance establishes a tunnel to the next peer associated with the crypto map. It sends data to the peer that it has successfully negotiated with, and that peer becomes the "active" peer. The "active" peer is the peer that the security appliance keeps trying first for follow-on negotiations until a negotiation fails. At that point the security appliance goes on to the next peer. The security appliance cycles back to the first peer when all peers associated with the crypto map have failed.
Viewing an IPSec Configuration Table 27-5 lists commands you can enter to view information about your IPSec configuration.

Table 27-5 Commands to View IPSec Configuration Information  
Command
Purpose
show running-configuration crypto
Displays the entire crypto configuration, including IPSec, crypto maps, dynamic crypto maps, and ISAKMP.
show running-config crypto ipsec
Displays the complete IPSec configuration.
show running-config crypto isakmp
Displays the complete ISAKMP configuration.
  show running-config crypto map
Displays the complete crypto map configuration.
show running-config crypto dynamic-map
Displays the dynamic crypto map configuration.
show all crypto map
View all of the configuration parameters, including those with default values.

Clearing Security Associations Certain configuration changes take effect only during the negotiation of subsequent SAs. If you want the new settings to take effect immediately, clear the existing SAs to reestablish them with the changed configuration. If the security appliance is actively processing IPSec traffic, clear only the portion of the SA database that the configuration changes affect. Reserve clearing the full SA database for large-scale changes, or when the security appliance is processing a small amount of IPSec traffic.
Table 27-6 lists commands you can enter to clear and reinitialize IPSec SAs.

Table 27-6 Commands to Clear and Reinitialize IPSec SAs  
Command
Purpose
clear configure crypto
Removes an entire crypto configuration, including IPSec, crypto maps, dynamic crypto maps, and ISAKMP.
clear configure crypto ca trustpoint
Removes all trustpoints.
clear configure crypto dynamic-map
Removes all dynamic crypto maps. Includes keywords that let you remove specific dynamic crypto maps.
clear configure crypto map
Removes all crypto maps. Includes keywords that let you remove specific crypto maps.
clear configure crypto isakmp
Removes the entire ISAKMP configuration.
clear configure crypto isakmp policy
Removes all ISAKMP policies or a specific policy.
clear crypto isakmp sa
Removes the entire ISAKMP SA database.

Clearing Crypto Map Configurations The clear configure crypto command includes arguments that let you remove elements of the crypto configuration, including IPSec, crypto maps, dynamic crypto maps, CA trustpoints, all certificates, certificate map configurations, and ISAKMP.
Be aware that if you enter the clear configure crypto command without arguments, you remove the entire crypto configuration, including all certificates.
For more information, see the clear configure crypto command in the Cisco Security Appliance Command Reference.
Supporting the Nokia VPN Client The security appliance supports connections from Nokia VPN Clients on Nokia 92xx Communicator series phones using the Challenge/Response for Authenticated Cryptographic Keys (CRACK) protocol. CRACK is ideal for mobile IPSec-enabled clients that use legacy authentication techniques instead of digital certificates. It provides mutual authentication when the client uses a legacy based secret-key authentication technique such as RADIUS and the gateway uses public-key authentication.
The Nokia back-end services must be in place to support both Nokia clients and the CRACK protocol. This requirement includes the Nokia Security Services Manager (NSSM) and Nokia databases as shown in Figure 27-5.
Figure 27-5 Nokia 92xx Communicator Service Requirement

To support the Nokia VPN Client, perform the following step on the security appliance:
•Enable CRACK authentication using the crypto isakmp policy priority authentication command with the crack keyword in global configuration mode. For example:
hostname(config)#crypto isakmp policy 2
hostname(config-isakmp-policy)#authentication crack


If you are using digital certificates for client authentication, perform the following additional steps:
Step 1 Configure the trustpoint and remove the requirement for a fully qualified domain name. The trustpoint might be NSSM or some other CA. In this example, the trustpoint is named CompanyVPNCA:
hostname(config)#crypto ca trustpoint CompanyVPNCA
hostname(config-ca-trustpoint)# fqdn none


Step 2 To configure the identity of the ISAKMP peer, perform one of the following steps:
a. Use the crypto isakmp identity command with the hostname keyword. For example:
hostname(config)#crypto isakmp identity hostname


-or-
b. Use the crypto isakmp identity command with the auto keyword to configure the identity to be automatically determined from the connection type. For example:
hostname(config)#crypto isakmp identity auto

Note If you use the crypto isakmp identity auto command, you must be sure that the DN attribute order in the client certificate is CN, OU, O, C, St, L.
To learn more about the Nokia services required to support the CRACK protocol on Nokia clients, and to ensure they are installed and configured properly, contact your local Nokia representative.

network

Applying QoS Policies

--------------------------------------------------------------------------------

This chapter describes how to apply QoS policies, and includes the following sections:

• Overview

• QoS Concepts

• Implementing QoS

• Identifying Traffic for QoS

• Defining a QoS Policy Map

• Applying Rate Limiting

• Activating the Service Policy

• Applying Low Latency Queueing

• Configuring QoS

• Viewing QoS Configuration

• Viewing QoS Statistics

Overview
Have you ever participated in a long-distance phone call that involved a satellite connection? The conversation might be interrupted with brief, but perceptible, gaps at odd intervals. Those gaps are the time, called the latency, between the arrival of packets being transmitted over the network. Some network traffic, such as voice and streaming video, cannot tolerate long latency times. Quality of Service (QoS) is a network feature that lets you give priority to these types of traffic.

As the Internet community of users upgrades their access points from modems to high-speed broadband connections like DSL and cable, the likelihood increases that at any given time, a single user might be able to absorb most, if not all, of the available bandwidth, thus starving the other users. To prevent any one user or site-to-site connection from consuming more than its fair share of bandwidth, QoS provides a policing feature that regulates the maximum bandwidth that any user can use.

QoS refers to the capability of a network to provide better service to selected network traffic over various technologies for the best overall services with limited bandwidth of the underlying technologies.

The primary goal of QoS in the security appliance is to provide rate limiting on selected network traffic for both individual flow and VPN tunnel flow to ensure that all traffic gets its fair share of limited bandwidth. A flow can be defined in a number of ways. In the security appliance, QoS can apply to a combination of source and destination IP addresses, source and destination port number, and the TOS byte of the IP header.

QoS Concepts
QoS is a traffic-management strategy that lets you allocate network resources for both mission-critical and normal data, based on the type of network traffic and the priority you assign to that traffic. In short, QoS ensures unimpeded priority traffic and provides the capability of rate-limiting (policing) default traffic.

For example, video and voice over IP (VoIP) are increasingly important for interoffice communication between geographically dispersed sites, using the infrastructure of the Internet as the transport mechanism. Firewalls are key to securing networks by controlling access, which includes inspecting VoIP protocols. QoS is the focal point to provide clear, uninterrupted voice and video communications, while still providing a basic level of service for all other traffic passing through the device.

For voice and video to traverse IP networks in a secure, reliable, and toll-quality manner, QoS must be enabled at all points of the network. Implementing QoS lets you:

•Simplify network operations by collapsing all data, voice, and video network traffic onto a single backbone using similar technologies.

•Enable new network applications, such as integrated call center applications and video-based training, that can help differentiate enterprises in their respective market spaces and increase productivity.

•Control resource use by controlling which traffic receives which resources. For example, you can ensure that the most important, time-critical traffic receives the network resources (available bandwidth and minimum delay) it needs, and that other applications using the link get their fair share of service without interfering with mission-critical traffic.

QoS provides maximum rate control, or policing, for tunneled traffic for each individual user tunnel and every site-to-site tunnel. In this release, there is no minimum bandwidth guarantee.

The security appliance can police individual user traffic within a LAN-to-LAN tunnel by configuring class-maps that are not associated with the tunnel, but whose traffic eventually passes through the LAN-to-LAN tunnel. The traffic before the LAN-to-LAN tunnel can then be specifically policed as it passes through the tunnel and is policed again to the aggregate rate applied to the tunnel.

The security appliance achieves QoS by allowing two types of traffic queues for each interface: a low-latency queue (LLQ) and a default queue. Only the default traffic is subject to rate limiting.

Because QoS can consume large amounts of resources, which could degrade security appliance performance, QoS is disabled by default.



--------------------------------------------------------------------------------

Note You must consider that in an ever-changing network environment, QoS is not a one-time deployment, but an ongoing, essential part of network design.


--------------------------------------------------------------------------------

Implementing QoS
In general, provisioning QoS policies requires the following steps:

1. Specifying traffic classes.

2. Associating actions with each traffic class to formulate policies.

3. Activating the policies.

The specification of a classification policy—that is, the definition of traffic classes—is separate from the specification of the policies that act on the results of the classification.

A traffic class is a set of traffic that is identifiable by its packet content. For example, TCP traffic with a port value of 23 might be classified as a Telnet traffic class.

An action is a specific activity taken to protect information or resources, in this case to perform QoS functions. An action is typically associated with a specific traffic class.

Configuring a traditional QoS policy for the security appliance consists of the following steps:

•Defining traffic classes (class-map command).

•Associating policies and actions with each class of traffic (policy-map command).

•Attaching policies to logical or physical interfaces (service-policy command).



--------------------------------------------------------------------------------

Note For detailed configuration steps, see the "Configuring QoS" section.


--------------------------------------------------------------------------------

The class-map command defines a named object representing a class of traffic, specifying the packet matching criteria that identifies packets that belong to this class. The basic form of the command is as follows:

class-map class-map-name-1
        match match-criteria-1
class-map class-map-name-n
        match match-criteria-n
The policy-map command defines a named object that represents a set of policies to be applied to a set of traffic classes. An example of such a policy is policing the traffic class to some maximum rate. The basic form of the command is as follows:

policy-map policy-map-name
        class class-map-name-1
                policy-1
                policy-n
        class class-map-name-n
                policy-m
                policy-m+1
The service-policy command attaches a policy-map and its associated policies to a target, named interface.



--------------------------------------------------------------------------------

Note QoS-related policies under policy-map-name apply only to the outbound traffic, not to the inbound traffic of the named interface.


--------------------------------------------------------------------------------

The command also indicates whether the policies apply to packets coming from or sent to the target. For example, an output policy (applied to packets exiting an interface) is applied as follows:

hostname(config)# service-policy policy-map-name interface outside
In addition, if you are differentiating between priority traffic and best-effort traffic, you must define a low-latency queue (priority-queue command) on each named, physical interface transmitting prioritized traffic.

The following example enables a default priority-queue with the default queue-limit and tx-ring-limit:

priority-queue name-interface
The following sections explain each of these uses in more detail.

Identifying Traffic for QoS
The class-map command classifies a set of traffic with which QoS actions are associated. You can use various types of match criteria to classify traffic. The match commands identify the traffic included in the traffic class for a class map. They include different criteria to define the traffic included in a class-map. Define a traffic class using the class-map global configuration command as part of configuring a security feature using Modular Policy Framework. From class-map configuration mode, you can define the traffic to include in the class using the match command.

After a traffic class is applied to an interface, packets received on that interface are compared to the criteria defined by the match statements in the class map. If the packet matches the specified criteria, it is included in the traffic class and is subjected to any actions associated with that traffic class. Packets that do not match any of the criteria in any traffic class are assigned to the default traffic class.

One such criterion is access-list. For example, in the following sequence, the class-map command classifies all non-tunneled TCP traffic, using an access-list named tcp_traffic:

hostname(config)# access-list tcp_traffic permit tcp any any
hostname(config)# class-map tcp_traffic
hostname(config-cmap)# match access-list tcp_traffic
When a packet is matched against a class-map, the result is either a match or a no-match.

In the following example, other, more specific match criteria are used for classifying traffic for specific, security-related tunnel groups. These specific match criteria stipulate that a match on tunnel-group (in this case, the previously-defined Tunnel-Group-1) is required as the first match characteristic to classify traffic for a specific tunnel, and it allows for an additional match line to classify the traffic (IP differential services code point, expedited forwarding).

hostname(config)# class-map TG1-voice
hostname(config-cmap)# match tunnel-group Tunnel-Group-1
hostname(config-cmap)# match dscp ef
In the following example, the class-map command classifies both tunneled and non-tunneled traffic according to the traffic type:

hostname(config)# access-list tunneled extended permit ip 10.10.34.0 255.255.255.0 20.20.10.0 255.255.255.0
hostname(config)# access-list non-tunneled extended permit tcp any any
hostname(config)# tunnel-group tunnel-grp1 type IPSec_L2L
hostname(config)# class-map browse
hostname(config-cmap)# description "This class-map matches all non-tunneled tcp traffic."
hostname(config-cmap)# match access-list non-tunneled
hostname(config-cmap)# class-map TG1-voice
hostname(config-cmap)# description "This class-map matches all dscp ef traffic for tunnel-grp 1."
hostname(config-cmap)# match dscp ef
hostname(config-cmap)# match tunnel-group tunnel-grp1
hostname(config-cmap)# class-map TG1-BestEffort
hostname(config-cmap)# description "This class-map matches all best-effort traffic for tunnel-grp1."
hostname(config-cmap)# match tunnel-group tunnel-grp1
hostname(config-cmap)# match flow ip destination-address
The following example shows a way of policing a flow within a tunnel, provided the classed traffic is not specified as a tunnel, but does go through the tunnel. In this example, 192.168.10.10 is the address of the host machine on the private side of the remote tunnel, and the access list is named "host-over-l2l". By creating a class-map (named "host-specific"), you can then police the "host-specific" class before the LAN-to-LAN connection polices the tunnel. In this example, the "host-specific" traffic is rate-limited before the tunnel, then the tunnel is rate-limited:

hostname(config)# access-list host-over-l2l extended permit ip any host 192.168.10.10
hostname(config)# class-map host-specific
hostname(config-cmap)# match access-list host-over-l2l
The following table summarizes the match command criteria available and relevant to QoS. For the full list of all match commands and their syntax, see Cisco Security Appliance Command Reference:


Command  Description  
match access-list
Matches, by name or number, access list traffic within a class map.

match any
Identifies traffic that matches any of the criteria in the class map.

match dscp
Matches the IETF-defined DSCP value (in an IP header) in a class map. You can specify up to 64 different dscp values, defining the class as composed of packets that match any of the specified values.

match flow ip destination-address
Enables flow-based policy actions. The criteria to define flow is the destination IP address. All traffic going to a unique IP destination address is considered a flow. Policy action is applied to each flow instead of the entire class of traffic. This command always accompanies match tunnel group. For remote-access VPNs, this command applies to each remote-access host flow. For LAN-to-LAN VPNs, this command applies to the single aggregated VPN flow identified by the local and remote tunnel address pair.

match port
Specifies the TCP/UDP ports as the comparison criteria for packets received on that interface.

match precedence
Matches the precedence value represented by the TOS byte in the IP header. You can specify up to 8 different precedence values, defining the class as composed of packets that match any of the specified values.

match rtp
Matches traffic that uses a specific RTP port within a specified range. The allowed range is targeted at capturing applications likely to be using RTP. The packet matches the defined class only if the UDP port falls within the specified range, inclusive, and the port number is an even number.

match tunnel group
Matches every tunnel within the specified tunnel group.





In addition to the user-defined classes, a system-defined class named class-default also exists. This class-default represents all packets that do not match any of the user-defined classes, so that policies can be defined for these packets.

Defining a QoS Policy Map
The policy-map command configures various policies, such as security policies or QoS policies. A policy is an association of a traffic class, specified by a class command, and one or more actions. This section specifically deals with using the policy-map command to define the QoS policies for one or more classes of packets.

When you enter a policy-map command you enter the policy-map configuration mode, and the prompt changes to indicate this. In this mode, you can enter class and description commands. A policy-map command can specify multiple policies. The maximum number of policy maps is 64.

After entering the policy-map command, you then enter a class command to specify the classification of the packet traffic. The class command configures QoS policies for the class of traffic specified in the given class-map. A traffic class is a set of traffic that is identifiable by its packet content. For example, TCP traffic with a port value of 23 can be classified as a Telnet traffic class. The class commands are differentiated by their previously named and constructed class-map designations, and the associated actions follow immediately after.

The security appliance evaluates class-maps in the order in which they were entered in the policy-map configuration. It classifies a packet to the first class-map that matches the packet.



--------------------------------------------------------------------------------

Note The order in which different types of actions in a policy-map are performed is independent of the order in which the actions appear in the command descriptions in this document.


--------------------------------------------------------------------------------

The priority command provides low-latency queuing for delay-sensitive traffic, such as voice. This command selects all packets that match the associated class (TG1-voice in the previous example) and sends them to the low latency queue for priority processing.

Applying Rate Limiting
Every user Bandwidth Limiting Traffic stream (BLT) can participate in maximum bandwidth limiting; that is, strict policing, which rate-limits the individual user default traffic to some maximum rate. This prevents any one individual user BLTs from overwhelming any other. LLQ traffic, however, is marked and processed downstream in a priority queue. LLQ traffic is not rate-limited.

Policing is a way of ensuring that no traffic exceeds the maximum rate (bits/second) that you configure, thus ensuring that no one traffic flow can take over the entire resource. You use the police command to specify the maximum rate (that is, the rate limit for this traffic flow); this is a value in the range 8000-2000000000, specifying the maximum speed (bits per second) allowed.

You also specify what action, drop or transmit, to take for traffic that conforms to the limit and for traffic that exceeds the limit.



--------------------------------------------------------------------------------

Note You can specify the drop action, but it is not functional. The action is always to transmit, except when the rate is exceeded, and even then, the action is to throttle the traffic to the maximum allowable speed.


--------------------------------------------------------------------------------

The police command also configures the largest single burst of traffic allowed. A burst value in the range 1000-512000000 specifies the maximum number of instantaneous bytes allowed in a sustained burst before throttling to the conforming rate value.



--------------------------------------------------------------------------------

Note Policing can apply in both the input and output directions.


--------------------------------------------------------------------------------

You cannot enable both priority and policing together.

If a service policy is applied or removed from an interface that has existing VPN client/LAN-to-LAN or non-tunneled traffic already established, the QoS policy is not applied or removed from the traffic stream. To apply or remove the QoS policy for such connections, you must clear (that is, drop) the connections and re-establish them.



--------------------------------------------------------------------------------

Note When policing is specified in the default class map, class-default, the police values of class-default are applied to the aggregated LAN-to-LAN VPN flow if there is no police command defined for tunnel-group of LAN-to-LAN VPN. In other words, the policing values of class-default are never applied to the individual flow of a LAN-to-LAN VPN that exists before encryption.


--------------------------------------------------------------------------------

The following example builds on the configuration developed in the previous section. As in the previous example, there are two named class-maps: tcp_traffic and TG1-voice. Adding a third class-map:

hostname(config)# class-map TG1-best-effort
hostname(config-cmap)# match tunnel-group Tunnel-Group-1
hostname(config-cmap)# match flow ip destination-address
provides a basis for defining a tunneled and non-tunneled QoS policy, as follows, which creates a simple QoS policy for tunneled and non-tunneled traffic, assigning packets of the class TG1-voice to the low latency queue and setting rate limits on the tcp_traffic and TG1-best-effort traffic flows.



--------------------------------------------------------------------------------

Note "Best effort" does not guarantee reliable packet delivery, in that it does not use a sophisticated acknowledgement system. It does, however, make a "best effort" to deliver packets to the destination.


--------------------------------------------------------------------------------

In this example, the maximum rate for traffic of the tcp_traffic class is 56,000 bits/second and a maximum burst size of 10,500 bytes per second. For the TC1-BestEffort class, the maximum rate is 200,000 bits/second, with a maximum burst of 37,500 bytes/second. Traffic in the TC1-voice class has no policed maximum speed or burst rate because it belongs to a priority class:

hostname(config)# policy-map qos
hostname(config-pmap)# class tcp_traffic
hostname(config-pmap-c)# police output 56000 10500
hostname(config-pmap-c)# class TG1-voice
hostname(config-pmap-c)# priority
hostname(config-pmap-c)# class TG1-best-effort
hostname(config-pmap-c)# police output 200000 37500
hostname(config-pmap-c)# class class-default
hostname(config-pmap-c)# police output 1000000 37500


--------------------------------------------------------------------------------

Note You can have up to 256 policy-maps, and up to 256 classes in a policy map. The maximum number of classes in all policy maps together is 256. For any class-map, you can have only one match statement associated with it, with the exception of a tunnel class. For a tunnel class, an additional match tunnel-group statement is allowed.

The class class-default always exists. It does not need to be declared.


--------------------------------------------------------------------------------

Activating the Service Policy
The service-policy command activates a policy-map command globally on all interfaces or on a targeted interface. An interface can be a virtual (vlan) interface or a physical interface. Only one global policy-map is allowed. If you specify the keyword interface and an interface name, the policy-map applies only to that interface. An interface policy-map inherits rules from the global policy-map. For rules that overlap with the global policy map, the interface policy rules will be applied. Only one interface policy-map can be applied to an interface at any one time.

In general, a service-policy command can be applied to any interface that can be defined by the nameif command.

Using the policy-map example in the previous section, the following service-policy command activates the policy-map "qos," defined in the previous section, for traffic on the outside interface:

hostname(config)# service-policy qos interface outside
Applying Low Latency Queueing
The security appliance allows two classes of traffic: low latency queuing (LLQ) for higher priority, latency-sensitive traffic (such as voice and video) and best effort, the default, for all other traffic. These two queues are built into the system. The security appliance recognizes QoS priority traffic and enforces appropriate QoS policies.

Because queues are not of infinite size, they can fill and overflow. When a queue is full, any additional packets cannot get into the queue and are dropped. This is tail drop. To avoid having the queue fill up, you can use the queue-limit command to increase the queue buffer size.

You can configure the low latency (priority) queue to fine-tune the maximum number of packets allowed into the transmit queue (using the tx-ring-limit command) and to size the depth of the priority queue (using the queue-limit command). This lets you control the latency and robustness of the priority queuing.



--------------------------------------------------------------------------------

Note The upper limit of the range of values for the queue-limit and tx-ring-limit commands is determined dynamically at run time. To view this limit, enter help or ? on the command line. The key determinants are the memory needed to support the queues and the memory available on the device. The range of queue-limit values is 0 through 2048 packets. The range of tx-ring-limit values is 3 through 128 packets on the PIX platform and 3 to 256 packets on the ASA platform.


--------------------------------------------------------------------------------

Configuring Priority Queuing
You identify high priority traffic by using the priority command in Class mode. This command instructs the security appliance to mark as high priority the traffic selected by the class map.

For priority queuing to occur, you must create a priority queue for named, physical interfaces that transmit high priority traffic. To enable a priority queue on an interface, use the priority-queue command in global configuration mode. You can apply one priority-queue command to each physical interface defined by the nameif command. All other traffic is delivered on a best-effort basis.

In general, you can apply a priority-queue command to any physical interface that can be defined by the nameif command. You cannot apply a priority-queue command to a VLAN interface. The priority-queue command enters priority-queue mode, as shown by the prompt, which lets you configure the maximum number of packets allowed in the transmit queue and the size of the priority queue.



--------------------------------------------------------------------------------

Note You cannot enable both priority queuing and policing together. In other words, only packets with normal priority can be policed; packets with high priority are not policed.


--------------------------------------------------------------------------------

Sizing the Priority Queue
The size that you specify for the priority queue affects both the low latency queue and the best-effort queue. The queue-limit command specifies a maximum number of packets that can be queued to a priority queue before it drops data. This limit must be in the range of 0 through 2048 packets.

Reducing Queue Latency
The tx-ring-limit command lets you configure the maximum number of packets (that is, the depth) allowed to be queued in the Ethernet transmit driver ring at any given time. This allows for fine-tuning the transmit queue to reduce latency and offer better performance through the transmit driver. This limit must be in the range 3 through 128 packets on the PIX platform, with a limit of 256 packets on the ASA platform.

The default queue-limit is the number of average, 256-byte packets that the specified interface can transmit in a 500-ms interval, with an upper limit of 2048 packets. A packet that stays more than 500 ms in a network node might trigger a timeout in the end-to-end application. Such a packet can be discarded in each network node.

The default tx-ring-limit is the number of maximum 1550-byte packets that the specified interface can transmit in a 10-ms interval. This guarantees that the hardware-based transmit ring imposes no more than 10-ms of extra latency for a high-priority packet.

The following example establishes a priority queue on interface "outside" (the GigabitEthernet0/1 interface), with the default queue-limit and tx-ring-limit.

hostname(config)# priority-queue outside
The following example establishes a priority queue on the interface "outside" (the GigabitEthernet0/1 interface), sets the queue-limit to 2048 packets, and sets the tx-ring-limit to 256:

hostname(config)# priority-queue outside
hostname(config-priority-queue)# queue-limit 2048
hostname(config-priority-queue)# tx-ring-limit 256


--------------------------------------------------------------------------------

Note When priority queuing is enabled, the security appliance empties all packets in higher priority queues before transmitting packets in lower priority queues.


--------------------------------------------------------------------------------

Configuring QoS
The following procedure provides steps for configuring a traffic class, a policy map, and a service policy that implement QoS policing (rate limiting) or priority queuing. In addition, for priority queuing, it includes steps for enabling priority queues on interfaces.

The number of traffic classes, policy maps, and service policies needed to implement QoS varies depending upon the requirements of your network. Analyze your network and determine how many traffic classes, policy maps, and service policies needed on the security appliance you are configuring, and then use this procedure as applicable to your QoS deployment.

To configure QoS policing and priority queuing, perform the following steps:


--------------------------------------------------------------------------------

Step 1 Determine which traffic you want to police or mark for priority queuing. For a detailed discussion of identifying QoS traffic, see the "Identifying Traffic for QoS" section.

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

hostname(config)# class-map class_map_name
hostname(config-cmap)#
where class_map_name is the name of the traffic class. When you enter the class-map command, the CLI enters class map configuration mode.

Step 3 Identify the traffic you determined in Step 1. To do so, use a match command. For a detailed discussion of identifying QoS traffic, see the "Identifying Traffic for QoS" section.

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

hostname(config)# access-list acl-name any any tcp eq port_number_1
hostname(config)# access-list acl-name any any tcp eq port_number_2
hostname(config)# class-map class_map_name
hostname(config-cmap)# match access-list acl-name
If you need to identify a single port, use the match port command, as follows:

hostname(config-cmap)# match port {tcp | udp} port_number
where port_number is the destination port of traffic that you want to configure the security appliance to police or mark for priority queuing.

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

hostname(config-cmap)# match port {tcp | udp} range begin_port_number end_port_number
where begin_port_number is the lowest port in the range of ports and end_port_number is the highest port.

Step 4 Create a policy map or modify an existing policy map that you want to use to apply policing or priority queuing to the traffic identified in Step 2. For more information about QoS policy maps, see the "Defining a QoS Policy Map" section.

Use the policy-map command, as follows:

hostname(config-cmap)# policy-map policy_map_name
hostname(config-pmap)#
where policy_map_name is the name of the policy map. The CLI enters the policy map configuration mode and the prompt changes accordingly.

Step 5 Specify the class map, created in Step 2, that identifies the traffic to be policed or marked for priority queuing. Use the class command to do so, as follows:

hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)#
where class_map_name is the name of the class map you created in Step 2. The CLI enters the policy map class configuration mode and the prompt changes accordingly.

Step 6 Configure the action for the class. You can either mark the traffic class as priority traffic or specify rate limiting for the traffic class. Do one of the following:

•If you want the traffic selected by the class map to be marked as priority traffic, enter the priority command.

hostname(config-pmap-c)# priority


--------------------------------------------------------------------------------

Note Priority queuing does not occur automatically to traffic marked as priority. To enable priority queuing, you must complete Step 8 also, which enables the priority queues.


--------------------------------------------------------------------------------

For details about priority queuing, see the "Applying Low Latency Queueing" section and the priority command page in the Cisco Security Appliance Command Reference.

•If you want the security appliance to police the traffic selected by the class map, enter the police command.

hostname(config-pmap-c)# police [output] conform-rate [conform-burst] [conform-action
[drop | transmit] [exceed-action {drop | transmit}]]
For details about the use of the police command, see the "Applying Rate Limiting" section and the police command page in the Cisco Security Appliance Command Reference.

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

hostname(config-pmap-c)# service-policy policy_map_name [global | interface interface_ID]
hostname(config)#
where policy_map_name is the policy map you configured in Step 4. If you want to apply the policy map to traffic on all the interfaces, use the global option. If you want to apply the policy map to traffic on a specific interface, use the interface interface_ID option, where interface_ID is the name assigned to the interface with the nameif command.

The security appliance begins policing traffic and marking traffic for priority queuing, as specified.

Step 8 If in Step 6 you entered the priority command, you must enable priority queues on interfaces before the security appliance performs priority queuing.

For each interface on which you want the security appliance to perform priority queuing, perform the following steps:

a. Enter the priority-queue command:

hostname(config)# priority-queue interface
hostname(config-priority-queue)#
where interface is the name assigned to the physical interface whose priority queue you want to enable. VLAN interfaces do not support priority queuing. The CLI enters the Priority-queue configuration mode and the prompt changes accordingly

b. (Optional) If you want to specify a non-default maximum number of priority packets that can be queued, enter the queue-limit command, as follows:

hostname(config-priority-queue)# queue-limit number-of-packets
The default queue size is 2048 packets.

c. (Optional) If you want specify a non-default maximum number of packets allowed into the transmit queue, enter the tx-ring-limit command, as follows:

hostname(config-priority-queue)# tx-ring-limit number-of-packets
The default transmit queue size is 128 packets.

On the interfaces you enabled priority queuing, the security appliance begins performing priority queuing.


--------------------------------------------------------------------------------

The following example creates class maps for high priority (voice) and best effort traffic for a previously configured tunnel group, named "tunnel-grp1". The "qos" policy map includes the police command for the best effort and the default traffic classes and the priority command for the voice class. The service policy is then applied to the outside interface and the priority queue for the outside interface is enabled.

Example 24-1 Configuring QoS Policing and Priority Queuing

hostname(config)# class-map TG1-voice
hostname(config-cmap)# description "This class-map matches all dscp ef traffic for tunnel-grp 1"
hostname(config-cmap)# match dscp ef
hostname(config-cmap)# match tunnel-group tunnel-grp1
hostname(config-cmap)# class-map TG1-BestEffort
hostname(config-cmap)# description "This class-map matches all best-effort traffic for tunnel-grp1"
hostname(config-cmap)# match tunnel-group tunnel-grp1
hostname(config-cmap)# match flow ip destination-address
hostname(config-cmap)# policy-map qos
hostname(config-pmap)# class TG1-voice
hostname(config-pmap-c)# priority
hostname(config-pmap-c)# class TG1-best-effort
hostname(config-pmap-c)# police output 200000 37500
hostname(config-pmap-c)# class class-default
hostname(config-pmap-c)# police output 1000000 37500
hostname(config-pmap-c)# service-policy qos interface outside
hostname(config)# priority-queue outside
hostname(config-priority-queue)# queue-limit 2048
hostname(config-priority-queue)# tx-ring-limit 256
Viewing QoS Configuration
This section includes the following topics:

• Viewing QoS Policy Map Configuration

• Viewing the Priority-Queue Configuration for an Interface

Viewing QoS Service Policy Configuration
To view all current service policies, including those that implement QoS policy maps, use the show service-policy command in privileged EXEC mode. You can limit the output to policies that include the police or priority commands by using the police or priority keywords.



--------------------------------------------------------------------------------

Note This is the same command you use to view priority and police statistics.


--------------------------------------------------------------------------------

The following is sample output from the show service-policy with the police keyword:

hostname# show service-policy police
Global policy:
        Service-policy: global_fw_policy
Interface outside:
        Service-policy: qos
                Class-map: browse
                        police Interface outside:
                                cir 56000 bps, bc 10500 bytes
                                conformed 10065 packets, 12621510 bytes; actions: transmit
                                exceeded 499 packets, 625146 bytes; actions: drop
                                conformed 5600 bps, exceed 5016 bps
                Class-map: cmap2
                        police Interface outside:
                                cir 200000 bps, bc 37500 bytes
                                conformed 17179 packets, 20614800 bytes; actions: transmit
                                exceeded 617 packets, 770718 bytes; actions: drop
                                conformed 198785 bps, exceed 2303 bps
The following is sample output from the show service-policy with the priority keyword:

hostname# show service-policy priority
Global policy:
        Service-policy: global_fw_policy
Interface outside:
        Service-policy: qos
                Class-map: TG1-voice
                        Priority:
                                Interface outside: aggregate drop 0, aggregate transmit 9383
Viewing QoS Policy Map Configuration
To view all policy maps, including those that include the police and priority commands, use the following command in privileged EXEC mode:

hostname# show running-config policy-map
The following is sample output from the show running-config policy-map:

hostname# show running-config policy-map
!
policy-map test
class class-default
policy-map inbound_policy
class ftp-port
  inspect ftp strict inbound_ftp
policy-map qos
class browse
  police 56000 10500
class TG1-voice
  priority
class TG1-BestEffort
  police 200000 37500
Viewing the Priority-Queue Configuration for an Interface
To display the priority-queue configuration for an interface, enter the show running-config priority-queue command in global configuration mode. The following is sample output from the show running-config priority-queue command for the interface named "test":

hostname(config)# show running-config priority-queue test
priority-queue test
  queue-limit   2048
  tx-ring-limit 256
hostname(config)#
Viewing QoS Statistics
This section includes the following topics:

• Viewing QoS Police Statistics

• Viewing QoS Priority Statistics

• Viewing QoS Priority Queue Statistics

Viewing QoS Police Statistics
To view the QoS statistics for traffic policing, use the show service-policy command with the police keyword, in privileged EXEC mode:

hostname# show service-policy police


--------------------------------------------------------------------------------

Note This is the same command you use to view configuration of policies that include the police keyword.


--------------------------------------------------------------------------------

The following is sample output from the show service-policy command. It displays service policies that include the police command and the related statistics:

hostname# show service-policy police
Global policy:
        Service-policy: global_fw_policy
Interface outside:
        Service-policy: qos
                Class-map: browse
                        police Interface outside:
                                cir 56000 bps, bc 10500 bytes
                                conformed 10065 packets, 12621510 bytes; actions: transmit
                                exceeded 499 packets, 625146 bytes; actions: drop
                                conformed 5600 bps, exceed 5016 bps
                Class-map: cmap2
                        police Interface outside:
                                cir 200000 bps, bc 37500 bytes
                                conformed 17179 packets, 20614800 bytes; actions: transmit
                                exceeded 617 packets, 770718 bytes; actions: drop
                                conformed 198785 bps, exceed 2303 bps
Viewing QoS Priority Statistics
To view statistics for service policies implementing the priority command, use the show service-policy command with the priority keyword, in privileged EXEC mode:

hostname# show service-policy priority


--------------------------------------------------------------------------------

Note This is the same command you use to view configuration of policies that include the priority keyword.


--------------------------------------------------------------------------------

The following is sample output from the show service-policy command. It includes the priority command and the related statistics.

hostname# show service-policy priority
Global policy:
        Service-policy: global_fw_policy
Interface outside:
        Service-policy: qos
                Class-map: TG1-voice
                        Priority:
                                Interface outside: aggregate drop 0, aggregate transmit 9383


--------------------------------------------------------------------------------

Note "Aggregate drop" denotes the aggregated drop in this interface; "aggregate transmit" denotes the aggregated number of transmitted packets in this interface.


--------------------------------------------------------------------------------

Viewing QoS Priority Queue Statistics
To display the priority-queue statistics for an interface, use the show priority-queue statistics command in privileged EXEC mode. The results show the statistics for both the best-effort (BE) queue and the low-latency queue (LLQ). The following is sample output from the show priority-queue statistics command for the interface named test.

hostname# show priority-queue statistics test
Priority-Queue Statistics interface test
Queue Type        = BE
Packets Dropped   = 0
Packets Transmit  = 0
Packets Enqueued  = 0
Current Q Length  = 0
Max Q Length      = 0
Queue Type        = LLQ
Packets Dropped   = 0
Packets Transmit  = 0
Packets Enqueued  = 0
Current Q Length  = 0
Max Q Length      = 0
hostname#
In this statistical report, the meaning of the line items is as follows:

•"Packets Dropped" denotes the overall number of packets that have been dropped in this queue.

•"Packets Transmit" denotes the overall number of packets that have been transmitted in this queue.

•"Packets Enqueued" denotes the overall number of packets that have been queued in this queue.

•"Current Q Length" denotes the current depth of this queue.

•"Max Q Length" denotes the maximum depth that ever occurred in this queue.

network

Configuring ARP Inspection and Bridging Parameters


Transparent Firewall Mode Only
This chapter describes how to enable ARP inspection and how to customize bridging operations for the security appliance. In multiple context mode, the commands in this chapter can be entered in a security context, but not the system.
This chapter includes the following sections:
• Configuring ARP Inspection
• Customizing the MAC Address Table
Configuring ARP Inspection This section describes ARP inspection and how to enable it, and includes the following topics:
• ARP Inspection Overview
• Adding a Static ARP Entry
• Enabling ARP Inspection
ARP Inspection Overview By default, all ARP packets are allowed through the security appliance. You can control the flow of ARP packets by enabling ARP inspection.
When you enable ARP inspection, the security appliance compares the MAC address, IP address, and source interface in all ARP packets to static entries in the ARP table, and takes the following actions:
•If the IP address, MAC address, and source interface match an ARP entry, the packet is passed through.
•If there is a mismatch between the MAC address, the IP address, or the interface, then the security appliance drops the packet.
•If the ARP packet does not match any entries in the static ARP table, then you can set the security appliance to either forward the packet out all interfaces (flood), or to drop the packet.

Note The dedicated management interface, if present, never floods packets even if this parameter is set to flood.
ARP inspection prevents malicious users from impersonating other hosts or routers (known as ARP spoofing). ARP spoofing can enable a "man-in-the-middle" attack. For example, a host sends an ARP request to the gateway router; the gateway router responds with the gateway router MAC address. The attacker, however, sends another ARP response to the host with the attacker MAC address instead of the router MAC address. The attacker can now intercept all the host traffic before forwarding it on to the router.
ARP inspection ensures that an attacker cannot send an ARP response with the attacker MAC address, so long as the correct MAC address and the associated IP address are in the static ARP table.
Adding a Static ARP Entry ARP inspection compares ARP packets with static ARP entries in the ARP table. Although hosts identify a packet destination by an IP address, the actual delivery of the packet on Ethernet relies on the Ethernet MAC address. When a router or host wants to deliver a packet on a directly connected network, it sends an ARP request asking for the MAC address associated with the IP address, and then delivers the packet to the MAC address according to the ARP response. The host or router keeps an ARP table so it does not have to send ARP requests for every packet it needs to deliver. The ARP table is dynamically updated whenever ARP responses are sent on the network, and if an entry is not used for a period of time, it times out. If an entry is incorrect (for example, the MAC address changes for a given IP address), the entry times out before it can be updated.

Note The transparent firewall uses dynamic ARP entries in the ARP table for traffic to and from the security appliance, such as management traffic.
To add a static ARP entry, enter the following command:
hostname(config)# arp interface_name ip_address mac_address


For example, to allow ARP responses from the router at 10.1.1.1 with the MAC address 0009.7cbe.2100 on the outside interface, enter the following command:
hostname(config)# arp outside 10.1.1.1 0009.7cbe.2100
Enabling ARP Inspection To enable ARP inspection, enter the following command:
hostname(config)# arp-inspection interface_name enable [flood | no-flood]


Where flood forwards non-matching ARP packets out all interfaces, and no-flood drops non-matching packets.

Note The default setting is to flood non-matching packets. To restrict ARP through the security appliance to only static entries, then set this command to no-flood.
For example, to enable ARP inspection on the outside interface, and to drop all non-matching ARP packets, enter the following command:
hostname(config)# arp-inspection outside
enable no-flood


To view the current settings for ARP inspection on all interfaces, enter the show arp-inspection command.
Customizing the MAC Address Table This section describes the MAC address table, and includes the following topics:
• MAC Address Table Overview
• Adding a Static MAC Address
• Setting the MAC Address Timeout
• Disabling MAC Address Learning
• Viewing the MAC Address Table
MAC Address Table Overview The security appliance learns and builds a MAC address table in a similar way as a normal bridge or switch: when a device sends a packet through the security appliance, the security appliance adds the MAC address to its table. The table associates the MAC address with the source interface so that the security appliance knows to send any packets addressed to the device out the correct interface.
The ASA 5505 adaptive security appliance includes a built-in switch; the switch MAC address table maintains the MAC address-to-switch port mapping for traffic within each VLAN. This section discusses the bridge MAC address table, which maintains the MAC address-to-VLAN interface mapping for traffic that passes between VLANs.
Because the security appliance is a firewall, if the destination MAC address of a packet is not in the table, the security appliance does not flood the original packet on all interfaces as a normal bridge does. Instead, it generates the following packets for directly connected devices or for remote devices:
•Packets for directly connected devices—The security appliance generates an ARP request for the destination IP address, so that the security appliance can learn which interface receives the ARP response.
•Packets for remote devices—The security appliance generates a ping to the destination IP address so that the security appliance can learn which interface receives the ping reply.
The original packet is dropped.
Adding a Static MAC Address Normally, MAC addresses are added to the MAC address table dynamically as traffic from a particular MAC address enters an interface. You can add static MAC addresses to the MAC address table if desired. One benefit to adding static entries is to guard against MAC spoofing. If a client with the same MAC address as a static entry attempts to send traffic to an interface that does not match the static entry, then the security appliance drops the traffic and generates a system message. When you add a static ARP entry (see the "Adding a Static ARP Entry" section), a static MAC address entry is automatically added to the MAC address table.
To add a static MAC address to the MAC address table, enter the following command:
hostname(config)# mac-address-table static interface_name mac_address


The interface_name is the source interface.
Setting the MAC Address Timeout The default timeout value for dynamic MAC address table entries is 5 minutes, but you can change the timeout. To change the timeout, enter the following command:
hostname(config)# mac-address-table aging-time timeout_value


The timeout_value (in minutes) is between 5 and 720 (12 hours). 5 minutes is the default.
Disabling MAC Address Learning By default, each interface automatically learns the MAC addresses of entering traffic, and the security appliance adds corresponding entries to the MAC address table. You can disable MAC address learning if desired, however, unless you statically add MAC addresses to the table, no traffic can pass through the security appliance.
To disable MAC address learning, enter the following command:
hostname(config)# mac-learn interface_name disable


The no form of this command reenables MAC address learning. The clear configure mac-learn command reenables MAC address learning on all interfaces.
Viewing the MAC Address Table You can view the entire MAC address table (including static and dynamic entries for both interfaces), or you can view the MAC address table for an interface. To view the MAC address table, enter the following command:
hostname# show mac-address-table [interface_name]


The following is sample output from the show mac-address-table command that shows the entire table:
hostname# show mac-address-table
interface                                    mac address                                       type                              Time Left
-----------------------------------------------------------------------
outside                                        0009.7cbe.2100                                   static                                -
inside                                        0010.7cbe.6101                                   static                                -
inside                                        0009.7cbe.5101                                   dynamic                                10


The following is sample output from the show mac-address-table command that shows the table for the inside interface:
hostname# show mac-address-table inside
interface                                    mac address       type                              Time Left
-----------------------------------------------------------------------
inside                                        0010.7cbe.6101                                   static                                -
inside                                        0009.7cbe.5101                                   dynamic                                10

network

Configuring 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 security appliance to do a deep packet inspection instead of passing the packet through the fast path (see the "Stateful Inspection Overview" section on page 1-4 for more information about the fast path). As a result, inspection engines can affect overall throughput.
Several common inspection engines are enabled on the security appliance by default, but you might need to enable others depending on your network. This chapter includes the following sections:
• Inspection Engine Overview
– When to Use Application Protocol Inspection
– Inspection Limitations
– Default Inspection Policy
• Configuring Application Inspection
• CTIQBE Inspection
• DCERPC Inspection
• DNS Inspection
• ESMTP Inspection
• FTP Inspection
• GTP Inspection
• H.323 Inspection
• HTTP Inspection
• Instant Messaging Inspection
• ICMP Inspection
• ICMP Error Inspection
• ILS Inspection
• MGCP Inspection
• NetBIOS Inspection
• PPTP Inspection
• RADIUS Accounting Inspection
• RSH Inspection
• RTSP Inspection
• SIP Inspection
• Skinny (SCCP) Inspection
• SMTP and Extended SMTP Inspection
• SNMP Inspection
• SQL*Net Inspection
• Sun RPC Inspection
• TFTP Inspection
• TLS Proxy for Encrypted Voice Inspection
• XDMCP Inspection
Inspection Engine Overview This section includes the following topics:
• When to Use Application Protocol Inspection
• Inspection Limitations
• Default Inspection Policy
When to Use Application Protocol Inspection When a user establishes a connection, the security appliance checks the packet against access lists, creates an address translation, and creates an entry for the session in the fast path, so that further packets can bypass time-consuming checks. However, the fast 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 security appliance.
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 security appliance 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 security appliance monitors sessions to identify the dynamic port assignments, and permits data exchange on these ports for the duration of the specific session.
Inspection Limitations See the following limitations for application protocol inspection:
•State information for multimedia sessions that require inspection are not passed over the state link for stateful failover. The exception is GTP, which is replicated over the state link.
•Some inspection engines do not support PAT, NAT, outside NAT, or NAT between same security interfaces. See "Default Inspection Policy" for more information about NAT support.
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 25-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 25-1 Supported Application Inspection Engines  
Application1
Default Port
NAT Limitations
Standards2
Comments
CTIQBE
TCP/2748
—
—
—
DNS over UDP
UDP/53
No NAT support is available for name resolution through WINS.
RFC 1123
No PTR records are changed.
FTP
TCP/21
—
RFC 959
—
GTP
UDP/3386
UDP/2123
—
—
Requires a special license.
H.323 H.225 and RAS
TCP/1720 UDP/1718
UDP (RAS) 1718-1719
No NAT on same security interfaces.
No static PAT.
ITU-T H.323, H.245, H225.0, Q.931, Q.932
—
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 Name Server over IP
UDP/137, 138 (Source ports)
—
—
NetBIOS is supported by performing NAT of the packets for NBNS UDP port 137 and NBDS UDP port 138.
PPTP
TCP/1723
—
RFC 2637
—
RADIUS Accounting
1646
—
RFC 2865
—
RSH
TCP/514
No PAT
Berkeley UNIX
—
RTSP
TCP/554
No PAT.
No outside NAT.
RFC 2326, 2327, 1889
No handling for HTTP cloaking.
SIP
TCP/5060
UDP/5060
No 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 and ESMTP
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.
Sun RPC over UDP and TCP
UDP/111
No NAT or PAT.
—
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
UDP/69
—
RFC 1350
Payload IP addresses are not translated.
XDCMP
UDP/177
No NAT or PAT.
—
—

1 Inspection engines that are enabled by default for the default port are in bold. 2 The security appliance 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 security appliance does not enforce the order.

The default policy configuration includes the following commands:
class-map inspection_default
match default-inspection-traffic
policy-map type inspect dns preset_dns_map
parameters
  message-length maximum 512
policy-map global_policy
class inspection_default
  inspect dns preset_dns_map
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect rsh
  inspect rtsp
  inspect esmtp
  inspect sqlnet
  inspect skinny
  inspect sunrpc
  inspect xdmcp
  inspect sip
  inspect netbios
  inspect tftp
service-policy global_policy global


Configuring Application Inspection This feature uses Modular Policy Framework, so that implementing application inspection consists of identifying traffic, applying inspections to the traffic, and activating inspections on an interface. For some applications, you can perform special actions when you enable inspection. See Chapter 21, "Using Modular Policy Framework," for more information.
Inspection is enabled by default for some applications. See the "Default Inspection Policy" section for more information. Use this section to modify your inspection policy.
To configure application inspection, perform the following steps:
Step 1 To identify the traffic to which you want to apply inspections, add either a Layer 3/4 class map for through traffic or a Layer 3/4 class map for management traffic. See the "Creating a Layer 3/4 Class Map for Through Traffic" section on page 21-3 and "Creating a Layer 3/4 Class Map for Management Traffic" section on page 21-5 for detailed information. The management Layer 3/4 class map can be used only with the RADIUS accounting inspection.
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 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.0
hostname(config)# class-map inspection_default
hostname(config-cmap)# match access-list inspect


View the entire class map using the following command:
hostname(config-cmap)# show running-config class-map inspection_default
!
class-map inspection_default
match default-inspection-traffic
match 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 21
hostname(config)# access-list ftp_inspect extended permit tcp any any eq 1056
hostname(config)# class-map new_inspection
hostname(config-cmap)# match access-list ftp_inspect


Step 2 (Optional) Some inspection engines let you control additional parameters when you apply the inspection to the traffic. See the following sections to configure an inspection policy map for your application:
•DCERPC—See the "Configuring a DCERPC Inspection Policy Map for Additional Inspection Control" section
•DNS—See the "Configuring a DNS Inspection Policy Map for Additional Inspection Control" section
•ESMTP—See the "Configuring an ESMTP Inspection Policy Map for Additional Inspection Control" section
•FTP—See the "Configuring an FTP Inspection Policy Map for Additional Inspection Control" section.
•GTP—See the "Configuring a GTP Inspection Policy Map for Additional Inspection Control" section.
•H323—See the "Configuring an H.323 Inspection Policy Map for Additional Inspection Control" section
•HTTP—See the "Configuring an HTTP Inspection Policy Map for Additional Inspection Control" section.
•Instant Messaging—See the "Configuring an Instant Messaging Inspection Policy Map for Additional Inspection Control" section
•MGCP—See the "Configuring an MGCP Inspection Policy Map for Additional Inspection Control" section.
•NetBIOS—See the "Configuring a NetBIOS Inspection Policy Map for Additional Inspection Control" section
•RADIUS Accounting—See the "Configuring a RADIUS Inspection Policy Map for Additional Inspection Control" section
•RTSP—See the "Configuring an RTSP Inspection Policy Map for Additional Inspection Control" section
•SIP—See the "Configuring a SIP Inspection Policy Map for Additional Inspection Control" section
•Skinny—See the "Configuring a Skinny (SCCP) Inspection Policy Map for Additional Inspection Control" section
•SNMP—See the "SNMP Inspection" section.
Step 3 To add or edit a Layer 3/4 policy map that sets the actions to take with the class map traffic, enter the following command:
hostname(config)# policy-map name
hostname(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 To identify the class map from Step 1 to which you want to assign an action, enter the following command:
hostname(config-pmap)# class class_map_name
hostname(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 Enable application inspection by entering the following command:
hostname(config-pmap-c)# inspect protocol


The protocol is one of the following values:

Table 25-2 Protocol Keywords
Keywords
Notes
ctiqbe
—
dcerpc [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]
If you added a DNS inspection policy map according to "Configuring a DNS Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command. The default DNS inspection policy map name is "preset_dns_map." The default inspection policy map sets the maximum DNS packet length to 512 bytes.
esmtp [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 inspection policy map according to "Configuring an FTP Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
gtp [map_name]
If you added a GTP inspection policy map according to the "Configuring a GTP Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
h323 h225 [map_name]
If you added an H323 inspection policy map according to "Configuring an H.323 Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
h323 ras [map_name]
If you added an H323 inspection policy map according to "Configuring an H.323 Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
http [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
—
im [map_name]
If you added an Instant Messaging inspection policy map according to "Configuring an Instant Messaging Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
mgcp [map_name]
If you added an MGCP inspection policy map according to "Configuring an MGCP Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
netbios [map_name]
If you added a NetBIOS inspection policy map according to "Configuring a NetBIOS Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
pptp
—
radius-accounting [map_name]
The radius-accounting keyword is only available for a management class map. See the "Creating a Layer 3/4 Class Map for Management Traffic" section on page 21-5 for more information about creating a management class map.
If you added a RADIUS accounting inspection policy map according to "Configuring a RADIUS Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
rsh
—
rtsp [map_name]
If you added a NetBIOS inspection policy map according to "Configuring an RTSP Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
sip [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 [map_name]
If you added a Skinny inspection policy map according to "Configuring a Skinny (SCCP) Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
snmp [map_name]
If you added an SNMP inspection policy map according to "SNMP 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
—
xdmcp
—

Step 6 To activate the policy map on one or more interfaces, enter the following command:
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 CTIQBE application inspection. This section includes the following topics:
• CTIQBE Inspection Overview
• Limitations and Restrictions
• Verifying and Monitoring CTIQBE Inspection
CTIQBE Inspection Overview CTIQBE protocol inspection supports NAT, PAT, and bidirectional NAT. This enables Cisco IP SoftPhone and other Cisco TAPI/JTAPI applications to work successfully with Cisco CallManager for call setup across the security appliance.
TAPI and JTAPI are used by many Cisco VoIP applications. CTIQBE is used by Cisco TSP to communicate with Cisco CallManager.
Limitations and Restrictions The following summarizes limitations that apply when using CTIQBE application inspection:
•CTIQBE application inspection does not support configurations with the alias command.
•Stateful failover of CTIQBE calls is not supported.
•Entering the debug ctiqbe command may delay message transmission, which may have a performance impact in a real-time environment. When you enable this debugging or logging and Cisco IP SoftPhone seems unable to complete call setup through the security appliance, increase the timeout values in the Cisco TSP settings on the system running Cisco IP SoftPhone.
The following summarizes special considerations when using CTIQBE application inspection in specific scenarios:
•If two Cisco IP SoftPhones are registered with different Cisco CallManagers, which are connected to different interfaces of the security appliance, calls between these two phones fails.
•When Cisco CallManager is located on the higher security interface compared to Cisco IP SoftPhones, if NAT or outside NAT is required for the Cisco CallManager IP address, the mapping must be static as Cisco IP SoftPhone requires the Cisco CallManager IP address to be specified explicitly in its Cisco TSP configuration on the PC.
•When using PAT or Outside PAT, if the Cisco CallManager IP address is to be translated, its TCP port 2748 must be statically mapped to the same port of the PAT (interface) address for Cisco IP SoftPhone registrations to succeed. The CTIQBE listening port (TCP 2748) is fixed and is not user-configurable on Cisco CallManager, Cisco IP SoftPhone, or Cisco TSP.
Verifying and Monitoring CTIQBE Inspection The show ctiqbe command displays information regarding the CTIQBE sessions established across the security appliance. It shows information about the media connections allocated by the CTIQBE inspection engine.
The following is sample output from the show ctiqbe command under the following conditions. There is only one active CTIQBE session setup across the security appliance. It is established between an internal CTI device (for example, a Cisco IP SoftPhone) at local address 10.0.0.99 and an external Cisco CallManager at 172.29.1.77, where TCP port 2748 is the Cisco CallManager. The heartbeat interval for the session is 120 seconds.
hostname# # show ctiqbe


Total: 1
        LOCAL           FOREIGN         STATE   HEARTBEAT
---------------------------------------------------------------
1       10.0.0.99/1117  172.29.1.77/2748        1       120
        ----------------------------------------------
        RTP/RTCP: PAT xlates: mapped to 172.29.1.99(1028 - 1029)
        ----------------------------------------------
        MEDIA: Device ID 27     Call ID 0
               Foreign 172.29.1.99      (1028 - 1029)
               Local   172.29.1.88      (26822 - 26823)
        ----------------------------------------------


The CTI device has already registered with the CallManager. The device internal address and RTP listening port is PATed to 172.29.1.99 UDP port 1028. Its RTCP listening port is PATed to UDP 1029.
The line beginning with RTP/RTCP: PAT xlates: appears only if an internal CTI device has registered with an external CallManager and the CTI device address and ports are PATed to that external interface. This line does not appear if the CallManager is located on an internal interface, or if the internal CTI device address and ports are translated to the same external interface that is used by the CallManager.
The output indicates a call has been established between this CTI device and another phone at 172.29.1.88. The RTP and RTCP listening ports of the other phone are UDP 26822 and 26823. The other phone locates on the same interface as the CallManager because the security appliance does not maintain a CTIQBE session record associated with the second phone and CallManager. The active call leg on the CTI device side can be identified with Device ID 27 and Call ID 0.
The following is sample output from the show xlate debug command for these CTIBQE connections:
hostname# show xlate debug
3 in use, 3 most used
Flags:  D - DNS, d - dump, I - identity, i - inside, n - no random,
        r - portmap, s - static
TCP PAT from inside:10.0.0.99/1117 to outside:172.29.1.99/1025 flags ri idle 0:00:22 timeout 0:00:30
UDP PAT from inside:10.0.0.99/16908 to outside:172.29.1.99/1028 flags ri idle 0:00:00 timeout 0:04:10
UDP PAT from inside:10.0.0.99/16909 to outside:172.29.1.99/1029 flags ri idle 0:00:23 timeout 0:04:10


The show conn state ctiqbe commanddisplays the status of CTIQBE connections. In the output, the media connections allocated by the CTIQBE inspection engine are denoted by a `C' flag. The following is sample output from the show conn state ctiqbe command:
hostname# show conn state ctiqbe
1 in use, 10 most used
hostname# show conn state ctiqbe detail
1 in use, 10 most used
Flags: A - awaiting inside ACK to SYN, a - awaiting outside ACK to SYN,
       B - initial SYN from outside, C - CTIQBE media, D - DNS, d - dump,
       E - outside back connection, F - outside FIN, f - inside FIN,
       G - group, g - MGCP, H - H.323, h - H.225.0, I - inbound data,
       i - incomplete, J - GTP, j - GTP data, k - Skinny media,
       M - SMTP data, m - SIP media, O - outbound data, P - inside back connection,
       q - SQL*Net data, R - outside acknowledged FIN,
       R - UDP RPC, r - inside acknowledged FIN, S - awaiting inside SYN,
       s - awaiting outside SYN, T - SIP, t - SIP transient, U - up


DCERPC Inspection This section describes the DCERPC inspection engine. This section includes the following topics:
• DCERPC Overview
• Configuring a DCERPC Inspection Policy Map for Additional Inspection Control
DCERPC Overview DCERPC is a protocol widely used by Microsoft distributed client and server applications that allows software clients to execute programs on a server remotely.
This typically involves a client querying a server called the Endpoint Mapper listening on a well known port number for the dynamically allocated network information of a required service. The client then sets up a secondary connection to the server instance providing the service. The security appliance allows the appropriate port number and network address and also applies NAT, if needed, for the secondary connection.
DCERPC inspect maps inspect for native TCP communication between the EPM and client on well known TCP port 135. Map and lookup operations of the EPM are supported for clients. Client and server can be located in any security zone. The embedded server IP address and Port number are received from the applicable EPM response messages. Since a client may attempt multiple connections to the server port returned by EPM, multiple use of pinholes are allowed, which have user configurable timeouts.
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 Create a DCERPC inspection policy map, enter the following command:
hostname(config)# policy-map type inspect dcerpc policy_map_name
hostname(config-pmap)#


Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration mode.
Step 2 (Optional) To add a description to the policy map, enter the following command:
hostname(config-pmap)# description string


Step 3 To configure parameters that affect the inspection engine, perform the following steps:
a. To enter parameters configuration mode, enter the following command:
hostname(config-pmap)# parameters
hostname(config-pmap-p)#


b. To configure the timeout for DCERPC pinholes and override the global system pinhole timeout of two minutes, enter the following command:
hostname(config-pmap-p)# timeout pinhole hh:mm:ss


Where the hh:mm:ss argument is the timeout for pinhole connections. Value is between 0:0:1 and 1193:0:0.
c. To configure options for the endpoint mapper traffic, enter the following command:
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_map
hostname(config-pmap)# timeout pinhole 0:10:00


hostname(config)# class-map dcerpc
hostname(config-cmap)# match port tcp eq 135


hostname(config)# policy-map global-policy
hostname(config-pmap)# class dcerpc
hostname(config-pmap-c)# inspect msrpc dcerpc-map


hostname(config)# service-policy global-policy global


DNS Inspection This section describes DNS application inspection. This section includes the following topics:
• How DNS Application Inspection Works
• How DNS Rewrite Works
• Configuring DNS Rewrite
• Verifying and Monitoring DNS Inspection
How DNS Application Inspection Works The security appliance tears down the DNS session associated with a DNS query as soon as the DNS reply is forwarded by the security appliance. The security appliance 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 security appliance performs the following additional tasks:
•Translates the DNS record based on the configuration completed using the alias, static and nat commands (DNS Rewrite). Translation only applies to the A-record in the DNS reply; therefore, DNS Rewrite does not affect reverse lookups, which request the PTR record.

Note DNS Rewrite is not applicable for PAT because multiple PAT rules are applicable for each A-record and the PAT rule to use is ambiguous.
•Enforces the maximum DNS message length (the default is 512 bytes and the maximum length is 65535 bytes). The security appliance performs reassembly as needed to verify that the packet length is less than the maximum length configured. The security appliance drops the packet if it exceeds the maximum length.

Note If you enter the inspect dns command without the maximum-length option, DNS packet size is not checked
•Enforces a domain-name length of 255 bytes and a label length of 63 bytes.
•Verifies the integrity of the domain-name referred to by the pointer if compression pointers are encountered in the DNS message.
•Checks to see if a compression pointer loop exists.
A single connection is created for multiple DNS sessions, as long as they are between the same two hosts, and the sessions have the same 5-tuple (source/destination IP address, source/destination port, and protocol). DNS identification is tracked by app_id, and the idle timer for each app_id runs independently.
Because the app_id expires independently, a legitimate DNS response can only pass through the security appliance within a limited period of time and there is no resource build-up. However, if you enter the show conn command, you will see the idle timer of a DNS connection being reset by a new DNS session. This is due to the nature of the shared DNS connection and is by design.
How DNS Rewrite Works When DNS inspection is enabled, DNS rewrite provides full support for NAT of DNS messages originating from any interface.
If a client on an inside network requests DNS resolution of an inside address from a DNS server on an outside interface, the DNS A-record is translated correctly. If the DNS inspection engine is disabled, the A-record is not translated.
As long as DNS inspection remains enabled, you can configure DNS rewrite using the alias, static, or nat commands. For details about the configuration required see the "Configuring DNS Rewrite" section.
DNS Rewrite performs two functions:
•Translating a public address (the routable or "mapped" address) in a DNS reply to a private address (the "real" address) when the DNS client is on a private interface.
•Translating a private address to a public address when the DNS client is on the public interface.
In Figure 25-1, the DNS server resides on the external (ISP) network The real address of the server (192.168.100.1) has been mapped using the static command to the ISP-assigned address (209.165.200.5). 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 security appliance translates the non-routable source address in the IP header and forwards the request to the ISP network on its outside interface. When the DNS reply is returned, the security appliance applies address translation not only to the destination address, but also to the embedded IP address of the web server, which is contained in the A-record in the DNS reply. As a result, the web client on the inside network gets the correct address for connecting to the web server on the inside network. For configuration instructions for scenarios similar to this one, see the "Configuring DNS Rewrite with Two NAT Zones" section.
Figure 25-1 Translating the Address in a DNS Reply (DNS Rewrite)

DNS rewrite also works if the client making the DNS request is on a DMZ network and the DNS server is on an inside interface. For an illustration and configuration instructions for this scenario, see the "DNS Rewrite with Three NAT Zones" section.
Configuring DNS Rewrite You configure DNS rewrite using the alias, static, or nat commands. The alias and static command can be used interchangeably; however, we recommend using the static command for new deployments because it is more precise and unambiguous. Also, DNS rewrite is optional when using the static command.
This section describes how to use the alias and static commands to configure DNS rewrite. It provides configuration procedures for using the static command in a simple scenario and in a more complex scenario. Using the nat command is similar to using the static command except that DNS Rewrite is based on dynamic translation instead of a static mapping.
This section includes the following topics:
• Using the Static Command for DNS Rewrite
• Using the Static Command for DNS Rewrite
• Configuring DNS Rewrite with Two NAT Zones
• DNS Rewrite with Three NAT Zones
• Configuring DNS Rewrite with Three NAT Zones
For detailed syntax and additional functions for the alias, nat, and static command, see the appropriatecommand page in the Cisco Security Appliance Command Reference.
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 (real_ifc,mapped_ifc) mapped-address real-address dns


The following example specifies that the address 192.168.100.10 on the inside interface is translated into 209.165.200.5 on the outside interface:
hostname(config)# static (inside,outside) 209.165.200.225 192.168.100.10 dns



Note Using the nat command is similar to using the static command except that DNS Rewrite is based on dynamic translation instead of a static mapping.
Using the Alias Command for DNS Rewrite The alias command causes the security appliance 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 (interface_name) mapped-address real-address


The following example specifies that the real address (192.168.100.10) on any interface except the inside interface will be translated to the mapped address (209.165.200.225) on the inside interface. Notice that the location of 192.168.100.10 is not precisely defined.
hostname(config)# alias (inside) 209.165.200.225 192.168.100.10



Note If you use the alias command to configure DNS Rewrite, proxy ARP will be performed for the mapped address. To prevent this, disable Proxy ARP by entering the sysopt noproxyarp command after entering the alias command.
Configuring DNS Rewrite with Two NAT Zones To implement a DNS Rewrite scenario similar to the one shown in Figure 25-1, perform the following steps:
Step 1 Create a static translation for the web server, as follows:
hostname(config)# static (real_ifc,mapped_ifc) mapped-address real-address netmask 255.255.255.255 dns


where the arguments are as follows:
•real_ifc—The name of the interface connected to the real addresses.
•mapped_ifc—The name of the interface where you want the addresses to be mapped.
•mapped-address—The translated IP address of the web server.
•real-address—The real IP address of the web server.
Step 2 Create an access list that permits traffic to the port that the web server listens to for HTTP requests.
hostname(config)# access-list acl-name extended permit tcp any host mapped-address eq port


where the arguments are as follows:
acl-name—The name you give the access list.
mapped-address—The translated IP address of the web server.
port—The TCP port that the web server listens to for HTTP requests.
Step 3 Apply the access list created in Step 2 to the mapped interface. To do so, use the access-group command, as follows:
hostname(config)# access-group acl-name in interface mapped_ifc


Step 4 If DNS inspection is disabled or if you want to change the maximum DNS packet length, configure DNS inspection. DNS application inspection is enabled by default with a maximum DNS packet length of 512 bytes. For configuration instructions, see the "Configuring Application Inspection" section.
Step 5 On the public DNS server, add an A-record for the web server, such as:
domain-qualified-hostname. IN A mapped-address


where domain-qualified-hostname is the hostname with a domain suffix, as in server.example.com. The period after the hostname is important. mapped-address is the translated IP address of the web server.
The following example configures the security appliance for the scenario shown in Figure 25-1. It assumes DNS inspection is already enabled.
hostname(config)# static (inside,outside) 209.165.200.225 192.168.100.1 netmask 255.255.255.255 dns
hostname(config)# access-list 101 permit tcp any host 209.165.200.225 eq www
hostname(config)# access-group 101 in interface outside


This configuration requires the following A-record on the DNS server:
server.example.com. IN A 209.165.200.225


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

In Figure 25-2, a web server, server.example.com, has the real address 192.168.100.10 on the DMZ interface of the security appliance. A web client with the IP address 10.10.10.25 is on the inside interface and a public DNS server is on the outside interface. The site NAT policies are as follows:
•The outside DNS server holds the authoritative address record for server.example.com.
•Hosts on the outside network can contact the web server with the domain name server.example.com through the outside DNS server or with the IP address 209.165.200.5.
•Clients on the inside network can access the web server with the domain name server.example.com through the outside DNS server or with the IP address 192.168.100.10.
When a host or client on any interface accesses the DMZ web server, it queries the public DNS server for the A-record of server.example.com. The DNS server returns the A-record showing that server.example.com binds to address 209.165.200.5.
When a web client on the outside network attempts to access http://server.example.com, the sequence of events is as follows:
1. The host running the web client sends the DNS server a request for the IP address of server.example.com.
2. The DNS server responds with the IP address 209.165.200.225 in the reply.
3. The web client sends its HTTP request to 209.165.200.225.
4. The packet from the outside host reaches the security appliance at the outside interface.
5. The static rule translates the address 209.165.200.225 to 192.168.100.10 and the security appliance directs the packet to the web server on the DMZ.
When a web client on the inside network attempts to access http://server.example.com, the sequence of events is as follows:
1. The host running the web client sends the DNS server a request for the IP address of server.example.com.
2. The DNS server responds with the IP address 209.165.200.225 in the reply.
3. The security appliance receives the DNS reply and submits it to the DNS application inspection engine.
4. The DNS application inspection engine does the following:
a. Searches for any NAT rule to undo the translation of the embedded A-record address "[outside]:209.165.200.5". In this example, it finds the following static configuration:
static (dmz,outside) 209.165.200.225 192.168.100.10 dns


b. Uses the static rule to rewrite the A-record as follows because the dns option is included:
[outside]:209.165.200.225 --> [dmz]:192.168.100.10



Note If the dns option were not included with the static command, DNS Rewrite would not be performed and other processing for the packet continues.
c. Searches for any NAT to translate the web server address, [dmz]:192.168.100.10, when communicating with the inside web client.
No NAT rule is applicable, so application inspection completes.
If a NAT rule (nat or static) were applicable, the dns option must also be specified. If the dns option were not specified, the A-record rewrite in step b would be reverted and other processing for the packet continues.
5. The security appliance sends the HTTP request to server.example.com on the DMZ interface.
Configuring DNS Rewrite with Three NAT Zones To enable the NAT policies for the scenario in Figure 25-2, perform the following steps:
Step 1 Create a static translation for the web server on the DMZ network, as follows:
hostname(config)# static (dmz,outside) mapped-address real-address dns


where the arguments are as follows:
•dmz—The name of the DMZ interface of the security appliance.
•outside—The name of the outside interface of the security appliance.
•mapped-address—The translated IP address of the web server.
•real-address—The real IP address of the web server.
Step 2 Create an access list that permits traffic to the port that the web server listens to for HTTP requests.
hostname(config)# access-list acl-name extended permit tcp any host mapped-address eq port


where the arguments are as follows:
acl-name—The name you give the access list.
mapped-address—The translated IP address of the web server.
port—The TCP port that the web server listens to for HTTP requests.
Step 3 Apply the access list created in Step 2 to the outside interface. To do so, use the access-group command, as follows:
hostname(config)# access-group acl-name in interface outside


Step 4 If DNS inspection is disabled or if you want to change the maximum DNS packet length, configure DNS inspection. DNS application inspection is enabled by default with a maximum DNS packet length of 512 bytes. For configuration instructions, see the "Configuring Application Inspection" section.
Step 5 On the public DNS server, add an A-record for the web server, such as:
domain-qualified-hostname. IN A mapped-address


where domain-qualified-hostname is the hostname with a domain suffix, as in server.example.com. The period after the hostname is important. mapped-address is the translated IP address of the web server.
The following example configures the security appliance for the scenario shown in Figure 25-2. It assumes DNS inspection is already enabled.
hostname(config)# static (dmz,outside) 209.165.200.225 192.168.100.10 dns
hostname(config)# access-list 101 permit tcp any host 209.165.200.225 eq www
hostname(config)# access-group 101 in interface outside


This configuration requires the following A-record on the DNS server:
server.example.com. IN A 209.165.200.225


Verifying and Monitoring DNS Inspection To view information about the current DNS connections, enter the following command:
hostname# show conn


For connections using a DNS server, the source port of the connection may be replaced by the IP address of DNS server in the show conn command output.
A single connection is created for multiple DNS sessions, as long as they are between the same two hosts, and the sessions have the same 5-tuple (source/destination IP address, source/destination port, and protocol). DNS identification is tracked by app_id, and the idle timer for each app_id runs independently.
Because the app_id expires independently, a legitimate DNS response can only pass through the security appliance within a limited period of time and there is no resource build-up. However, when you enter the show conn command, you see the idle timer of a DNS connection being reset by a new DNS session. This is due to the nature of the shared DNS connection and is by design.
To display the statistics for DNS application inspection, enter the show service-policy command. The following is sample output from the show service-policy command:
hostname# show service-policy
Interface outside:
  Service-policy: sample_policy
    Class-map: dns_port
      Inspect: dns maximum-length 1500, packet 0, drop 0, reset-drop 0


Configuring a DNS Inspection Policy Map for Additional Inspection Control DNS application inspection supports DNS message controls that provide protection against DNS spoofing and cache poisoning. User configurable rules allow filtering based on DNS header, domain name, resource record type and class. Zone transfer can be restricted between servers with this function, for example.
The Recursion Desired and Recursion Available flags in the DNS header can be masked to protect a public server from attack if that server only supports a particular internal zone. In addition, DNS randomization can be enabled avoid spoofing and cache poisoning of servers that either do not support randomization, or utilize a weak pseudo random number generator. Limiting the domain names that can be queried also restricts the domain names which can be queried, which protects the public server further.
A configurable DNS mismatch alert can be used as notification if an excessive number of mismatching DNS responses are received, which could indicate a cache poisoning attack. In addition, a configurable check to enforce a Transaction Signature be attached to all DNS messages is also supported.
To specify actions when a message violates a parameter, create a DNS inspection policy map. You can then apply the inspection policy map when you enable DNS inspection according to the "Configuring Application Inspection" section.
To create a DNS inspection policy map, perform the following steps:
Step 1 (Optional) Add one or more regular expressions for use in traffic matching commands according to the "Creating a Regular Expression" section on page 21-6. See the types of text you can match in the match commands described in Step 3.
Step 2 (Optional) Create one or more regular expression class maps to group regular expressions according to the "Creating a Regular Expression Class Map" section on page 21-9.
Step 3 (Optional) Create a DNS inspection class map by performing the following steps.
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. Create the class map by entering the following command:
hostname(config)# class-map type
inspect dns [match-all | match-any]class_map_name
hostname(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. (Optional) To add a description to the class map, enter the following command:
hostname(config-cmap)# description string


c. (Optional) To match a specific flag that is set in the DNS header, enter the following command:
hostname(config-cmap)# match [not] header-flag [eq] {f_well_known | f_value}


Where the f_well_known argument is the DNS flag bit. The f_value argument is the 16-bit value in hex. The eq keyword specifies an exact match.
d. (Optional) To match a DNS type, including Query type and RR type, enter the following command:
hostname(config-cmap)# match [not] dns-type {eq t_well_known
| t_val} {range t_val1 t_val2}


Where the t_well_known argument is the DNS flag bit. The t_val arguments are arbitrary values in the DNS type field (0-65535). The range keyword specifies a range and the eq keyword specifies an exact match.
e. (Optional) To match a DNS class, enter the following command:
hostname(config-cmap)# match [not] dns-class {eq c_well_known
| c_val} {range c_val1 c_val2}


Where the c_well_known argument is the DNS class. The c_val arguments are arbitrary values in the DNS class field. The range keyword specifies a range and the eq keyword specifies an exact match.
f. (Optional) To match a DNS question or resource record, enter the following command:
hostname(config-cmap)# match {question
| {resource-record answer | authority | any}}


Where the question keyword specifies the question portion of a DNS message. The resource-record keyword specifies the resource record portion of a DNS message. The answer keyword specifies the Answer RR section. The authority keyword specifies the Authority RR section. The additional keyword specifies the Additional RR section.
g. (Optional) To match a DNS message domain name list, enter the following command:
hostname(config-cmap)# match [not] domain-name {regex regex_id | regex class class_id]


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 Create a DNS inspection policy map, enter the following command:
hostname(config)# policy-map type inspect dns policy_map_name
hostname(config-pmap)#


Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration mode.
Step 5 (Optional) To add a description to the policy map, enter the following command:
hostname(config-pmap)# description string


Step 6 To apply actions to matching traffic, perform the following steps.
a. Specify the traffic on which you want to perform actions using one of the following methods:
•Specify the DNS class map that you created in Step 3 by entering the following command:
hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)#


•Specify traffic directly in the policy map using one of the match commands described in Step 3. If you use a match not command, then any traffic that does not match the criterion in the match not command has the action applied.
b. Specify the action you want to perform on the matching traffic by entering the following command:
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 Cisco Security Appliance 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 21-11.
Step 7 To configure parameters that affect the inspection engine, perform the following steps:
a. To enter parameters configuration mode, enter the following command:
hostname(config-pmap)# parameters
hostname(config-pmap-p)#


b. To randomize the DNS identifier for a DNS query, enter the following command:
hostname(config-pmap-p)# id-randomization


c. To enable logging for excessive DNS ID mismatches, enter the following command:
hostname(config-pmap-p)# id-mismatch [count number duration seconds] action log


Where the count string argument specifies the maximum number of mismatch instances before a system message log is sent. The duration seconds specifies the period, in seconds, to monitor.
d. To require a TSIG resource record to be present, enter the following command:
hostname(config-pmap-p)# tsig enforced action {drop [log] | [log}


Where the count string argument specifies the maximum number of mismatch instances before a system message log is sent. The duration seconds specifies the period, in seconds, to monitor.
The following example shows a how to define a DNS inspection policy map.
hostname(config)# regex domain_example "example\.com"
hostname(config)# regex domain_foo "foo\.com"


hostname(config)# ! define the domain names that the server serves
hostname(config)# class-map type inspect regex match-any my_domains
hostname(config-cmap)# match regex domain_example
hostname(config-cmap)# match regex domain_foo


hostname(config)# ! Define a DNS map for query only
hostname(config)# class-map type inspect dns match-all pub_server_map
hostname(config-cmap)# match not header-flag QR
hostname(config-cmap)# match question
hostname(config-cmap)# match not domain-name regex class my_domains


hostname(config)# policy-map type inspect dns serv_prot
hostname(config-pmap)# class pub_server_map
hostname(config-pmap-c)# drop log
hostname(config-pmap-c)# match header-flag RD
hostname(config-pmap-c)# mask log


hostname(config)# class-map dns_serv_map
hostname(config-cmap)# match default-inspection-traffic


hostname(config)# policy-map pub_policy
hostname(config-pmap)# class dns_serv_map
hostname(config-pmap-c)# inspect dns serv_prot


hostname(config)# service-policy pub_policy interface dmz


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 (Optional) Add one or more regular expressions for use in traffic matching commands according to the "Creating a Regular Expression" section on page 21-6. See the types of text you can match in the match commands described in Step 3.
Step 2 (Optional) Create one or more regular expression class maps to group regular expressions according to the "Creating a Regular Expression Class Map" section on page 21-9.
Step 3 Create an ESMTP inspection policy map, enter the following command:
hostname(config)# policy-map type inspect esmtp policy_map_name
hostname(config-pmap)#


Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration mode.
Step 4 (Optional) To add a description to the policy map, enter the following command:
hostname(config-pmap)# description string


Step 5 To apply actions to matching traffic, perform the following steps.
a. Specify the traffic on which you want to perform actions using one of the following methods:
•Specify the ESMTP class map that you created in Step 3 by entering the following command:
hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)#


•Specify traffic directly in the policy map using one of the match commands described in Step 3. If you use a match not command, then any traffic that does not match the criterion in the match not command has the action applied.
b. Specify the action you want to perform on the matching traffic by entering the following command:
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 Cisco Security Appliance 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 21-11.
Step 6 To configure parameters that affect the inspection engine, perform the following steps:
a. To enter parameters configuration mode, enter the following command:
hostname(config-pmap)# parameters
hostname(config-pmap-p)#


b. To configure a local domain name, enter the following command:
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. To enforce banner obfuscation, enter the following command:
hostname(config-pmap-p)# mask-banner


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_list
hostname(config-cmap)# description "Regular expressions to filter out undesired senders"
hostname(config-cmap)# match regex user1
hostname(config-cmap)# match regex user2
hostname(config-cmap)# match regex user3


hostname(config)# policy-map type inspect esmtp advanced_esmtp_map
hostname(config-pmap)# match sender-address regex class senders_black_list
hostname(config-pmap-c)# drop-connection log


hostname(config)# policy-map outside_policy
hostname(config-pmap)# class inspection_default
hostname(config-pmap-c)# inspect esmtp advanced_esmtp_map


hostname(config)# service-policy outside_policy interface outside


FTP Inspection This section describes the FTP inspection engine. This section includes the following topics:
• FTP Inspection Overview
• Using the strict Option
• Configuring an FTP Inspection Policy Map for Additional Inspection Control
• Verifying and Monitoring FTP Inspection
FTP Inspection Overview The FTP application inspection inspects the FTP sessions and performs four
tasks:
•Prepares dynamic secondary data connection
•Tracks the FTP command-response sequence
•Generates an audit trail
•Translates the embedded IP address
FTP application inspection prepares secondary channels for FTP data transfer. Ports for these channels are negotiated through PORT or PASV commands. The channels are allocated in response to a file upload, a file download, or a directory listing event.

Note If you disable FTP inspection engines with the no inspect ftp command, outbound users can start connections only in passive mode, and all inbound FTP is disabled.
Using the strict Option Using the strict option with the inspect ftp command increases the security of protected networks by preventing web browsers from sending embedded commands in FTP requests.

Note To specify FTP commands that are not permitted to pass through the security appliance, create an FTP map according to the "Configuring an FTP Inspection Policy Map for Additional Inspection Control" section.
After you enable the strict option on an interface, FTP inspection enforces the following behavior:
•An FTP command must be acknowledged before the security appliance allows a new command.
•The security appliance drops connections that send embedded commands.
•The 227 and PORT commands are checked to ensure they do not appear in an error string.

Caution Using the strict option may cause the failure of FTP clients that are not strictly compliant with FTP RFCs.
If the strict option is enabled, each FTP command and response sequence is tracked for the following anomalous activity:
•Truncated command—Number of commas in the PORT and PASV reply command is checked to see if it is five. If it is not five, then the PORT command is assumed to be truncated and the TCP connection is closed.
&#8226;Incorrect command—Checks the FTP command to see if it ends with <CR><LF> characters, as required by the RFC. If it does not, the connection is closed.
&#8226;Size of RETR and STOR commands—These are checked against a fixed constant. If the size is greater, then an error message is logged and the connection is closed.
&#8226;Command spoofing—The PORT command should always be sent from the client. The TCP connection is denied if a PORT command is sent from the server.
&#8226;Reply spoofing—PASV reply command (227) should always be sent from the server. The TCP connection is denied if a PASV reply command is sent from the client. This prevents the security hole when the user executes "227 xxxxx a1, a2, a3, a4, p1, p2."
&#8226;TCP stream editing—The security appliance closes the connection if it detects TCP stream editing.
&#8226;Invalid port negotiation—The negotiated dynamic port value is checked to see if it is less than 1024. As port numbers in the range from 1 to 1024 are reserved for well-known connections, if the negotiated port falls in this range, then the TCP connection is freed.
&#8226;Command pipelining—The number of characters present after the port numbers in the PORT and PASV reply command is cross checked with a constant value of 8. If it is more than 8, then the TCP connection is closed.
&#8226;The security appliance replaces the FTP server response to the SYST command with a series of Xs. to prevent the server from revealing its system type to FTP clients. To override this default behavior, use the no mask-syst-reply command in the FTP map.
Configuring an FTP Inspection Policy Map for Additional Inspection Control FTP command filtering and security checks are provided using strict FTP inspection for improved security and control. Protocol conformance includes packet length checks, delimiters and packet format checks, command terminator checks, and command validation.
Blocking FTP based on user values is also supported so that it is possible for FTP sites to post files for download, but restrict access to certain users. You can block FTP connections based on file type, server name, and other attributes. System message logs are generated if an FTP connection is denied after inspection.
If you want FTP inspection to allow FTP servers to reveal their system type to FTP clients, and limit the allowed FTP commands, then create and configure an FTP map. You can then apply the FTP map when you enable FTP inspection according to the "Configuring Application Inspection" section.
To create an FTP map, perform the following steps:
Step 1 (Optional) Add one or more regular expressions for use in traffic matching commands according to the "Creating a Regular Expression" section on page 21-6. See the types of text you can match in the match commands described in Step 3.
Step 2 (Optional) Create one or more regular expression class maps to group regular expressions according to the "Creating a Regular Expression Class Map" section on page 21-9.
Step 3 (Optional) Create an FTP inspection class map by performing the following steps.
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. Create the class map by entering the following command:
hostname(config)# class-map type
inspect ftp [match-all | match-any]class_map_name
hostname(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. (Optional) To add a description to the class map, enter the following command:
hostname(config-cmap)# description string


c. (Optional) To match a filename for FTP transfer, enter the following command:
hostname(config-cmap)# match [not] filename 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.
d. (Optional) To match a file type for FTP transfer, enter the following command:
hostname(config-cmap)# match [not] filetype 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. (Optional) To disallow specific FTP commands, use the following command:
hostname(config-cmap)# match [not] request-command ftp_command [ftp_command...]


Where ftp_command with one or more FTP commands that you want to restrict. See Table 25-3 for a list of the FTP commands that you can restrict.
.

Table 25-3 FTP Map request-command deny Options  
request-command deny Option
Purpose
appe
Disallows the command that appends to a file.
cdup
Disallows the command that changes to the parent directory of the current working directory.
dele
Disallows the command that deletes a file on the server.
get
Disallows the client command for retrieving a file from the server.
help
Disallows the command that provides help information.
mkd
Disallows the command that makes a directory on the server.
put
Disallows the client command for sending a file to the server.
rmd
Disallows the command that deletes a directory on the server.
rnfr
Disallows the command that specifies rename-from filename.
rnto
Disallows the command that specifies rename-to filename.
site
Disallows the command that are specific to the server system. Usually used for remote administration.
stou
Disallows the command that stores a file using a unique file name.

f. (Optional) To match an FTP server, enter the following command:
hostname(config-cmap)# match [not] server 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.
g. (Optional) To match an FTP username, enter the following command:
hostname(config-cmap)# match [not] username 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.
Step 4 Create an FTP inspection policy map, enter the following command:
hostname(config)# policy-map type inspect ftp policy_map_name
hostname(config-pmap)#


Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration mode.
Step 5 (Optional) To add a description to the policy map, enter the following command:
hostname(config-pmap)# description string


Step 6 To apply actions to matching traffic, perform the following steps.
a. Specify the traffic on which you want to perform actions using one of the following methods:
&#8226;Specify the FTP class map that you created in Step 3 by entering the following command:
hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)#


&#8226;Specify traffic directly in the policy map using one of the match commands described in Step 3. If you use a match not command, then any traffic that does not match the criterion in the match not command has the action applied.
b. Specify the action you want to perform on the matching traffic by entering the following command:
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 Cisco Security Appliance 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 21-11.
Step 7 To configure parameters that affect the inspection engine, perform the following steps:
a. To enter parameters configuration mode, enter the following command:
hostname(config-pmap)# parameters
hostname(config-pmap-p)#


b. To mask the greeting banner from the FTP server, enter the following command:
hostname(config-pmap-p)# mask-banner


c. To mask the reply to syst command, enter the following command:
hostname(config-pmap-p)# mask-syst-reply


Before submitting a username and password, all FTP users are presented with a greeting banner. By default, this banner includes version information useful to hackers trying to identify weaknesses in a system. The following example shows how to mask this banner:


hostname(config)# policy-map type inspect ftp mymap
hostname(config-pmap)# parameters
hostname(config-pmap-p)# mask-banner


hostname(config)# class-map match-all ftp-traffic
hostname(config-cmap)# match port tcp eq ftp


hostname(config)# policy-map ftp-policy
hostname(config-pmap)# class ftp-traffic
hostname(config-pmap-c)# inspect ftp strict mymap


hostname(config)# service-policy ftp-policy interface inside


Verifying and Monitoring FTP Inspection FTP application inspection generates the following log messages:
&#8226;An Audit record 302002 is generated for each file that is retrieved or uploaded.
&#8226;The FTP command is checked to see if it is RETR or STOR and the retrieve and store commands are logged.
&#8226;The username is obtained by looking up a table providing the IP address.
&#8226;The username, source IP address, destination IP address, NAT address, and the file operation are logged.
&#8226;Audit record 201005 is generated if the secondary dynamic channel preparation failed due to memory shortage.
In conjunction with NAT, the FTP application inspection translates the IP address within the application payload. This is described in detail in RFC 959.
GTP Inspection This section describes the GTP inspection engine. This section includes the following topics:
&#8226; GTP Inspection Overview
&#8226; Configuring a GTP Inspection Policy Map for Additional Inspection Control
&#8226; Verifying and Monitoring GTP Inspection

Note GTP inspection requires a special license. If you enter GTP-related commands on a security appliance without the required license, the security appliance displays an error message.
GTP Inspection Overview GPRS provides uninterrupted connectivity for mobile subscribers between GSM networks and corporate networks or the Internet. The GGSN is the interface between the GPRS wireless data network and other networks. The SGSN performs mobility, data session management, and data compression (See Figure 25-3).
Figure 25-3 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 security appliance helps protect your network against these risks.
The SGSN is logically connected to a GGSN using GTP. GTP allows multiprotocol packets to be tunneled through the GPRS backbone between GSNs. GTP provides a tunnel control and management protocol that allows the SGSN to provide GPRS network access for a mobile station by creating, modifying, and deleting tunnels. GTP uses a tunneling mechanism to provide a service for carrying user data packets.

Note When using GTP with failover, if a GTP connection is established and the active unit fails before data is transmitted over the tunnel, the GTP data connection (with a "j" flag set) is not replicated to the standby unit. This occurs because the active unit does not replicate embryonic connections to the standby unit.
Configuring a GTP Inspection Policy Map for Additional Inspection Control If you want to enforce additional parameters on GTP traffic, create and configure a GTP map. If you do not specify a map with the inspect gtp command, the security appliance uses the default GTP map, which is preconfigured with the following default values:
&#8226;request-queue 200
&#8226;timeout gsn 0:30:00
&#8226;timeout pdp-context 0:30:00
&#8226;timeout request 0:01:00
&#8226;timeout signaling 0:30:00
&#8226;timeout tunnel 0:01:00
&#8226;tunnel-limit 500
To create and configure a GTP map, perform the following steps. You can then apply the GTP map when you enable GTP inspection according to the "Configuring Application Inspection" section.
Step 1 Create a GTP inspection policy map, enter the following command:
hostname(config)# policy-map type inspect gtp policy_map_name
hostname(config-pmap)#


Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration mode.
Step 2 (Optional) To add a description to the policy map, enter the following command:
hostname(config-pmap)# description string


Step 3 To match an Access Point name, enter the following command:
hostname(config-pmap)# match [not] apn 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.
Step 4 To match a message ID, enter the following command:
hostname(config-pmap)# match [not] message id
[message_id | range lower_range upper_range]


Where the message_id is an alphanumeric identifier between 1 and 255. The lower_range is lower range of message IDs. The upper_range is the upper range of message IDs.
Step 5 To match a message length, enter the following command:
hostname(config-pmap)# match [not] message length min min_length max max_length


Where the min_length and max_length are both between 1 and 65536. The length specified by this command is the sum of the GTP header and the rest of the message, which is the payload of the UDP packet.
Step 6 To match the version, enter the following command:
hostname(config-pmap)# match [not] version [version_id | range lower_range upper_range]


Where the version_id is between 0and 255. The lower_range is lower range of versions. The upper_range is the upper range of versions.
Step 7 To configure parameters that affect the inspection engine, perform the following steps:
a. To enter parameters configuration mode, enter the following command:
hostname(config-pmap)# parameters
hostname(config-pmap-p)#


The mnc network_code argument is a two or three-digit value identifying the network code.
By default, the security appliance does not check for valid MCC/MNC combinations. This command is used for IMSI Prefix filtering. The MCC and MNC in the IMSI of the received packet is compared with the MCC/MNC configured with this command and is dropped if it does not match.
This command must be used to enable IMSI Prefix filtering. You can configure multiple instances to specify permitted MCC and MNC combinations. By default, the security appliance does not check the validity of MNC and MCC combinations, so you must verify the validity of the combinations configured. To find more information about MCC and MNC codes, see the ITU E.212 recommendation, Identification Plan for Land Mobile Stations.
b. To allow invalid GTP packets or packets that otherwise would fail parsing and be dropped, enter the following command:
hostname(config-pmap-p)# permit errors


By default, all invalid packets or packets that failed, during parsing, are dropped.
c. To enable support for GSN 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 a object group that the responding GSN is permitted to send a GTP response to, the security appliance permits the response.
d. To create an object to represent the pool of load-balancing GSNs, perform the following steps:
Use the object-group command to define a new network object group representing the pool of load-balancing GSNs.
hostname(config)# object-group network GSN-pool-name
hostname(config-network)#


For example, the following command creates an object group named gsnpool32:
hostname(config)# object-group network gsnpool32
hostname(config-network)#


e. Use the network-object command to specify the load-balancing GSNs. You can do so with one network-object command per GSN, using the host keyword. You can also using network-object command to identify whole networks containing GSNs that perform load balancing.
hostname(config-network)# network-object host IP-address


For example, the following commands create three network objects representing individual hosts:
hostname(config-network)# network-object host 192.168.100.1
hostname(config-network)# network-object host 192.168.100.2
hostname(config-network)# network-object host 192.168.100.3
hostname(config-network)#


f. To create an object to represent the SGSN that the load-balancing GSNs are permitted to respond to, perform the following steps:
a. Use the object-group command to define a new network object group that will represent the SGSN that sends GTP requests to the GSN pool.
hostname(config)# object-group network SGSN-name
hostname(config-network)#


For example, the following command creates an object group named sgsn32:
hostname(config)# object-group network sgsn32
hostname(config-network)#


b. Use the network-object command with the host keyword to identify the SGSN.
hostname(config-network)# network-object host IP-address


For example, the following command creates a network objects representing the SGSN:
hostname(config-network)# network-object host 192.168.50.100
hostname(config-network)#


g. To allow GTP responses from any GSN in the network object representing the GSN pool, defined in c., d, to the network object representing the SGSN, defined in c., f., enter the following commands:
hostname(config)# gtp-map map_name
hostname(config-gtp-map)# permit response to-object-group SGSN-name from-object-group GSN-pool-name


For example, the following command permits GTP responses from any host in the object group named gsnpool32 to the host in the object group named sgsn32:
hostname(config-gtp-map)# permit response to-object-group sgsn32 from-object-group gsnpool32


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 but you can identify multiple individual IP addresses, one per network-object command, instead of identifying whole networks. The example then modifies a GTP map to permit responses from the GSN pool to the SGSN.
hostname(config)# object-group network gsnpool32
hostname(config-network)# network-object 192.168.100.0 255.255.255.0
hostname(config)# object-group network sgsn32
hostname(config-network)# network-object host 192.168.50.100
hostname(config)# gtp-map gtp-policy
hostname(config-gtp-map)# permit response to-object-group sgsn32 from-object-group gsnpool32


h. To specify the maximum number of GTP requests that will be queued waiting for a response, enter the following command:
hostname(config-gtp-map)# request-queue max_requests


where the max_requests argument sets the maximum number of GTP requests that will be queued waiting for a response, from 1 to 4294967295. The default is 200.
When the limit has been reached and a new request arrives, the request that has been in the queue for the longest time is removed. The Error Indication, the Version Not Supported and the SGSN Context Acknowledge messages are not considered as requests and do not enter the request queue to wait for a response.
i. To change the inactivity timers for a GTP session, enter the following command:
hostname(config-gtp-map)# timeout {gsn | pdp-context | request | signaling | tunnel} hh:mm:ss


Enter this command separately for each timeout.
The gsn keyword specifies the period of inactivity after which a GSN will be removed.
The pdp-context keyword specifies the maximum period of time allowed before beginning to receive the PDP context.
The request keyword specifies the maximum period of time allowed before beginning to receive the GTP message.
The signaling keyword specifies the period of inactivity after which the GTP signaling will be removed.
The tunnel keyword specifies the period of inactivity after which the GTP tunnel will be torn down.
The hh:mm:ss argument is the timeout where hh specifies the hour, mm specifies the minutes, and ss specifies the seconds. The value 0 means never tear down.
j. To specify the maximum number of GTP tunnels allowed to be active on the security appliance, enter the following command:
hostname(config-gtp-map)# tunnel-limit max_tunnels
where the max_tunnels argument is the maximum number of tunnels allowed, from 1 to 4294967295. The default is 500.
New requests will be dropped once the number of tunnels specified by this command is reached.
The following example shows how to limit the number of tunnels in the network:
hostname(config)# policy-map type inspect gtp gmap
hostname(config-pmap)# parameters
hostname(config-pmap-p)# tunnel-limit 3000


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


hostname(config)# service-policy global_policy global


Verifying and Monitoring GTP Inspection To display GTP configuration, enter the show service-policy inspect gtp
command in privileged EXEC mode. For the detailed syntax for this command, see the command page in the Cisco Security Appliance Command Reference.
Use the show service-policy inspect gtp statistics command to show the statistics for GTP inspection. The following is sample output from the show service-policy inspect gtp statistics command:
hostname# show service-policy inspect gtp statistics
GPRS GTP Statistics:
  version_not_support               0     msg_too_short             0
  unknown_msg                       0     unexpected_sig_msg        0
  unexpected_data_msg               0     ie_duplicated             0
  mandatory_ie_missing              0     mandatory_ie_incorrect    0
  optional_ie_incorrect             0     ie_unknown                0
  ie_out_of_order                   0     ie_unexpected             0
  total_forwarded                   0     total_dropped             0
  signalling_msg_dropped            0     data_msg_dropped          0
  signalling_msg_forwarded          0     data_msg_forwarded        0
  total created_pdp                 0     total deleted_pdp         0
  total created_pdpmcb              0     total deleted_pdpmcb      0
  pdp_non_existent                  0


You can use the vertical bar (|) to filter the display. Type ?| for more display filtering options.
The following is sample GSN output from the show service-policy inspect gtp statistics gsn command:
hostname# show service-policy inspect gtp statistics gsn 9.9.9.9
1 in use, 1 most used, timeout 0:00:00


GTP GSN Statistics for 9.9.9.9, Idle 0:00:00, restart counter 0
Tunnels Active 0        Tunnels Created 0
Tunnels Destroyed 0
Total Messages Received 2
Signaling Messages Data Messages
total received 2 0
dropped 0 0
forwarded 2 0


Use the show service-policy inspect gtp pdp-context command to display PDP context-related information. The following is sample output from the show service-policy inspect gtp pdp-context command:
hostname# show service-policy inspect gtp pdp-context detail
1 in use, 1 most used, timeout 0:00:00


Version TID                  MS Addr        SGSN Addr    Idle      APN
v1      1234567890123425         10.0.1.1        10.0.0.2 0:00:13  gprs.cisco.com


    user_name (IMSI): 214365870921435    MS address:         1.1.1.1
    primary pdp: Y                       nsapi: 2
    sgsn_addr_signal:        10.0.0.2    sgsn_addr_data:          10.0.0.2
    ggsn_addr_signal:        10.1.1.1    ggsn_addr_data:          10.1.1.1
    sgsn control teid:     0x000001d1    sgsn data teid:        0x000001d3
    ggsn control teid:     0x6306ffa0    ggsn data teid:        0x6305f9fc
    seq_tpdu_up:                    0    seq_tpdu_down:                 0
    signal_sequence:                0
    upstream_signal_flow:          0     upstream_data_flow:          0
    downstream_signal_flow:        0     downstream_data_flow:        0
    RAupdate_flow:                 0


The PDP context is identified by the tunnel ID, which is a combination of the values for IMSI and NSAPI. A GTP tunnel is defined by two associated PDP contexts in different GSN nodes and is identified with a Tunnel ID. A GTP tunnel is necessary to forward packets between an external packet data network and a MS user.
You can use the vertical bar (|) to filter the display, as in the following example:
hostname# show service-policy gtp statistics  |  grep gsn


H.323 Inspection This section describes the H.323 application inspection. This section includes the following topics:
&#8226; H.323 Inspection Overview
&#8226; How H.323 Works
&#8226; Limitations and Restrictions
&#8226; Configuring H.323 and H.225 Timeout Values
&#8226; Verifying and Monitoring H.323 Inspection
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 security appliance supports H.323 through Version 4, including H.323 v3 feature Multiple Calls on One Call Signaling Channel.
With H323 inspection enabled, the security appliance 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 security appliance.
The two major functions of H.323 inspection are as follows:
&#8226;NAT the necessary embedded IPv4 addresses in the H.225 and H.245 messages. Because H.323 messages are encoded in PER encoding format, the security appliance uses
an ASN.1 decoder to decode the H.323 messages.
&#8226;Dynamically allocate the negotiated H.245 and RTP/RTCP connections.
How H.323 Works The H.323 collection of protocols collectively may use up to two TCP connection and four to six UDP connections. FastConnect uses only one TCP connection, and 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 security appliance 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.
&#8226;1718—Gate Keeper Discovery UDP port
&#8226;1719—RAS UDP port
&#8226;1720—TCP Control Port
You must permit traffic for the well-known H.323 port 1720 for the H.225 call signaling; however, the H.245 signaling ports are negotiated between the endpoints in the H.225 signaling. When an H.323 gatekeeper is used, the security appliance opens an H.225 connection based on inspection of the ACF message.
After inspecting the H.225 messages, the security appliance opens the H.245 channel and then inspects traffic sent over the H.245 channel as well. All H.245 messages passing through the security appliance undergo H.245 application inspection, which translates 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 security appliance must remember the TPKT length to process and decode the messages properly. For each connection, the security appliance keeps a record that contains the TPKT length for the next expected message.
If the security appliance 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 security appliance proxy ACKs that TPKT and appends a new TPKT to the H.245 message with the new length.

Note The security appliance does not support TCP options in the Proxy ACK for the TPKT.
Each UDP connection with a packet going through H.323 inspection is marked as an H.323 connection and times out with the H.323 timeout as configured with the timeout command.
Limitations and Restrictions The following are some of the known issues and limitations when using H.323 application inspection:
&#8226;Static PAT may not properly translate IP addresses embedded in optional fields within H.323 messages. If you experience this kind of problem, do not use static PAT with H.323.
&#8226;H.323 application inspection is not supported with NAT between same-security-level interfaces.
&#8226;When a NetMeeting client registers with an H.323 gatekeeper and tries to call an H.323 gateway that is also registered with the H.323 gatekeeper, the connection is established but no voice is heard in either direction. This problem is unrelated to the security appliance.
&#8226;If you configure a network static address where the network static address is the same as a third-party netmask and address, then any outbound H.323 connection fails.
Configuring an H.323 Inspection Policy Map for Additional Inspection Control To specify actions when a message violates a parameter, create an H.323 inspection policy map. You can then apply the inspection policy map when you enable H.323 inspection according to the "Configuring Application Inspection" section.
To create an H.323 inspection policy map, perform the following steps:
Step 1 (Optional) Add one or more regular expressions for use in traffic matching commands according to the "Creating a Regular Expression" section on page 21-6. See the types of text you can match in the match commands described in Step 3.
Step 2 (Optional) Create one or more regular expression class maps to group regular expressions according to the "Creating a Regular Expression Class Map" section on page 21-9.s
Step 3 (Optional) Create an H.323 inspection class map by performing the following steps.
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-connection, reset, 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. Create the class map by entering the following command:
hostname(config)# class-map type
inspect h323 [match-all | match-any]class_map_name
hostname(config-cmap)#


Where the 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. (Optional) To add a description to the class map, enter the following command:
hostname(config-cmap)# description string


Where string is the description of the class map (up to 200 characters).
c. (Optional) To match a called party, enter the following command:
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. (Optional) To match a media type, enter the following command:
hostname(config-cmap)# match [not] media-type {audio | data |
video}


Step 4 Create an H.323 inspection policy map, enter the following command:
hostname(config)# policy-map type inspect h323 policy_map_name
hostname(config-pmap)#


Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration mode.
Step 5 (Optional) To add a description to the policy map, enter the following command:
hostname(config-pmap)# description string


Step 6 To apply actions to matching traffic, perform the following steps.
a. Specify the traffic on which you want to perform actions using one of the following methods:
&#8226;Specify the H.323 class map that you created in Step 3 by entering the following command:
hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)#


&#8226;Specify traffic directly in the policy map using one of the match commands described in Step 3. If you use a match not command, then any traffic that does not match the criterion in the match not command has the action applied.
b. Specify the action you want to perform on the matching traffic by entering the following command:
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 Cisco Security Appliance 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 21-11.
Step 7 To configure parameters that affect the inspection engine, perform the following steps:
a. To enter parameters configuration mode, enter the following command:
hostname(config-pmap)# parameters
hostname(config-pmap-p)#


b. To define the H.323 call duration limit, enter the following command:
hostname(config-pmap-p)# call-duration-limit time


Where time is the call duration limit in seconds. Range is from 0:0:0 ti 1163:0;0. A value of 0 means never timeout.
c. To enforce call party number used in call setup, enter the following command:
hostname(config-pmap-p)# call-party-number


d. To enforce H.245 tunnel blocking, enter the following command:
hostname(config-pmap-p)# h245-tunnel-block action {drop-connection | log}


e. To define an hsi group and enter hsi group configuration mode, enter the following command:
hostname(config-pmap-p)# hsi-group id


Where id is the hsi group ID. Range is from 0 to 2147483647.
To add an hsi to the hsi group, enter the following command in hsi group configuration mode:
hostname(config-h225-map-hsi-grp)# hsi ip_address


Where ip_address is the host to add. A maximum of five hosts per hsi group are allowed.
To add an endpoint to the hsi group, enter the following command in hsi group configuration mode:
hostname(config-h225-map-hsi-grp)# endpoint ip_address if_name


Where ip_address is the endpoint to add and if_name is the interface through which the endpoint is connected to the security appliance. A maximum of ten endpoints per hsi group are allowed.
f. To check RTP packets flowing on the pinholes for protocol conformance, enter the following command:
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.
g. To enable state checking validation, enter the following command:
hostname(config-pmap-p)# state-checking {h225 | ras}


The following example shows how to configure phone number filtering:
hostname(config)# regex caller 1 "5551234567"
hostname(config)# regex caller 2 "5552345678"
hostname(config)# regex caller 3 "5553456789"


hostname(config)# class-map type inspect h323 match-all h323_traffic
hostname(config-pmap-c)# match called-party regex caller1
hostname(config-pmap-c)# match calling-party regex caller2


hostname(config)# policy-map type inspect h323 h323_map
hostname(config-pmap)# parameters
hostname(config-pmap-p)# class h323_traffic
hostname(config-pmap-c)# drop


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:
&#8226; Monitoring H.225 Sessions
&#8226; Monitoring H.245 Sessions
&#8226; Monitoring H.323 RAS Sessions
Monitoring H.225 Sessions The show h225 command displays information for H.225 sessions established across the security appliance. Along with the debug h323 h225 event, debug h323 h245 event, and show local-host commands, this command is used for troubleshooting H.323 inspection engine issues.
Before entering the show h225, show h245, or show h323-ras commands, we recommend that you configure the pager command. If there are a lot of session records and the pager command is not configured, it may take a while for the show command output to reach its end. If there is an abnormally large number of connections, check that the sessions are timing out based on the default timeout values or the values set by you. If they are not, then there is a problem that needs to be investigated.
The following is sample output from the show h225 command:
hostname# show h225
Total H.323 Calls: 1
1 Concurrent Call(s) for
    Local:   10.130.56.3/1040   Foreign: 172.30.254.203/1720
    1. CRV 9861
    Local:   10.130.56.3/1040   Foreign: 172.30.254.203/1720
0 Concurrent Call(s) for
    Local:   10.130.56.4/1050   Foreign: 172.30.254.205/1720


This output indicates that there is currently 1 active H.323 call going through the security appliance 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 security appliance by endpoints using slow start. Slow start is when the two endpoints of a call open another TCP control channel for H.245. Fast start is where the H.245 messages are exchanged as part of the H.225 messages on the H.225 control channel.) Along with the debug h323 h245 event, debug h323 h225 event, and show local-host commands, this command is used for troubleshooting H.323 inspection engine issues.
The following is sample output from the show h245 command:
hostname# show h245
Total: 1
        LOCAL           TPKT    FOREIGN         TPKT
1       10.130.56.3/1041        0       172.30.254.203/1245    0
        MEDIA: LCN 258 Foreign 172.30.254.203 RTP 49608 RTCP 49609
                      Local   10.130.56.3 RTP 49608 RTCP 49609
        MEDIA: LCN 259 Foreign 172.30.254.203 RTP 49606 RTCP 49607
                      Local   10.130.56.3 RTP 49606 RTCP 49607


There is currently one H.245 control session active across the security appliance. 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 security appliance between a gatekeeper and its H.323 endpoint. Along with the debug h323 ras event and show local-host commands, this command is used for troubleshooting H.323 RAS inspection engine issues.
The show h323-ras command displays connection information for troubleshooting H.323 inspection engine issues. The following is sample output from the show h323-ras command:
hostname# show h323-ras
Total: 1
        GK                      Caller
        172.30.254.214 10.130.56.14


This output shows that there is one active registration between the gatekeeper 172.30.254.214 and its client 10.130.56.14.
HTTP Inspection This section describes the HTTP inspection engine. This section includes the following topics:
&#8226; HTTP Inspection Overview
&#8226; Configuring an HTTP Inspection Policy Map for Additional Inspection Control
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:
&#8226;Enhanced HTTP inspection
&#8226;URL screening through N2H2 or Websense
&#8226;Java and ActiveX filtering
The latter two features are configured in conjunction with the filter command. For more information about filtering, see "Applying Filtering Services."

Note The no inspect http command also disables the filter url command.
The enhanced HTTP inspection feature, which is also known as an application firewall 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:
&#8226;Conformance to RFC 2616
&#8226;Use of RFC-defined methods only.
&#8226;Compliance with the additional criteria.
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 When you enable HTTP inspection with an inspection policy map, strict HTTP inspection with the action reset and log is enabled by default. You can change the actions performed in response to inspection failure, but you cannot disable strict inspection as long as the inspection policy map remains enabled.
To create an HTTP inspection policy map, perform the following steps:
Step 1 (Optional) Add one or more regular expressions for use in traffic matching commands according to the "Creating a Regular Expression" section on page 21-6. See the types of text you can match in the match commands described in Step 3.
Step 2 (Optional) Create one or more regular expression class maps to group regular expressions according to the "Creating a Regular Expression Class Map" section on page 21-9.
Step 3 (Optional) Create an HTTP inspection class map by performing the following steps.
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. Create the class map by entering the following command:
hostname(config)# class-map type
inspect http [match-all | match-any]class_map_name
hostname(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. (Optional) To add a description to the class map, enter the following command:
hostname(config-cmap)# description string


c. (Optional) To match traffic with a content-type field in the HTTP response that does not match the accept field in the corresponding HTTP request message, enter the following command:
hostname(config-cmap)# match [not] req-resp content-type mismatch


d. (Optional) To match text found in the HTTP request message arguments, enter the following command:
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. (Optional) To match text found in the HTTP request message body or to match traffic that exceeds the maximum HTTP request message body length, enter the following command:
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. (Optional) To match text found in the HTTP request message header, or to restrict the count or length of the header, enter the following command:
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. (Optional) To match text found in the HTTP request message method, enter the following command:
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. (Optional) To match text found in the HTTP request message URI, enter the following command:
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. Optional) To match text found in the HTTP response message body, or to comment out Java applet and Active X object tags in order to filter them, enter the following command:
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. (Optional) To match text found in the HTTP response message header, or to restrict the count or length of the header, enter the following command:
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. (Optional) To match text found in the HTTP response message status line, enter the following command:
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 Create an HTTP inspection policy map, enter the following command:
hostname(config)# policy-map type inspect http policy_map_name
hostname(config-pmap)#


Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration mode.
Step 5 (Optional) To add a description to the policy map, enter the following command:
hostname(config-pmap)# description string


Step 6 To apply actions to matching traffic, perform the following steps.
a. Specify the traffic on which you want to perform actions using one of the following methods:
&#8226;Specify the HTTP class map that you created in Step 3 by entering the following command:
hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)#


&#8226;Specify traffic directly in the policy map using one of the match commands described in Step 3. If you use a match not command, then any traffic that does not match the criterion in the match not command has the action applied.
b. Specify the action you want to perform on the matching traffic by entering the following command:
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 Cisco Security Appliance 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 21-11.
Step 7 To configure parameters that affect the inspection engine, perform the following steps:
a. To enter parameters configuration mode, enter the following command:
hostname(config-pmap)# parameters
hostname(config-pmap-p)#


b. To check for HTTP protocol violations, enter the following command:
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. To substitute a string for the server header field, enter the following command:
hostname(config-pmap-p)# spoof-server string


Where the string argument is the string to substitute for the server header field. Note: WebVPN streams are not subject to the spoof-server comand.
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\.xyz.com/.*\.asp" or "www\.xyz[0-9][0-9]\.com" with methods "GET" or "PUT." All other URL/Method combinations will be silently allowed.
hostname(config)# regex url1 "www\.xyz.com/.*\.asp"
hostname(config)# regex url2 "www\.xyz[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_log
hostname(config-cmap)# match regex url1
hostname(config-cmap)# match regex url2
hostname(config-cmap)# exit


hostname(config)# class-map type regex match-any methods_to_log
hostname(config-cmap)# match regex get
hostname(config-cmap)# match regex put
hostname(config-cmap)# exit


hostname(config)# class-map type inspect http http_url_policy
hostname(config-cmap)# match request uri regex class url_to_log
hostname(config-cmap)# match request method regex class methods_to_log
hostname(config-cmap)# exit


hostname(config)# policy-map type inspect http http_policy
hostname(config-pmap)# class http_url_policy
hostname(config-pmap-c)# log


Instant Messaging Inspection This section describes the IM inspection engine. This section includes the following topics:
&#8226; IM Inspection Overview
&#8226; Configuring an Instant Messaging Inspection Policy Map for Additional Inspection Control
IM Inspection Overview The IM inspect engine lets you apply fine grained controls on the IM application to control the network usage and stop leakage of confidential data, propagation of worms, and other threats to the corporate network.
Configuring an Instant Messaging Inspection Policy Map for Additional Inspection Control To specify actions when a message violates a parameter, create an IM inspection policy map. You can then apply the inspection policy map when you enable IM inspection according to the "Configuring Application Inspection" section.
To create an IM inspection policy map, perform the following steps:
Step 1 (Optional) Add one or more regular expressions for use in traffic matching commands according to the "Creating a Regular Expression" section on page 21-6. See the types of text you can match in the match commands described in Step 3.
Step 2 (Optional) Create one or more regular expression class maps to group regular expressions according to the "Creating a Regular Expression Class Map" section on page 21-9.s
Step 3 (Optional) Create an IM inspection class map by performing the following steps.
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-connection, reset, 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. Create the class map by entering the following command:
hostname(config)# class-map type
inspect im [match-all | match-any]class_map_name
hostname(config-cmap)#


Where the 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. (Optional) To add a description to the class map, enter the following command:
hostname(config-cmap)# description string


Where the string is the description of the class map (up to 200 characters).
c. (Optional) To match traffic of a specific IM protocol, such as Yahoo or MSN, enter the following command:
hostname(config-cmap)# match [not] protocol {im-yahoo | im-msn}


d. (Optional) To match a specific IM service, such as chat, file-transfer, webcam, voice-chat, conference, or games, enter the following command:
hostname(config-cmap)# match [not] service {chat | file-transfer | webcam | voice-chat | conference | games}


e. (Optional) To match the source login name of the IM message, enter the following command:
hostname(config-cmap)# match [not]login-name 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.
f. (Optional) To match the destination login name of the IM message, enter the following command:
hostname(config-cmap)# match [not] peer-login-name 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. (Optional) To match the source IP address of the IM message, enter the following command:
hostname(config-cmap)# match [not]ip-address ip_address ip_address_mask


Where the ip_address and the ip_address_mask is the IP address and netmask of the message source.
h. (Optional) To match the destination IP address of the IM message, enter the following command:
hostname(config-cmap)# match [not]peer-ip-address ip_address ip_address_mask


Where the ip_address and the ip_address_mask is the IP address and netmask of the message destination.
i. (Optional) To match the version of the IM message, enter the following command:
hostname(config-cmap)# match [not] version 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.
j. (Optional) To match the filename of the IM message, enter the following command:
hostname(config-cmap)# match [not] filename 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.

Note Not supported using MSN IM protocol.
Step 4 Create an IM inspection policy map, enter the following command:
hostname(config)# policy-map type inspect im policy_map_name
hostname(config-pmap)#


Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration mode.
Step 5 (Optional) To add a description to the policy map, enter the following command:
hostname(config-pmap)# description string


Step 6 Specify the traffic on which you want to perform actions using one of the following methods:
&#8226;Specify the IM class map that you created in Step 3 by entering the following command:
hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)#


&#8226;Specify traffic directly in the policy map using one of the match commands described in Step 3. If you use a match not command, then any traffic that does not match the criterion in the match not command has the action applied.
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 21-11.
Step 7 Specify the action you want to perform on the matching traffic by entering the following command:
hostname(config-pmap-c)# {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.
The following example shows how to define an IM inspection policy map.
hostname(config)# regex loginname1 "ying\@yahoo.com"
hostname(config)# regex loginname2 "Kevin\@yahoo.com"
hostname(config)# regex loginname3 "rahul\@yahoo.com"
hostname(config)# regex loginname3 "darshant\@yahoo.com"
hostname(config)# regex yhoo_version_regex "1\.0"


hostname(config)# class-map type regex match-any yahoo_src_login_name_regex
hostname(config-cmap)# match regex loginname1
hostname(config-cmap)# match regex loginname2


hostname(config)# class-map type regex match-any yahoo_dst_login_name_regex
hostname(config-cmap)# match regex loginname3
hostname(config-cmap)# match regex loginname4


hostname(config)# class-map type regex match-any yhoo_file_block_list
hostname(config-cmap)# match regex ".*\.gif"
hostname(config-cmap)# match regex ".*\.exe"


hostname(config)# class-map type regex match-any new_im_regexp
hostname(config-cmap)# match regexp "new_im_regexp"


hostname(config)# class-map type inspect im match-all yahoo_im_policy
hostname(config-cmap)# match login-name regex class yhoo_src_login_name_regex
hostname(config-cmap)# match peer-login-name regex class yhoo_dst_login_name_regex


hostname(config)# class-map type inspect im yahoo_im_policy2
hostname(config-cmap)# match version regex yahoo_version_regex


hostname(config)# class-map im_inspect_class_map
hostname(config-cmap)# match default-inspection-traffic


hostname(config)# policy-map type im im_policy_all
hostname(config-pmap)# class yahoo_in_file_xfer_policy
hostname(config-pmap-c)# drop-connection
hostname(config-pmap)# class yhoo_im_policy
hostname(config-pmap-c)# drop-connection
hostname(config-pmap)# class yhoo_im_policy2
hostname(config-pmap-c)# reset
hostname(config-pmap)# match im-pattern regex class new_im_regexp
hostname(config-pmap-c)# action log
hostname(config)# policy-map global_policy_name
hostname(config-pmap)# class im_inspection_class_map
hostname(config-pmap-c)# inspect im im_policy_all


ICMP Inspection The ICMP inspection engine allows ICMP traffic to have a "session" so it can be inspected like TCP and UDP traffic. Without the ICMP inspection engine, we recommend that you do not allow ICMP through the security appliance in an access list. Without stateful inspection, ICMP can be used to attack your network. The ICMP inspection engine ensures that there is only one response for each request, and that the sequence number is correct.
ICMP Error Inspection When this feature is enabled, the security appliance creates translation sessions for intermediate hops that send ICMP error messages, based on the NAT configuration. The security appliance overwrites the packet with the translated IP addresses.
When disabled, the security appliance does not create translation sessions for intermediate nodes that generate ICMP error messages. ICMP error messages generated by the intermediate nodes between the inside host and the security appliance reach the outside host without consuming any additional NAT resource. This is undesirable when an outside host uses the traceroute command to trace the hops to the destination on the inside of the security appliance. When the security appliance does not translate the intermediate hops, all the intermediate hops appear with the mapped destination IP address.
The ICMP payload is scanned to retrieve the five-tuple from the original packet. Using the retrieved five-tuple, a lookup is performed to determine the original address of the client. The ICMP error inspection engine makes the following changes to the ICMP packet:
&#8226;In the IP Header, the mapped IP is changed to the real IP (Destination Address) and the IP checksum is modified.
&#8226;In the ICMP Header, the ICMP checksum is modified due to the changes in the ICMP packet.
&#8226;In the Payload, the following changes are made:
–Original packet mapped IP is changed to the real IP
–Original packet mapped port is changed to the real Port
–Original packet IP checksum is recalculated
ILS Inspection The ILS inspection engine provides NAT support for Microsoft NetMeeting, SiteServer, and Active Directory products that use LDAP to exchange directory information with an ILS server.
The security appliance supports NAT for ILS, which is used to register and locate endpoints in the ILS or SiteServer Directory. PAT cannot be supported because only IP addresses are stored by an LDAP database.
For search responses, when the LDAP server is located outside, NAT should be considered to allow internal peers to communicate locally while registered to external LDAP servers. For such search responses, xlates are searched first, and then DNAT entries to obtain the correct address. If both of these searches fail, then the address is not changed. For sites using NAT 0 (no NAT) and not expecting DNAT interaction, we recommend that the inspection engine be turned off to provide better performance.
Additional configuration may be necessary when the ILS server is located inside the security appliance border. This would require a hole for outside clients to access the LDAP server on the specified port, typically TCP 389.
Because ILS traffic only occurs on the secondary UDP channel, the TCP connection is disconnected after the TCP inactivity interval. By default, this interval is 60 minutes and can be adjusted using the timeout command.
ILS/LDAP follows a client/server model with sessions handled over a single TCP connection. Depending on the client's actions, several of these sessions may be created.
During connection negotiation time, a BIND PDU is sent from the client to the server. Once a successful BIND RESPONSE from the server is received, other operational messages may be exchanged (such as ADD, DEL, SEARCH, or MODIFY) to perform operations on the ILS Directory. The ADD REQUEST and SEARCH RESPONSE PDUs may contain IP addresses of NetMeeting peers, used by H.323 (SETUP and CONNECT messages) to establish the NetMeeting sessions. Microsoft NetMeeting v2.X and v3.X provides ILS support.
The ILS inspection performs the following operations:
&#8226;Decodes the LDAP REQUEST/RESPONSE PDUs using the BER decode functions
&#8226;Parses the LDAP packet
&#8226;Extracts IP addresses
&#8226;Translates IP addresses as necessary
&#8226;Encodes the PDU with translated addresses using BER encode functions
&#8226;Copies the newly encoded PDU back to the TCP packet
&#8226;Performs incremental TCP checksum and sequence number adjustment
ILS inspection has the following limitations:
&#8226;Referral requests and responses are not supported
&#8226;Users in multiple directories are not unified
&#8226;Single users having multiple identities in multiple directories cannot be recognized by NAT

Note Because H225 call signalling traffic only occurs on the secondary UDP channel, the TCP connection is disconnected after the interval specified by the TCP timeout command. By default, this interval is set at 60 minutes.
MGCP Inspection This section describes MGCP application inspection. This section includes the following topics:
&#8226; MGCP Inspection Overview
&#8226; Configuring an MGCP Inspection Policy Map for Additional Inspection Control
&#8226; Configuring MGCP Timeout Values
&#8226; Verifying and Monitoring MGCP Inspection
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:
&#8226;Trunking gateways, that interface between the telephone network and a Voice over IP network. Such gateways typically manage a large number of digital circuits.
&#8226;Residential gateways, that provide a traditional analog (RJ11) interface to a Voice over IP network. Examples of residential gateways include cable modem/cable set-top boxes, xDSL devices, broad-band wireless devices.
&#8226;Business gateways, that provide a traditional digital PBX interface or an integrated soft PBX interface to a Voice over IP network.

Note To avoid policy failure when upgrading from ASA version 7.1, all layer 7 and layer 3 policies must have distinct names. For instance, a previously configured policy map with the same name as a previously configured MGCP map must be changed before the upgrade.
MGCP messages are transmitted over UDP. A response is sent back to the source address (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 25-4 illustrates how NAT can be used with MGCP.
Figure 25-4 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:
&#8226;CreateConnection
&#8226;ModifyConnection
&#8226;DeleteConnection
&#8226;NotificationRequest
&#8226;Notify
&#8226;AuditEndpoint
&#8226;AuditConnection
&#8226;RestartInProgress
The first four commands are sent by the call agent to the gateway. The Notify command is sent by the gateway to the call agent. The gateway may also send a DeleteConnection. 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.
&#8226;The port on which the gateway receives commands from the call agent. Gateways usually listen to UDP port 2427.
&#8226;The port on which the call agent receives commands from the gateway. Call agents usually listen to UDP port 2727.

Note MGCP inspection does not support the use of different IP addresses for MGCP signaling and RTP data. A common and recommended practice is to send RTP data from a resilient IP address, such as a loopback or virtual IP address; however, the security appliance requires the RTP data to come from the same address as MGCP signalling.
Configuring an MGCP Inspection Policy Map for Additional Inspection Control If the network has multiple call agents and gateways for which the security appliance has to open pinholes, create an MGCP map. You can then apply the MGCP map when you enable MGCP inspection according to the "Configuring Application Inspection" section
To create an MGCP map, perform the following steps:
Step 1 To create an MGCP inspection policy map, enter the following command:
hostname(config)# policy-map type inspect mgcp map_name
hostname(config-pmap)#


Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration mode.
Step 2 (Optional) To add a description to the policy map, enter the following command:
hostname(config-pmap)# description string


Step 3 To configure parameters that affect the inspection engine, perform the following steps:
a. To enter parameters configuration mode, enter the following command:
hostname(config-pmap)# parameters
hostname(config-pmap-p)#


b. To configure the call agents, enter the following command for each call agent:
hostname(config-pmap-p)# call-agent ip_address group_id


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.

Note MGCP call agents send AUEP messages to determine if MGCP end points are present. This establishes a flow through the security appliance and allows MGCP end points to register with the call agent.
c. To configure the gateways, enter the following command for each gateway:
hostname(config-pmap-p)# gateway ip_address group_id


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.
d. If you want to change the maximum number of commands allowed in the MGCP command queue, enter the following command:
hostname(config-pmap-p)# command-queue command_limit


The following example shows how to define an MGCP map:
hostname(config)# policy-map type inspect mgcp sample_map
hostname(config-pmap)# parameters
hostname(config-pmap-p)# call-agent 10.10.11.5 101
hostname(config-pmap-p)# call-agent 10.10.11.6 101
hostname(config-pmap-p)# call-agent 10.10.11.7 102
hostname(config-pmap-p)# call-agent 10.10.11.8 102
hostname(config-pmap-p)# gateway 10.10.10.115 101
hostname(config-pmap-p)# gateway 10.10.10.116 102
hostname(config-pmap-p)# gateway 10.10.10.117 102
hostname(config-pmap-p)# command-queue 150


Configuring MGCP Timeout Values The timeout mgcp command lets you set the interval for inactivityafter which an MGCP media connection is closed. The default is 5 minutes.
The timeout mgcp-pat command lets you set the timeout for PAT xlates. Because MGCP does not have a keepalive mechanism, if you use non-Cisco MGCP gateways (call agents), the PAT xlates are torn down after the default timeout interval, which is 30 seconds.
Verifying and Monitoring MGCP Inspection The show mgcp commands command lists the number of MGCP commands in the command queue. The show mgcp sessions command lists the number of existing MGCP sessions. The detail option includes additional information about each command (or session) in the output. The following is sample output from the show mgcp commands command:
hostname# show mgcp commands
1 in use, 1 most used, 200 maximum allowed
CRCX, gateway IP: host-pc-2, transaction ID: 2052, idle: 0:00:07


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


The following is sample output from the show mgcp sessions command.
hostname# show mgcp sessions
1 in use, 1 most used
Gateway IP host-pc-2, connection ID 6789af54c9, active 0:00:11


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


NetBIOS Inspection NetBIOS inspection is enabled by default. The NetBios inspection engine translates IP addresses in the NetBios name service (NBNS) packets according to the security appliance NAT configuration.
Configuring a NetBIOS Inspection Policy Map for Additional Inspection Control To specify actions when a message violates a parameter, create a NETBIOS inspection policy map. You can then apply the inspection policy map when you enable NETBIOS inspection according to the "Configuring Application Inspection" section.
To create a NETBIOS inspection policy map, perform the following steps:
Step 1 (Optional) Add one or more regular expressions for use in traffic matching commands according to the "Creating a Regular Expression" section on page 21-6. See the types of text you can match in the match commands described in Step 3.
Step 2 (Optional) Create one or more regular expression class maps to group regular expressions according to the "Creating a Regular Expression Class Map" section on page 21-9.
Step 3 Create a NetBIOS inspection policy map, enter the following command:
hostname(config)# policy-map type inspect netbios policy_map_name
hostname(config-pmap)#


Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration mode.
Step 4 (Optional) To add a description to the policy map, enter the following command:
hostname(config-pmap)# description string


Step 5 To apply actions to matching traffic, perform the following steps.
a. Specify the traffic on which you want to perform actions using one of the following methods:
&#8226;Specify the NetBIOS class map that you created in Step 3 by entering the following command:
hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)#


&#8226;Specify traffic directly in the policy map using one of the match commands described in Step 3. If you use a match not command, then any traffic that does not match the criterion in the match not command has the action applied.
b. Specify the action you want to perform on the matching traffic by entering the following command:
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 Cisco Security Appliance 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 21-11.
Step 6 To configure parameters that affect the inspection engine, perform the following steps:
a. To enter parameters configuration mode, enter the following command:
hostname(config-pmap)# parameters
hostname(config-pmap-p)#


b. To check for NETBIOS protocol violations, enter the following command:
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.
The following example shows how to define a NETBIOS inspection policy map.
hostname(config)# policy-map type inspect netbios netbios_map
hostname(config-pmap)# protocol-violation drop log


hostname(config)# policy-map netbios_policy
hostname(config-pmap)# class inspection_default
hostname(config-pmap-c)# inspect netbios netbios_map


PPTP Inspection PPTP is a protocol for tunneling PPP traffic. A PPTP session is composed of one TCP channel and usually two PPTP GRE tunnels. The TCP channel is the control channel used for negotiating and managing the PPTP GRE tunnels. The GRE tunnels carries PPP sessions between the two hosts.
When enabled, PPTP application inspection inspects PPTP protocol packets and dynamically creates the GRE connections and xlates necessary to permit PPTP traffic. Only Version 1, as defined in RFC 2637, is supported.
PAT is only performed for the modified version of GRE [RFC 2637] when negotiated over the PPTP TCP control channel. Port Address Translation is not performed for the unmodified version of GRE [RFC 1701, RFC 1702].
Specifically, the security appliance inspects the PPTP version announcements and the outgoing call request/response sequence. Only PPTP Version 1, as defined in RFC 2637, is inspected. Further inspection on the TCP control channel is disabled if the version announced by either side is not Version 1. In addition, the outgoing-call request and reply sequence are tracked. Connections and xlates are dynamic allocated as necessary to permit subsequent secondary GRE data traffic.
The PPTP inspection engine must be enabled for PPTP traffic to be translated by PAT. Additionally, PAT is only performed for a modified version of GRE (RFC2637) and only if it is negotiated over the PPTP TCP control channel. PAT is not performed for the unmodified version of GRE (RFC 1701 and RFC 1702).
As described in RFC 2637, the PPTP protocol is mainly used for the tunneling of PPP sessions initiated from a modem bank PAC (PPTP Access Concentrator) to the headend PNS (PPTP Network Server). When used this way, the PAC is the remote client and the PNS is the server.
However, when used for VPN by Windows, the interaction is inverted. The PNS is a remote single-user PC that initiates connection to the head-end PAC to gain access to a central network.
RADIUS Accounting Inspection One of the well known problems is the over-billing attack in GPRS networks. The over-billing attack can cause consumers anger and frustration by being billed for services that they have not used. In this case, a malicious attacker sets up a connection to a server and obtains an IP address from the SGSN. When the attacker ends the call, the malicious server will still send packets to it, which gets dropped by the GGSN, but the connection from the server remains active. The IP address assigned to the malicious attacker gets released and reassigned to a legitimate user who will then get billed for services that the attacker will use.
RADIUS accounting inspection prevents this type of attack using by ensuring the traffic seen by the GGSN is legitimate. With the RADIUS accounting feature properly configured, the security appliance tears down a connection based on matching the Framed IP attribute in the Radius Accounting Request Start message with the Radius Accounting Request Stop message. When the Stop message is seen with the matching IP address in the Framed IP attribute, the security appliance looks for all connections with the source matching the IP address.
You have the option to configure a secret pre-shared key with the RADIUS server so the security appliance can validate the message. If the shared secret is not configured, the security appliance does not need to validate the source of the message and will only check that the source IP address is one of the configured addresses allowed to send the RADIUS messages.
Configuring a RADIUS Inspection Policy Map for Additional Inspection Control In order to use this feature, the radius-accounting-map will need to be specified in the policy-map type management and then applied to the service-policy using the new control-plane keyword to specify that this traffic is for to-the-box inspection.
The following example shows the complete set of commands in context to properly configure this feature:
Step 1 Configure the class map and the port:
class-map type management c1
  match port udp eq 1888
Step 2 Create the policy map, and configure the parameters for RADIUS accounting inspection using the parameter command to access the proper mode to configure the attributes, host, and key.
policy-map type inspect radius-accounting radius_accounting_map
  parameters
    host 10.1.1.1 inside key 123456789
    send response
    enable gprs
    validate-attribute 22
Step 3 Configure the service policy and control-plane keywords.
policy-map type management global_policy
  class c1
     inspect radius-accounting radius_accounting_map


service-policy global_policy control-plane abc global
RSH Inspection RSH inspection is enabled by default. The RSH protocol uses a TCP connection from the RSH client to the RSH server on TCP port 514. The client and server negotiate the TCP port number where the client listens for the STDERR output stream. RSH inspection supports NAT of the negotiated port number if necessary.
RTSP Inspection This section describes RTSP application inspection. This section includes the following topics:
&#8226; RTSP Inspection Overview
&#8226; Using RealPlayer
&#8226; Restrictions and Limitations
RTSP Inspection Overview The RTSP inspection engine lets the security appliance pass RTSP packets. RTSP is used by RealAudio, RealNetworks, Apple QuickTime 4, RealPlayer, and Cisco IP/TV connections.

Note For Cisco IP/TV, use RTSP TCP port 554 and TCP 8554.
RTSP applications use the well-known port 554 with TCP (rarely UDP) as a control channel. The security appliance only supports TCP, 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 security appliance parses Setup response messages with a status code of 200. If the response message is travelling inbound, the server is outside relative to the security appliance and dynamic channels need to be opened for connections coming inbound from the server. If the response message is outbound, then the security appliance 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 security appliance 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 does not support PAT or dual-NAT. Also, the security appliance cannot recognize HTTP cloaking where RTSP messages are hidden in the HTTP messages.
Using RealPlayer When using RealPlayer, it is important to properly configure transport mode. For the security appliance, add an access-list command from the server to the client or vice versa. For RealPlayer, change transport mode by clicking Options>Preferences>Transport>RTSP Settings.
If using TCP mode on the RealPlayer, select the Use TCP to Connect to Server and Attempt to use TCP for all content check boxes. On the security appliance, there is no need to configure the inspection engine.
If using UDP mode on the RealPlayer, select 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 security appliance, add an inspect rtsp port command.
Restrictions and Limitations The following restrictions apply to the inspect rtsp command.
&#8226;The security appliance does not support multicast RTSP or RTSP messages over UDP.
&#8226;PAT is not supported.
&#8226;The security appliance does not have the ability to recognize HTTP cloaking where RTSP messages are hidden in the HTTP messages.
&#8226;The security appliance cannot perform NAT on RTSP messages because the embedded IP addresses are contained in the SDP files as part of HTTP or RTSP messages. Packets could be fragmented and security appliance cannot perform NAT on fragmented packets.
&#8226;With Cisco IP/TV, the number of translates the security appliance performs on the SDP part of the message is proportional to the number of program listings in the Content Manager (each program listing can have at least six embedded IP addresses).
&#8226;You can configure NAT for Apple QuickTime 4 or RealPlayer. Cisco IP/TV only works with NAT if the Viewer and Content Manager are on the outside network and the server is on the inside network.
Configuring an RTSP Inspection Policy Map for Additional Inspection Control To specify actions when a message violates a parameter, create an RTSP inspection policy map. You can then apply the inspection policy map when you enable RTSP inspection according to the "Configuring Application Inspection" section.
To create an RTSP inspection policy map, perform the following steps:
Step 1 (Optional) Add one or more regular expressions for use in traffic matching commands according to the "Creating a Regular Expression" section on page 21-6. See the types of text you can match in the match commands described in Step 3.
Step 2 (Optional) Create one or more regular expression class maps to group regular expressions according to the "Creating a Regular Expression Class Map" section on page 21-9.
Step 3 (Optional) Create an RTSP inspection class map by performing the following steps.
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-connection 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. Create the class map by entering the following command:
hostname(config)# class-map type
inspect rtsp [match-all | match-any]class_map_name
hostname(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. (Optional) To add a description to the class map, enter the following command:
hostname(config-cmap)# description string


c. (Optional) To match an RTSP request method, enter the following command:
hostname(config-cmap)# match [not] request-method method


Where method is the type of method to match (announce, describe, get_parameter, options, pause, play, record, redirect, setup, set_parameter, teardown).
d. (Optional) To match URL filtering, enter the following command:
hostname(config-cmap)# match [not] url-filter 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.
Step 4 To create an RTSP inspection policy map, enter the following command:
hostname(config)# policy-map type inspect rtsp policy_map_name
hostname(config-pmap)#


Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration mode.
Step 5 (Optional) To add a description to the policy map, enter the following command:
hostname(config-pmap)# description string


Step 6 To apply actions to matching traffic, perform the following steps.
a. Specify the traffic on which you want to perform actions using one of the following methods:
&#8226;Specify the RTSP class map that you created in Step 3 by entering the following command:
hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)#


&#8226;Specify traffic directly in the policy map using one of the match commands described in Step 3. If you use a match not command, then any traffic that does not match the criterion in the match not command has the action applied.
b. Specify the action you want to perform on the matching traffic by entering the following command:
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 Cisco Security Appliance 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 21-11.
Step 7 To configure parameters that affect the inspection engine, perform the following steps:
a. To enter parameters configuration mode, enter the following command:
hostname(config-pmap)# parameters
hostname(config-pmap-p)#


b. To restrict usage on reserve port for media negotiation, enter the following command:
hostname(config-pmap-p)# reserve-port-protect


c. To set the limit on the URL length allowed in the message, enter the following command:
hostname(config-pmap-p)# url-length-limit length


Where the length argument specifies the URL length in bytes (0 to 6000).
The following example shows a how to define an RTSP inspection policy map.
hostname(config)# regex badurl1 www.url1.com/rtsp.avi
hostname(config)# regex badurl2 www.url2.com/rtsp.rm
hostname(config)# regex badurl3 www.url3.com/rtsp.asp


hostname(config)# class-map type regex match-any badurl-list
hostname(config-cmap)# match regex badurl1
hostname(config-cmap)# match regex badurl2
hostname(config-cmap)# match regex badurl3


hostname(config)# policy-map type inspect rtsp rtsp-filter-map
hostname(config-pmap)# match url-filter regex class badurl-list
hostname(config-pmap-p)# drop-connection


hostname(config)# class-map rtsp-traffic-class
hostname(config-cmap)# match default-inspection-traffic


hostname(config)# policy-map rtsp-traffic-policy
hostname(config-pmap)# class rtsp-traffic-class
hostname(config-pmap-c)# inspect rtsp rtsp-filter-map


hostname(config)# service-policy rtsp-traffic-policy global
SIP Inspection This section describes SIP application inspection. This section includes the following topics:
&#8226; SIP Inspection Overview
&#8226; SIP Instant Messaging
&#8226; Configuring SIP Timeout Values
&#8226; Verifying and Monitoring SIP Inspection
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 security appliance can support any SIP VoIP gateways and VoIP proxy servers. SIP and SDP are defined in the following RFCs:
&#8226;SIP: Session Initiation Protocol, RFC 3261
&#8226;SDP: Session Description Protocol, RFC 2327
To support SIP calls through the security appliance, signaling messages for the media connection addresses, media ports, and embryonic connections for the media must be inspected, because while the signaling is sent over a well-known destination port (UDP/TCP 5060), the media streams are dynamically allocated. Also, SIP embeds IP addresses in the user-data portion of the IP packet. SIP inspection applies NAT for these embedded IP addresses.
The following limitations and restrictions apply when using PAT with SIP:
&#8226;If a remote endpoint tries to register with a SIP proxy on a network protected by the security appliance, the registration fails under very specific conditions, as follows:
–PAT is configured for the remote endpoint.
–The SIP registrar server is on the outside network.
–The port is missing in the contact field in the REGISTER message sent by the endpoint to the proxy server.
&#8226;If a SIP device transmits a packet in which the SDP portion has an IP address in the owner/creator field (o=) that is different than the IP address in the connection field (c=), the IP address in the o= field may not be properly translated. This is due to a limitation in the SIP protocol, which does not provide a port value in the o= field.
SIP Instant Messaging Instant Messaging refers to the transfer of messages between users in near real-time. SIP supports the Chat feature on Windows XP using Windows Messenger RTC Client version 4.7.0105 only. The MESSAGE/INFO methods and 202 Accept response are used to support IM as defined in the following RFCs:
&#8226;Session Initiation Protocol (SIP)-Specific Event Notification, RFC 3265
&#8226;Session Initiation Protocol (SIP) Extension for Instant Messaging, RFC 3428
MESSAGE/INFO requests can come in at any time after registration/subscription. For example, two users can be online at any time, but not chat for hours. Therefore, the SIP inspection engine opens pinholes that time out according to the configured SIP timeout value. This value must be configured at least five minutes longer than the subscription duration. The subscription duration is defined in the Contact Expires value and is typically 30 minutes.
Because MESSAGE/INFO requests are typically sent using a dynamically allocated port other than port 5060, they are required to go through the SIP inspection engine.

Note Only the Chat feature is currently supported. Whiteboard, File Transfer, and Application Sharing are not supported. RTC Client 5.0 is not supported.
SIP inspection translates 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 security appliance 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 translated.
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 security appliance, unless the security appliance
configuration specifically allows it.
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 (Optional) Add one or more regular expressions for use in traffic matching commands according to the "Creating a Regular Expression" section on page 21-6. See the types of text you can match in the match commands described in Step 3.
Step 2 (Optional) Create one or more regular expression class maps to group regular expressions according to the "Creating a Regular Expression Class Map" section on page 21-9.s
Step 3 (Optional) Create a SIP inspection class map by performing the following steps.
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-connection, reset, 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. Create the class map by entering the following command:
hostname(config)# class-map type
inspect sip [match-all | match-any]class_map_name
hostname(config-cmap)#


Where the 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 leX ( The CLI enters class-map configuration mode, where you can enter one or more match commands.
b. (Optional) To add a description to the class map, enter the following command:
hostname(config-cmap)# description string


Where string is the description of the class map (up to 200 characters).
c. (Optional) To match a called party, as specified in the To header, enter the following command:
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. (Optional) To match a calling party, as specified in the From header, enter the following command:
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. (Optional) To match a content length in the SIP header, enter the following command:
hostname(config-cmap)# match [not]content length gt length


Where length is the number of bytes the content length is greater than. 0 to 65536.
f. (Optional) To match an SDP content type or regular expression, enter the following command:
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. (Optional) To match a SIP IM subscriber, enter the following command:
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. (Optional) To match a SIP via header, enter the following command:
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. (Optional) To match a SIP request method, enter the following command:
hostname(config-cmap)# match [not] request-method method


Where method is the type of method to match (ack, bye, cancel, info, invite, message, notify, options, prack, refer, register, subscribe, unknown, update).
j. (Optional) To match the requester of a third-party registration, enter the following command:
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. (Optional) To match an URI in the SIP headers, enter the following command:
hostname(config-cmap)# match [not] uri {sip | tel} length gt length


Where length is the number of bytes the URI is greater than. 0 to 65536.
Step 4 Create a SIP inspection policy map, enter the following command:
hostname(config)# policy-map type inspect sip policy_map_name
hostname(config-pmap)#


Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration mode.
Step 5 (Optional) To add a description to the policy map, enter the following command:
hostname(config-pmap)# description string


Step 6 To apply actions to matching traffic, perform the following steps.
a. Specify the traffic on which you want to perform actions using one of the following methods:
&#8226;Specify the SIP class map that you created in Step 3 by entering the following command:
hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)#


&#8226;Specify traffic directly in the policy map using one of the match commands described in Step 3. If you use a match not command, then any traffic that does not match the criterion in the match not command has the action applied.
b. Specify the action you want to perform on the matching traffic by entering the following command:
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 Cisco Security Appliance 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 21-11.
Step 7 To configure parameters that affect the inspection engine, perform the following steps:
a. To enter parameters configuration mode, enter the following command:
hostname(config-pmap)# parameters
hostname(config-pmap-p)#


b. To enable or disable instant messaging, enter the following command:
hostname(config-pmap-p)# im


c. To enable or disable IP address privacy, enter the following command:
hostname(config-pmap-p)# ip-address-privacy


d. To enable check on Max-forwards header field being 0 (which cannot be 0 before reaching the destination), enter the following command:
hostname(config-pmap-p)# max-forwards-validation action {drop | drop-connection | reset | log} [log]


e. To enable check on RTP packets flowing on the pinholes for protocol conformance, enter the following command:
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. To identify the Server and User-Agent header fields, which expose the software version of either a server or an endpoint, enter the following command:
hostname(config-pmap-p)# software-version action {mask | log} [log]


Where the mask keyword masks the software version in the SIP messages.
g. To enable state checking validation, enter the following command:
hostname(config-pmap-p)# state-checking action {drop | drop-connection | reset | log} [log]


h. To enable strict verification of the header fields in the SIP messages according to RFC 3261, enter the following command:
hostname(config-pmap-p)# strict-header-validation action {drop | drop-connection | reset | log} [log]


i. To allow non SIP traffic using the well-known SIP signaling port, enter the following command:
hostname(config-pmap-p)# traffic-non-sip


j. To identify the non-SIP URIs present in the Alert-Info and Call-Info header fields, enter the following command:
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 mymap
hostname(config-pmap)# parameters
hostname(config-pmap-p)# no im


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


hostname(config)# service-policy global_policy global


Configuring SIP Timeout Values The media connections are torn down within two minutes after the connection becomes idle. This is, however, a configurable timeout and can be set for a shorter or longer period of time. To configure the timeout for the SIP control connection, enter the following command:
hostname(config)# timeout sip hh:mm:ss


This command configures the idle timeout after which a SIP control connection is closed.
To configure the timeout for the SIP media connection, enter the following command:
hostname(config)# timeout sip_media hh:mm:ss


This command configures the idle timeout after which a SIP media connection is closed.
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 security appliance. Along with the debug sip and show local-host commands, this command is used for troubleshooting SIP inspection engine issues.

Note We recommend that you configure the pager command before entering the show sip command. If there are a lot of SIP session records and the pager command is not configured, it takes a while for the show sip command output to reach its end.
The following is sample output from the show sip command:
hostname# show sip
Total: 2
call-id c3943000-960ca-2e43-228f@10.130.56.44
    state Call init, idle 0:00:01
call-id c3943000-860ca-7e1f-11f7@10.130.56.45
    state Active, idle 0:00:06


This sample shows two active SIP sessions on the security appliance (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.
Skinny (SCCP) Inspection This section describes SCCP application inspection. This section includes the following topics:
&#8226; SCCP Inspection Overview
&#8226; Supporting Cisco IP Phones
&#8226; Restrictions and Limitations
&#8226; Verifying and Monitoring SCCP Inspection
SCCP Inspection Overview Skinny (SCCP) is a simplified protocol used in VoIP networks. Cisco IP Phones using SCCP can coexist in an H.323 environment. When used with Cisco CallManager, the SCCP client can interoperate with H.323 compliant terminals. Application layer functions in the security appliance recognize SCCP Version 3.3. There are 5 versions of the SCCP protocol: 2.4, 3.0.4, 3.1.1, 3.2, and 3.3.2. The security appliance supports all versions through Version 3.3.2.
The security appliance 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 security appliance.
Normal traffic between Cisco CallManager and Cisco IP Phones uses SCCP and is handled by SCCP inspection without any special configuration. The security appliance 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 10-4.
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 as a Cisco IP Phone requires the Cisco CallManager IP address to be specified explicitly in its configuration. An 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 entry for the TFTP server, this does not have to be an identity static entry. When using NAT, an identity static entry maps to the same IP address. When using 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 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:
&#8226;PAT does not work with configurations containing the alias command.
&#8226;Outside NAT or PAT is not supported.
If the address of an internal Cisco CallManager is configured for NAT or PAT to a different IP address or port, registrations for external Cisco IP Phones fail because the security appliance currently does not support NAT or PAT for the file content transferred over TFTP. Although the security appliance supports NAT of TFTP messages and opens a pinhole for the TFTP file, the security appliance cannot translate the Cisco CallManager IP address and port embedded in the Cisco IP Phone configuration files that are transferred by TFTP during phone registration.

Note The security appliance supports stateful failover of SCCP calls except for calls that are in the middle of call setup.
Verifying and Monitoring SCCP Inspection The show skinny command assists in troubleshooting SCCP (Skinny) inspection engine issues. The following is sample output from the show skinny command under the following conditions. There are two active Skinny sessions set up across the security appliance. The first one is 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 established between another internal Cisco IP Phone at local address 10.0.0.22 and the same Cisco CallManager.
hostname# show skinny
        LOCAL                   FOREIGN                 STATE
---------------------------------------------------------------
1       10.0.0.11/52238         172.18.1.33/2000                1
  MEDIA 10.0.0.11/22948         172.18.1.22/20798
2       10.0.0.22/52232         172.18.1.33/2000                1
  MEDIA 10.0.0.22/20798         172.18.1.11/22948


The output indicates that a call has been established between two internal Cisco IP Phones. The RTP listening ports of the first and second phones are UDP 22948 and 20798 respectively.
The following is sample output from the show xlate debug command for these Skinny connections:
hostname# show xlate debug
2 in use, 2 most used
Flags:  D - DNS, d - dump, I - identity, i - inside, n - no random,
        r - portmap, s - static
NAT from inside:10.0.0.11 to outside:172.18.1.11 flags si idle 0:00:16 timeout 0:05:00
NAT from inside:10.0.0.22 to outside:172.18.1.22 flags si idle 0:00:14 timeout 0:05:00


Configuring a Skinny (SCCP) Inspection Policy Map for Additional Inspection Control To specify actions when a message violates a parameter, create an SCCP inspection policy map. You can then apply the inspection policy map when you enable SCCP inspection according to the "Configuring Application Inspection" section.
To create an SCCP inspection policy map, perform the following steps:
Step 1 (Optional) Add one or more regular expressions for use in traffic matching commands according to the "Creating a Regular Expression" section on page 21-6. See the types of text you can match in the match commands described in Step 3.
Step 2 (Optional) Create one or more regular expression class maps to group regular expressions according to the "Creating a Regular Expression Class Map" section on page 21-9.
Step 3 Create an SCCP inspection policy map, enter the following command:
hostname(config)# policy-map type inspect skinny policy_map_name
hostname(config-pmap)#


Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration mode.
Step 4 (Optional) To add a description to the policy map, enter the following command:
hostname(config-pmap)# description string


Step 5 To apply actions to matching traffic, perform the following steps.
a. Specify the traffic on which you want to perform actions using one of the following methods:
&#8226;Specify the SCCP class map that you created in Step 3 by entering the following command:
hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)#


&#8226;Specify traffic directly in the policy map using one of the match commands described in Step 3. If you use a match not command, then any traffic that does not match the criterion in the match not command has the action applied.
b. Specify the action you want to perform on the matching traffic by entering the following command:
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 Cisco Security Appliance 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.
Step 6 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 21-11.To configure parameters that affect the inspection engine, perform the following steps:
a. To enter parameters configuration mode, enter the following command:
hostname(config-pmap)# parameters
hostname(config-pmap-p)#


b. To enforce registration before calls can be placed, enter the following command:
hostname(config-pmap-p)# enforce-registration


c. To set the maximum SCCP station message ID allowed, enter the following command:
hostname(config-pmap-p)# message-ID max hex_value


Where the hex_value argument is the station message ID in hex.
d. To check RTP packets flowing on the pinholes for protocol conformance, enter the following command:
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.
e. To set the maximum and minimum SCCP prefix length value allowed, enter the following command:
hostname(config-pmap-p)# sccp-prefix-len {max | min} value_length


Where the value_length argument is a maximum or minimum value.
f. To configure the timeout value for signaling and media connections, enter the following command:
hostname(config-pmap-p)# timeout


The following example shows how to define an SCCP inspection policy map.
hostname(config)# policy-map type inspect skinny skinny-map
hostname(config-pmap)# parameters
hostname(config-pmap-p)# enforce-registration
hostname(config-pmap-p)# match message-id range 200 300
hostname(config-pmap-p)# drop log
hostname(config)# class-map inspection_default
hostname(config-cmap)# match default-inspection-traffic
hostname(config)# policy-map global_policy
hostname(config-pmap)# class inspection_default
hostname(config-pmap-c)# inspect skinny skinny-map
hostname(config)# service-policy global_policy global


SMTP and Extended SMTP Inspection ESMTP application inspection provides improved protection against SMTP-based attacks by restricting the types of SMTP commands that can pass through the security appliance and by adding monitoring capabilities.
ESMTP is an enhancement to the SMTP protocol and is similar is most respects to SMTP. For convenience, the term SMTP is used in this document to refer to both SMTP and ESMTP. The application inspection process for extended SMTP is similar to SMTP application inspection and includes support for SMTP sessions. Most commands used in an extended SMTP 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.
Extended SMTP application inspection adds support for eight extended SMTP commands, including AUTH, EHLO, ETRN, HELP, SAML, SEND, SOML and VRFY. Along with the support for seven RFC 821 commands (DATA, HELO, MAIL, NOOP, QUIT, RCPT, RSET), the security appliance supports a total of fifteen SMTP commands.
Other extended SMTP commands, such as ATRN, STARTLS, ONEX, VERB, CHUNKING, and private extensions and are not supported. Unsupported commands are translated into Xs, which are rejected by the internal server. This results in a message such as "500 Command unknown: 'XXX'." Incomplete commands are discarded.
The ESMTP inspection engine 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:
&#8226;Restricts SMTP requests to seven basic SMTP commands and eight extended commands.
&#8226;Monitors the SMTP command-response sequence.
&#8226;Generates an audit trail—Audit record 108002 is generated when invalid character embedded in the mail address is replaced. For more information, see RFC 821.
SMTP inspection monitors the command and response sequence for the following
anomalous signatures:
&#8226;Truncated commands.
&#8226;Incorrect command termination (not terminated with <CR><LR>).
&#8226;The MAIL and RCPT commands specify who are the sender and the receiver of the mail. Mail addresses are scanned for strange characters. The pipeline character (|) is deleted (changed to a blank space) and "<" &#8218;">" are only allowed if they are used to define a mail address (">" must be preceded by "<").
&#8226;Unexpected transition by the SMTP server.
&#8226;For unknown commands, the security appliance changes all the characters in the packet to X. In this case, the server generates an error code to the client. Because of the change in the packed, the TCP checksum has to be recalculated or adjusted.
&#8226;TCP stream editing.
&#8226;Command pipelining.
SNMP Inspection 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 security appliance can deny SNMP versions 1, 2, 2c, or 3. You control the versions permitted by creating an SNMP map. You then apply the SNMP map when you enable SNMP inspection according to the "Configuring Application Inspection" section.
To create an SNMP inspection policy map, perform the following steps:
Step 1 To create an SNMP map, enter the following command:
hostname(config)# snmp-map map_name
hostname(config-snmp-map)#


where map_name is the name of the SNMP map. The CLI enters SNMP map configuration mode.
Step 2 To specify the versions of SNMP to deny, enter the following command for each version:
hostname(config-snmp-map)# deny version version
hostname(config-snmp-map)#


where version is 1, 2, 2c, or 3.
The following example denies SNMP Versions 1 and 2:
hostname(config)# snmp-map sample_map
hostname(config-snmp-map)# deny version 1
hostname(config-snmp-map)# deny version 2


SQL*Net Inspection SQL*Net inspection is enabled by default.
The SQL*Net protocol consists of different packet types that the security appliance handles to make the data stream appear consistent to the Oracle applications on either side of the security appliance.
The default port assignment for SQL*Net is 1521. This is the value used by Oracle for SQL*Net, but this value does not agree with IANA port assignments for Structured Query Language (SQL). Use the class-map command to apply SQL*Net inspection to a range of port numbers.
The security appliance translates all addresses and looks in the packets for all embedded
ports to open for SQL*Net Version 1.
For SQL*Net Version 2, all DATA or REDIRECT packets that immediately follow REDIRECT packets with a zero data length will be fixed up.
The packets that need fix-up contain embedded host/port addresses in the following format:
(ADDRESS=(PROTOCOL=tcp)(DEV=6)(HOST=a.b.c.d)(PORT=a))


SQL*Net Version 2 TNSFrame types (Connect, Accept, Refuse, Resend, and Marker) will not be scanned for addresses to NAT nor will inspection open dynamic
connections for any embedded ports in the packet.
SQL*Net Version 2 TNSFrames, Redirect, and Data packets will be scanned for ports to open and addresses to NAT, if preceded by a REDIRECT TNSFrame type with a
zero data length for the payload. When the Redirect message with data length
zero passes through the security appliance, a flag will be set in the connection data structure to expect the Data or Redirect message that follows to be translated and ports to be dynamically opened. If one of the TNS frames in the preceding paragraph arrive after the Redirect message, the flag will be reset.
The SQL*Net inspection engine will recalculate the checksum, change IP, TCP lengths, and readjust Sequence Numbers and Acknowledgment Numbers using the delta of the length of the new and old message.
SQL*Net Version 1 is assumed for all other cases. TNSFrame types (Connect, Accept, Refuse, Resend, Marker, Redirect, and Data) and all packets
will be scanned for ports and addresses. Addresses will be translated and port connections will be opened.
Sun RPC Inspection This section describes Sun RPC application inspection. This section includes the following topics:
&#8226; Sun RPC Inspection Overview
&#8226; Managing Sun RPC Services
&#8226; Verifying and Monitoring Sun RPC Inspection
Sun RPC Inspection Overview The Sun RPC inspection engine 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 security appliance intercepts this packet and opens both embryonic TCP and UDP connections on that port.

Note NAT or PAT of Sun RPC payload information is not supported.
Managing Sun RPC Services Use the Sun RPC services table to control Sun RPC traffic through the security appliance based on established Sun RPC sessions. To create entries in the Sun RPC services table, use the sunrpc-server command in global configuration mode:
hostname(config)# sunrpc-server interface_name ip_address mask service service_type protocol {tcp | udp} port[-port] timeout hh:mm:ss


You can use this command to specify the timeout after which the pinhole that was opened by Sun RPC application inspection will be closed. For example, to create a timeout of 30 minutes to the Sun RPC server with the IP address 192.168.100.2, enter the following command:
hostname(config)# sunrpc-server inside 192.168.100.2 255.255.255.255 service 100003 protocol tcp 111 timeout 00:30:00


This command specifies that the pinhole that was opened by Sun RPC application inspection will be closed after 30 minutes. In this example, the Sun RPC server is on the inside interface using TCP port 111. You can also specify UDP, a different port number, or a range of ports. To specify a range of ports, separate the starting and ending port numbers in the range with a hyphen (for example, 111-113).
The service type identifies the mapping between a specific service type and the port number used for the service. To determine the service type, which in this example is 100003, use the sunrpcinfo command at the UNIX or Linux command line on the Sun RPC server machine.
To clear the Sun RPC configuration, enter the following command.
hostname(config)# clear configure sunrpc-server


This removes the configuration performed using the sunrpc-server command. The sunrpc-server command allows pinholes to be created with a specified timeout.
To clear the active Sun RPC services, enter the following command:
hostname(config)# clear sunrpc-server active


This clears the pinholes that are opened by Sun RPC application inspection for specific services, such as NFS or NIS.
Verifying and Monitoring Sun RPC Inspection The sample output in this section is for a Sun RPC server with an IP address of 192.168.100.2 on the inside interface and a Sun RPC client with an IP address of 209.168.200.5 on the outside interface.
To view information about the current Sun RPC connections, enter the show conn command. The following is sample output from the show conn command:
hostname# show conn
15 in use, 21 most used
UDP out 209.165.200.5:800 in 192.168.100.2:2049 idle 0:00:04 flags -
UDP out 209.165.200.5:714 in 192.168.100.2:111 idle 0:00:04 flags -
UDP out 209.165.200.5:712 in 192.168.100.2:647 idle 0:00:05 flags -
UDP out 192.168.100.2:0 in 209.165.200.5:714 idle 0:00:05 flags i
hostname(config)#


To display the information about the Sun RPC service table configuration, enter the show running-config sunrpc-server command. The following is sample output from the show running-config sunrpc-server command:
hostname(config)# show running-config sunrpc-server
sunrpc-server inside 192.168.100.2 255.255.255.255 service 100003 protocol UDP port 111 timeout 0:30:00
sunrpc-server inside 192.168.100.2 255.255.255.255 service 100005 protocol UDP port 111 timeout 0:30:00


This output shows that a timeout interval of 30 minutes is configured on UDP port 111 for the Sun RPC server with the IP address 192.168.100.2 on the inside interface.
To display the pinholes open for Sun RPC services, enter the show sunrpc-server active command. The following is sample output from show sunrpc-server active command:
hostname# show sunrpc-server active
LOCAL FOREIGN SERVICE TIMEOUT
-----------------------------------------------
1 209.165.200.5/0 192.168.100.2/2049 100003 0:30:00
2 209.165.200.5/0 192.168.100.2/2049 100003 0:30:00
3 209.165.200.5/0 192.168.100.2/647 100005 0:30:00
4 209.165.200.5/0 192.168.100.2/650 100005 0:30:00


The entry in the LOCAL column shows the IP address of the client or server on the inside interface, while the value in the FOREIGN column shows the IP address of the client or server on the outside interface.
To view information about the Sun RPC services running on a Sun RPC server, enter the rpcinfo -p command from the Linux or UNIX server command line. The following is sample output from the rpcinfo -p command:
sunrpcserver:~ # rpcinfo -p
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 632 status
100024 1 tcp 635 status
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100021 1 udp 32771 nlockmgr
100021 3 udp 32771 nlockmgr
100021 4 udp 32771 nlockmgr
100021 1 tcp 32852 nlockmgr
100021 3 tcp 32852 nlockmgr
100021 4 tcp 32852 nlockmgr
100005 1 udp 647 mountd
100005 1 tcp 650 mountd
100005 2 udp 647 mountd
100005 2 tcp 650 mountd
100005 3 udp 647 mountd
100005 3 tcp 650 mountd


In this output, port 647 corresponds to the mountd daemon running over UDP. The mountd process would more commonly be using port 32780. The mountd process running over TCP uses port 650 in this example.
TFTP Inspection TFTP inspection is enabled by default.
TFTP, described in RFC 1350, is a simple protocol to read and write files between a TFTP server and client.
The security appliance inspects TFTP traffic and dynamically creates connections and translations, if necessary, to permit file transfer between a TFTP client and server. Specifically, the inspection engine inspects TFTP read request (RRQ), write request (WRQ), and error notification (ERROR).
A dynamic secondary channel and a PAT translation, if necessary, are allocated on a reception of a valid read (RRQ) or write (WRQ) request. This secondary channel is subsequently used by TFTP for file transfer or error notification.
Only the TFTP server can initiate traffic over the secondary channel, and at most one incomplete secondary channel can exist between the TFTP client and server. An error notification from the server closes the secondary channel.
TFTP inspection must be enabled if static PAT is used to redirect TFTP traffic.
TLS Proxy for Encrypted Voice Inspection This section describes TLS proxy for encrypted voice inspection. This section includes the following topics:
&#8226; Overview
&#8226; Maximum TLS Proxy Sessions
&#8226; Configuring TLS Proxy
&#8226; Debugging TLS Proxy
&#8226; CTL Client
Overview With encrypted voice inspection, the security appliance decrypts, inspects and modifies (as needed, for example, performing NAT fixup), and re-encrypts voice signaling traffic while all of the existing VoIP inspection functions for Skinny and SIP protocols are preserved. Once voice signaling is decrypted, the plaintext signaling message is passed to the existing inspection engines.
The security appliance acts as a TLS proxy between the Cisco IP Phone and Cisco Unified CallManager. The proxy is transparent for the voice calls between the phone and the Cisco Unified CallManager. Cisco IP Phones download a Certificate Trust List from the Cisco Unified CallManager before registration which contains identities (certificates) of the devices that the phone should trust, such as TFTP servers and Cisco Unified CallManager servers. To support server proxy, the CTL file must contain the certificate that the security appliance creates for the Cisco Unified CallManagers. To proxy calls on behalf of the Cisco IP Phone, the security appliance presents a certificate that the Cisco Unified CallManager can verify, which is a Local Dynamic Certificate for the phone, issued by the certificate authority on the security appliance.
TLS proxy is supported by the Cisco Unified CallManager Release 5.1 and later. You should be familiar with the security features of the Cisco Unified CallManager. For background and detailed description of Cisco Unified CallManager security, see the Cisco Unified CallManager document:
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/5_0/sec_vir/ae/sec504/index.htm
TLS proxy applies to the encryption layer and must be configured with an application layer protocol inspection. You should be familiar with the inspection features on the ASA security appliance, especially Skinny and SIP inspection. For more information on deployment topologies and configuration, refer to the Cisco Security Appliance Command Line Configuration Guide:
http://www.cisco.com/en/US/products/ps6120/products_configuration_guide_chapter09186a008070320a_4container_ccmigration_09186a00807d939a.html#wp1148989
Maximum TLS Proxy Sessions Each TLS proxy session is composed of two SSL connections with mutual authentication. The security appliance supports a pre-set number of TLS proxy sessions by default. The default limit varies by platform. You can increase or decrease the limit by using the tls-proxy maximum-sessions global configuration command.
Table 25-4 lists the default and maximum possible sessions on the security appliance platforms.
.

Table 25-4 Maximum Sessions  
Platform
Default Sessions
Max Possible Sessions
ASA 5505
10
80
ASA 5510
100
200
ASA 5520
300
1200
ASA 5540
1000
4500
ASA 5550
2000
4500

All cryptographic applications, mainly SSL VPN, IPSec VPN, and TLS proxy, share the same crypto memory pool on the security appliance. The memory used by 2.5 SSL VPN connections is equal to one TLS proxy session. The number of possible TLS proxy sessions is reduced if there are active SSL VPN and TLS proxy sessions concurrently. For example, if the security appliance is configured to support up to 100 TLS proxy sessions, and there are 25 active SSL VPN connections, the maximum number of TLS proxy sessions is reduced to 90.

Note You do not need SSL VPN or IPSec VPN licenses to use TLS proxy, though the licenses are needed to support SSL VPN or IPSec VPN.
Configuring TLS Proxy The security appliance in Figure 25-5 serves as a proxy for both client and server, with Cisco IP Phone and Cisco Unified CallManager interaction.
Figure 25-5

TLS Proxy Flow
Before configuring TLS proxy, the following prerequisites are required:
&#8226;You must set clock on the security appliance before configuring TLS proxy. To set the clock manually and display clock, use the clock set and show clock commands. We recommend that the security appliance use the same NTP server as the Cisco Unified CallManager cluster. TLS handshake may fail due to certificate validation failure if clock is out of sync between the security appliance and the Cisco Unified CallManager server.
&#8226;3DES-AES license is needed to interoperate with the Cisco Unified CallManager. AES is the default cipher used by the Cisco Unified CallManager and Cisco IP Phone.
To configure the security appliance for TLS proxy, perform the following steps:
Step 1 (Optional) Set the maximum number of TLS proxy sessions to be supported by the security appliance using the following command, for example:
hostname(config)# tls-proxy maximum-sessions 1200



Note The tls-proxy maximum-sessions command controls the memory size reserved for cryptographic applications such as TLS proxy. Crypto memory is reserved at the time of system boot. You may need to reboot the security appliance for the configuration to take effect if the configured maximum sessions number is greater than the currently reserved.
Step 2 Create necessary RSA key pairs using the following commands, for example:
hostname(config)# crypto key generate rsa label ccm_proxy_key modulus 1024
hostname(config)# crypto key generate rsa label ldc_signer_key modulus 1024
hostname(config)# crypto key generate rsa label phone_common modulus 1024


We recommend to use a different key pair for each role.
Step 3 Create the proxy certificate for the Cisco Unified CallManager cluster using the following commands, for example:
hostname(config)# ! for self-signed CCM proxy certificate
hostname(config)# crypto ca trustpoint ccm_proxy
hostname(config-ca-trustpoint)# enrollment self
hostname(config-ca-trustpoint)# fqdn none
hostname(config-ca-trustpoint)# subject-name cn=EJW-SV-1-Proxy
hostname(config-ca-trustpoint)# keypair ccm_proxy_key
hostname(config)# crypto ca enroll ccm_proxy


The Cisco Unified CallManager proxy certificate could be self-signed or issued by a third-party CA. The certificate is exported to the CTL client.

Note Cisco IP Phones require certain fields from the X.509v3 certificate to be present to validate the certificate via consulting the CTL file. Consequently, the subject-name entry must be configured for a proxy certificate trustpoint. The subject name must be composed of the ordered concatenation of the CN, OU and O fields. The CN field is mandatory; the others are optional.

Each of the concatenated fields (when present) are separated by a semicolon, yielding one of the following forms:

CN=xxx;OU=yyy;O=zzz
CN=xxx;OU=yyy
CN=xxx;O=zzz
CN=xxx
Step 4 Create an internal local CA to sign the LDC for Cisco IP Phones using the following commands, for example:
hostname(config)# ! for the internal local LDC issuer
hostname(config)# crypto ca trustpoint ldc_server
hostname(config-ca-trustpoint)# enrollment self
hostname(config-ca-trustpoint)# proxy-ldc-issuer
hostname(config-ca-trustpoint)# fqdn my_ldc_ca.exmaple.com
hostname(config-ca-trustpoint)# subject-name cn=FW_LDC_SIGNER_172_23_45_200
hostname(config-ca-trustpoint)# keypair ldc_signer_key
hostname(config)# crypto ca enroll ldc_server


This local CA is created as a regular self-signed trustpoint with proxy-ldc-issuer enabled. You may use the embedded local CA LOCAL-CA-SERVER on the security appliance to issue the LDC.
Step 5 Create a CTL Provider instance in preparation for a connection from the CTL Client using the following commands, for example:
hostname(config)# ctl-provider my_ctl
hostname(config-ctl-provider)# client interface inside address 172.23.45.1
hostname(config-ctl-provider)# client username CCMAdministrator password XXXXXX encrypted
hostname(config-ctl-provider)# export certificate ccm_proxy
hostname(config-ctl-provider)# ctl install


The username and password must match the username and password for Cisco Unified CallManager administration. The trustpoint name in the export command is the proxy certificate for the Cisco Unified CallManager server.
The default port number listened by the CTL Provider is TCP 2444, which is the default CTL port on the Cisco Unified CallManager. Use the service port command to change the port number if a different port is used by the Cisco Unified CallManager cluster.
Step 6 Create a TLS proxy instance using the following commands, for example:
hostname(config)# tls-proxy my_proxy
hostname(config-tlsp)# server trust-point ccm_proxy
hostname(config-tlsp)# client ldc issuer ldc_server
hostname(config-tlsp)# client ldc keypair phone_common
hostname(config-tlsp)# client cipher-suite aes128-sha1 aes256-sha1


The server commands configure the proxy parameters for the original TLS server. In other words, the parameters for the security appliance to act as the server during a TLS handshake, or facing the original TLS client. The client commands configure the proxy parameters for the original TLS client. In other words, the parameters for the security appliance to act as the client during a TLS handshake, or facing the original TLS server.
Step 7 Enable TLS proxy for the Cisco IP Phones and Cisco Unified CallManagers in Skinny or SIP inspection using the following commands, for example:
hostname(config)# class-map sec_skinny
hostname(config-cmap)# match port tcp eq 2443


hostname(config)# policy-map type inspect skinny skinny_inspect
hostname(config-pmap)# parameters
hostname(config-pmap-p)# ! Skinny inspection parameters


hostname(config)# policy-map global_policy
hostname(config-pmap)# class inspection_default
hostname(config-pmap-c)# inspect skinny skinny_inspect
hostname(config-pmap)# class sec_skinny
hostname(config-pmap-c)# inspect skinny skinny_inspect tls-proxy my_proxy


hostname(config)# service-policy global_policy global


Step 8 Export the local CA certificate (ldc_server) and install it as a trusted certificate on the Cisco Unified CallManager server.
a. Use the following command to export the certificate if a trust-point with proxy-ldc-issuer is used as the signer of the dynamic certificates, for example:
hostname(config)# crypto ca export ldc_server identity-certificate


b. For the embedded local CA server LOCAL-CA-SERVER, use the following command to export its certificate, for example:
hostname(config)# show crypto ca server certificate


Save the output to a file and import the certificate on the Cisco Unified CallManager. For more information, see the Cisco Unified CallManager document: /en/US/products/sw/voicesw/ps556/products_administration_guide_chapter09186a00806c3e2f.html#wp1040848
After this step, you may use the Display Certificates function on the Cisco Unified CallManager GUI to verify the installed certificate:
/en/US/products/sw/voicesw/ps556/products_administration_guide_chapter09186a00806c3e2f.html#wp1040354
Step 9 Run the CTL Client application to add the server proxy certificate (ccm_proxy) to the CTL file and install the CTL file on the security appliance. See the Cisco Unified CallManager document for information on how to configure and use CTL Client:
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/5_1/nci/p08/secuauth.htm

Note You will need the CTL Client that is released with Cisco Unified CallManager Release 5.1 to interoperate with the security appliance. See the "CTL Client" section for more information regarding TLS proxy support.
Debugging TLS Proxy You may enable TLS proxy debug flags along with SSL syslogs to debug TLS proxy connection problems. For example, using the following commands to enable TLS proxy-related debug and syslog output only:
hostname(config)# debug inspect tls-proxy events
hostname(config)# debug inspect tls-proxy errors
hostname(config)# logging enable
hostname(config)# logging timestamp
hostname(config)# logging list loglist message 711001
hostname(config)# logging list loglist message 725001-725014
hostname(config)# logging list loglist message 717001-717038
hostname(config)# logging buffer-size 1000000
hostname(config)# logging buffered loglist
hostname(config)# logging debug-trace


The following is sample output reflecting a successful TLS proxy session setup for a SIP phone:
hostname(config)# show log


Apr 17 2007 23:13:47: %ASA-6-725001: Starting SSL handshake with client outside:133.9.0.218/49159 for TLSv1 session.
Apr 17 2007 23:13:47: %ASA-7-711001: TLSP cbad5120: Set up proxy for Client outside:133.9.0.218/49159 <-> Server inside:195.168.2.201/5061
Apr 17 2007 23:13:47: %ASA-7-711001: TLSP cbad5120: Using trust point 'local_ccm' with the Client, RT proxy cbae1538
Apr 17 2007 23:13:47: %ASA-7-711001: TLSP cbad5120: Waiting for SSL handshake from Client outside:133.9.0.218/49159.
Apr 17 2007 23:13:47: %ASA-7-725010: Device supports the following 4 cipher(s).
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[1] : RC4-SHA
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[2] : AES128-SHA
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[3] : AES256-SHA
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[4] : DES-CBC3-SHA
Apr 17 2007 23:13:47: %ASA-7-725008: SSL client outside:133.9.0.218/49159 proposes the following 2 cipher(s).
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[1] : AES256-SHA
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[2] : AES128-SHA
Apr 17 2007 23:13:47: %ASA-7-725012: Device chooses cipher : AES128-SHA for the SSL session with client outside:133.9.0.218/49159
Apr 17 2007 23:13:47: %ASA-7-725014: SSL lib error. Function: SSL23_READ Reason: ssl handshake failure
Apr 17 2007 23:13:47: %ASA-7-717025: Validating certificate chain containing 1 certificate(s).
Apr 17 2007 23:13:47: %ASA-7-717029: Identified client certificate within certificate chain. serial number: 01, subject name: cn=SEP0017593F50A8.
Apr 17 2007 23:13:47: %ASA-7-717030: Found a suitable trustpoint _internal_ejw-sv-2_cn=CAPF-08a91c01 to validate certificate.
Apr 17 2007 23:13:47: %ASA-6-717022: Certificate was successfully validated. serial number: 01, subject name:  cn=SEP0017593F50A8.
Apr 17 2007 23:13:47: %ASA-6-717028: Certificate chain was successfully validated with warning, revocation status was not checked.
Apr 17 2007 23:13:47: %ASA-6-725002: Device completed SSL handshake with client outside:133.9.0.218/49159
Apr 17 2007 23:13:47: %ASA-6-725001: Starting SSL handshake with server inside:195.168.2.201/5061 for TLSv1 session.
Apr 17 2007 23:13:47: %ASA-7-725009: Device proposes the following 2 cipher(s) to server inside:195.168.2.201/5061
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[1] : AES128-SHA
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[2] : AES256-SHA
Apr 17 2007 23:13:47: %ASA-7-711001: TLSP cbad5120: Generating LDC for client 'cn=SEP0017593F50A8', key-pair 'phone_common', issuer 'LOCAL-CA-SERVER', RT proxy cbae1538
Apr 17 2007 23:13:47: %ASA-7-711001: TLSP cbad5120: Started SSL handshake with Server
Apr 17 2007 23:13:47: %ASA-7-711001: TLSP cbad5120: Data channel ready for the Client
Apr 17 2007 23:13:47: %ASA-7-725013: SSL Server inside:195.168.2.201/5061 choose cipher : AES128-SHA
Apr 17 2007 23:13:47: %ASA-7-717025: Validating certificate chain containing 1 certificate(s).
Apr 17 2007 23:13:47: %ASA-7-717029: Identified client certificate within certificate chain. serial number: 76022D3D9314743A, subject name: cn=EJW-SV-2.inside.com.
Apr 17 2007 23:13:47: %ASA-6-717022: Certificate was successfully validated. Certificate is resident and trusted, serial number: 76022D3D9314743A, subject name: cn=EJW-SV-2.inside.com.
Apr 17 2007 23:13:47: %ASA-6-717028: Certificate chain was successfully validated with revocation status check.
Apr 17 2007 23:13:47: %ASA-6-725002: Device completed SSL handshake with server inside:195.168.2.201/5061
Apr 17 2007 23:13:47: %ASA-7-711001: TLSP cbad5120: Data channel ready for the Server


Use the show tls-proxy commands with different options to check the active TLS proxy sessions. The following are some sample outputs:
hostname(config-tlsp)# show tls-proxy
Maximum number of sessions: 1200


TLS-Proxy 'sip_proxy': ref_cnt 1, seq# 3
Server proxy:
Trust-point: local_ccm
Client proxy:
Local dynamic certificate issuer: LOCAL-CA-SERVER
Local dynamic certificate key-pair: phone_common
Cipher suite:  aes128-sha1 aes256-sha1
Run-time proxies:
    Proxy 0xcbae1538: Class-map: sip_ssl, Inspect: sip
        Active sess 1, most sess 3, byte 3456043


TLS-Proxy 'proxy': ref_cnt 1, seq# 1
Server proxy:
Trust-point: local_ccm
Client proxy:
Local dynamic certificate issuer: ldc_signer
Local dynamic certificate key-pair: phone_common
Cipher-suite: <unconfigured>
Run-time proxies:
Proxy 0xcbadf720: Class-map: skinny_ssl, Inspect: skinny
        Active sess 1, most sess 1, byte 42916


hostname(config-tlsp)# show tls-proxy session count
2 in use, 4 most used


hostname(config-tlsp)# show tls-proxy session
2 in use, 4 most used
outside 133.9.0.211:50437 inside 195.168.2.200:2443 P:0xcbadf720(proxy) S:0xcbc48a08 byte 42940
outside 133.9.0.218:49159 inside 195.168.2.201:5061 P:0xcbae1538(sip_proxy) S:0xcbad5120 byte 8786


hostname(config-tlsp)# show tls-proxy session detail
2 in use, 4 most used
outside 133.9.0.211:50437 inside 195.168.2.200:2443 P:0xcbadf720(proxy) S:0xcbc48a08 byte 42940
Client: State SSLOK  Cipher AES128-SHA Ch 0xca55e498 TxQSize 0 LastTxLeft 0 Flags 0x1
Server: State SSLOK  Cipher AES128-SHA Ch 0xca55e478 TxQSize 0 LastTxLeft 0 Flags 0x9
Local Dynamic Certificate
Status: Available
Certificate Serial Number: 29
Certificate Usage: General Purpose
Public Key Type: RSA (1024 bits)
Issuer Name:
cn=TLS-Proxy-Signer
Subject Name:
cn=SEP0002B9EB0AAD
o=Cisco Systems Inc
c=US
Validity Date:
start date: 09:25:41 PDT Apr 16 2007
end   date: 09:25:41 PDT Apr 15 2008
Associated Trustpoints:


outside 133.9.0.218:49159 inside 195.168.2.201:5061 P:0xcbae1538(sip_proxy) S:0xcbad5120 byte 8786
Client: State SSLOK  Cipher AES128-SHA Ch 0xca55e398 TxQSize 0 LastTxLeft 0 Flags 0x1
Server: State SSLOK  Cipher AES128-SHA Ch 0xca55e378 TxQSize 0 LastTxLeft 0 Flags 0x9
Local Dynamic Certificate
Status: Available
Certificate Serial Number: 2b
Certificate Usage: General Purpose
Public Key Type: RSA (1024 bits)
Issuer Name:
cn=F1-ASA.default.domain.invalid
Subject Name:
cn=SEP0017593F50A8
Validity Date:
start date: 23:13:47 PDT Apr 16 2007
end   date: 23:13:47 PDT Apr 15 2008
Associated Trustpoints:


CTL Client The CTL Client application supplied by Cisco Unified CallManager Release 5.1 and later supports a TLS proxy server (firewall) in the CTL file. Figure 25-6 through Figure 25-9 illustrate the TLS proxy features supported in the CTL Client.
Figure 25-6 CTL Client TLS Proxy Features — Add Firewall

Figure 25-6 shows support for adding a CTL entry consisting of the security appliance as the TLS proxy.

Figure 25-7 CTL Client TLS Proxy Features — ASA IP Address or Domain Name

Figure 25-7 shows support for entering the security appliance IP address or domain name in the CTL Client.
Figure 25-8 CTL Client TLS Proxy Features — CTL Entry for ASA

Figure 25-8 shows that the CTL entry for the security appliance as the TLS proxy has been added. The CTL entry is added after the CTL Client connects to the CTL Provider service on the security appliance and retrieves the proxy certificate.

Figure 25-9 CTL Client TLS Proxy Features — CTL File Installed on the ASA

The security appliance does not store the raw CTL file in the flash, rather, it parses the CTL file and installs appropriate trustpoints. Figure 25-9 indicates the installation was successful.
XDMCP Inspection XDMCP inspection is enabled by default; however, the XDMCP inspection engine is dependent upon proper configuration of the established command.
XDMCP is a protocol that uses UDP port 177 to negotiate X sessions, which use TCP when established.
For successful negotiation and start of an XWindows session, the security appliance must allow the TCP back connection from the Xhosted computer. To permit the back connection, use the established command on the security appliance. Once XDMCP negotiates the port to send the display, The established command is consulted to verify if this back connection should be permitted.
During the XWindows session, the manager talks to the display Xserver on the well-known port 6000 | n. Each display has a separate connection to the Xserver, as a result of the following terminal setting.
setenv DISPLAY Xserver:n


where n is the display number.
When XDMCP is used, the display is negotiated using IP addresses, which the security appliance can NAT if needed. XDCMP inspection does not support PAT.
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 security appliance, unless the security appliance
configuration specifically allows it.
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 (Optional) Add one or more regular expressions for use in traffic matching commands according to the "Creating a Regular Expression" section on page 21-6. See the types of text you can match in the match commands described in Step 3.
Step 2 (Optional) Create one or more regular expression class maps to group regular expressions according to the "Creating a Regular Expression Class Map" section on page 21-9.s
Step 3 (Optional) Create a SIP inspection class map by performing the following steps.
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-connection, reset, 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. Create the class map by entering the following command:
hostname(config)# class-map type
inspect sip [match-all | match-any]class_map_name
hostname(config-cmap)#


Where the 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. (Optional) To add a description to the class map, enter the following command:
hostname(config-cmap)# description string

network

在很多的site-to-site VPN配置中都会用到Pre-shared Key的配置，但是可能由于种种原因你可能不记得了目前key的配置，而show run的话又不可能看到星号的内容，如果想恢复怎么办呢？

　　最新一期的Cisco Newsletter里面介绍了一种简单的方法来恢复：通过copy running-config tftp命令把当前配置拷贝至TFTP服务器，然后用文本编辑文件对此文件进行编辑就可以看到了。很简单吧。

　　注意，copy running-config tfttp命令适合于PIX v7，对于以前的版本使用write net命令。

network

个人总结的asa/pix 7.x透明模式防火墙的关键知识点


看了前面有人问透明和路由模式的区别，路由模式应该大家比较熟悉了，透明模式是7.0后才支持的，我稍微总结了一下，希望方便大家学习。 如果有不对的地方，大家尽快告诉我，共同进步，呵呵

针对asa和pix的7.x

透明模式只支持两个接口，透明模式也可以用multi-context
注意透明模式没有nat,没有路由

1. 3层流量要明确放行（ospf，eigrp），要想跨防火墙建邻居，两边都要permit
2. 直连的outside和inside网络必须属于相同子网
3. 必须要配置一个网管ip地址,必须~~~
4  网管ip和内外网ip在同一段.
5. 管理ip不能做内网网关
6. 可以配置网关,但是只做网管用，远程访问防火墙用
7. 每个接口必须在不同vlan,（这个是看的资料上写的，暂时不是很理解）
8. 所有流量都可由ip acl和ethernet acl控制是否放行，eth acl只能管二层流量，但是如果deny any了，则 2，3层都不过
9. arp不需要放行就可以过去,除arp外，所有二层流量默认都不通
10. cdp不可以过
透明模式不支持,nat, dynamic routing protocol,ipv6, dhcp relay,qos, multicast, 不能终结vpn

seedhome

不错不错！！好东西顶！

gengyu2008

network管理员， 可否把你的QQ留下 ，  或者你加我的QQ  : 243411103  .   我做的都是华为的