Cisco ASA 5500 Series Configuration Guide using the CLI, 8.4 and 8.6

Supported Features

Table 30-1 lists the features supported by Modular Policy Framework.

Feature Directionality

Actions are applied to traffic bidirectionally or unidirectionally depending on the feature. For features that are applied bidirectionally, all traffic that enters or exits the interface to which you apply the policy map is affected if the traffic matches the class map for both directions.

Note When you use a global policy, all features are unidirectional; features that are normally bidirectional when applied to a single interface only apply to the ingress of each interface when applied globally. Because the policy is applied to all interfaces, the policy will be applied in both directions so bidirectionality in this case is redundant.

For features that are applied unidirectionally, for example QoS priority queue, only traffic that enters (or exits, depending on the feature) the interface to which you apply the policy map is affected. See Table 30-2 for the directionality of each feature.

Feature Matching Within a Service Policy

See the following information for how a packet matches class maps in a policy map for a given interface:

1. A packet can match only one class map in the policy map for each feature type.

2. When the packet matches a class map for a feature type, the ASA does not attempt to match it to any subsequent class maps for that feature type.

3. If the packet matches a subsequent class map for a different feature type, however, then the ASA also applies the actions for the subsequent class map, if supported. See the “Incompatibility of Certain Feature Actions” section for more information about unsupported combinations.

Note Application inspection includes multiple inspection types, and most are mutually exclusive. For inspections that can be combined, each inspection is considered to be a separate feature.

For example, if a packet matches a class map for connection limits, and also matches a class map for an application inspection, then both actions are applied.

If a packet matches a class map for HTTP inspection, but also matches another class map that includes HTTP inspection, then the second class map actions are not applied.

If a packet matches a class map for HTTP inspection, but also matches another class map that includes FTP inspection, then the second class map actions are not applied because HTTP and FTP inspections cannpt be combined.

If a packet matches a class map for HTTP inspection, but also matches another class map that includes IPv6 inspection, then both actions are applied because the IPv6 inspection can be combined with any other type of inspection.

Order in Which Multiple Feature Actions are Applied

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

Note NetFlow Secure Event Logging filtering and User statistics for Identity Firewall are order-independent.

Actions are performed in the following order:

1. QoS input policing

2. TCP normalization, TCP and UDP connection limits and timeouts, TCP sequence number randomization, and TCP state bypass.

Note When a the ASA performs a proxy service (such as AAA or CSC) or it modifies the TCP payload (such as FTP inspection), the TCP normalizer acts in dual mode, where it is applied before and after the proxy or payload modifying service.

3. ASA CSC

4. Application inspections that can be combined with other inspections:

a. IPv6

b. IP options

c. WAAS

5. Application inspections that cannot be combined with other inspections. The remaining application inspections cannot be combined with other inspections. See the “Incompatibility of Certain Feature Actions” section for more information.

6. ASA IPS

7. ASA CX

8. QoS output policing

9. QoS standard priority queue

10. QoS traffic shaping, hierarchical priority queue

Incompatibility of Certain Feature Actions

Some features are not compatible with each other for the same traffic. The following list may not include all incompatibilities; for information about compatibility of each feature, see the chapter or section for your feature:

• You cannot configure QoS priority queueing and QoS policing for the same set of traffic.
• Most inspections should not be combined with another inspection, so the ASA only applies one inspection if you configure multiple inspections for the same traffic. The only exceptions are listed in the “Order in Which Multiple Feature Actions are Applied” section.
• You cannot configure traffic to be sent to multiple modules, such as the ASA CX and ASA IPS.
• HTTP inspection is not compatible with the ASA CX.

Note The match default-inspection-traffic command, which is used in the default global policy, is a special CLI shortcut to match the default ports for all inspections. When used in a policy map, this class map ensures that the correct inspection is applied to each packet, based on the destination port of the traffic. For example, when UDP traffic for port 69 reaches the ASA, then the ASA applies the TFTP inspection; when TCP traffic for port 21 arrives, then the ASA applies the FTP inspection. So in this case only, you can configure multiple inspections for the same class map. Normally, the ASA does not use the port number to determine which inspection to apply, thus giving you the flexibility to apply inspections to non-standard ports, for example.

An example of a misconfiguration is if you configure multiple inspections in the same policy map and do not use the default-inspection-traffic shortcut. In Example 30-1, traffic destined to port 21 is mistakenly configured for both FTP and HTTP inspection. In Example 30-2, traffic destined to port 80 is mistakenly configured for both FTP and HTTP inspection. In both cases of misconfiguration examples, only the FTP inspection is applied, because FTP comes before HTTP in the order of inspections applied.

Example 30-1 Misconfiguration for FTP packets: HTTP Inspection Also Configured

Example 30-2 Misconfiguration for HTTP packets: FTP Inspection Also Configured

Feature Matching for Multiple Service Policies

For TCP and UDP traffic (and ICMP when you enable stateful ICMP inspection), service policies operate on traffic flows, and not just individual packets. If traffic is part of an existing connection that matches a feature in a policy on one interface, that traffic flow cannot also match the same feature in a policy on another interface; only the first policy is used.

For example, if HTTP traffic matches a policy on the inside interface to inspect HTTP traffic, and you have a separate policy on the outside interface for HTTP inspection, then that traffic is not also inspected on the egress of the outside interface. Similarly, the return traffic for that connection will not be inspected by the ingress policy of the outside interface, nor by the egress policy of the inside interface.

For traffic that is not treated as a flow, for example ICMP when you do not enable stateful ICMP inspection, returning traffic can match a different policy map on the returning interface. For example, if you configure IPS on the inside and outside interfaces, but the inside policy uses virtual sensor 1 while the outside policy uses virtual sensor 2, then a non-stateful Ping will match virtual sensor 1 outbound, but will match virtual sensor 2 inbound.

Default Configuration

By default, the configuration includes a policy that matches all default application inspection traffic and applies certain inspections to the traffic on all interfaces (a global policy). Not all inspections are enabled by default. You can only apply one global policy, so if you want to alter the global policy, you need to either edit the default policy or disable it and apply a new one. (An interface policy overrides the global policy for a particular feature.)

The default policy includes the following application inspections:

• DNS inspection for the maximum message length of 512 bytes
• FTP
• H323 (H225)
• H323 (RAS)
• RSH
• RTSP
• ESMTP
• SQLnet
• Skinny (SCCP)
• SunRPC
• XDMCP
• SIP
• NetBios
• TFTP
• IP Options

The default policy configuration includes the following commands:

Note See the “Incompatibility of Certain Feature Actions” section for more information about the special match default-inspection-traffic command used in the default class map.

Default Class Maps

The configuration includes a default Layer 3/4 class map that the ASA uses in the default global policy called default-inspection-traffic; it matches the default inspection traffic. This class, which is used in the default global policy, is a special shortcut to match the default ports for all inspections. When used in a policy, this class ensures that the correct inspection is applied to each packet, based on the destination port of the traffic. For example, when UDP traffic for port 69 reaches the ASA, then the ASA applies the TFTP inspection; when TCP traffic for port 21 arrives, then the ASA applies the FTP inspection. So in this case only, you can configure multiple inspections for the same class map. Normally, the ASA does not use the port number to determine which inspection to apply, thus giving you the flexibility to apply inspections to non-standard ports, for example.

Another class map that exists in the default configuration is called class-default, and it matches all traffic. This class map appears at the end of all Layer 3/4 policy maps and essentially tells the ASA to not perform any actions on all other traffic. You can use the class-default class if desired, rather than making your own match any class map. In fact, some features are only available for class-default, such as QoS traffic shaping.

Task Flow for Using the Modular Policy Framework

To configure Modular Policy Framework, perform the following steps:

Step 1 Identify the traffic—Identify the traffic on which you want to perform Modular Policy Framework actions by creating Layer 3/4 class maps.

For example, you might want to perform actions on all traffic that passes through the ASA; or you might only want to perform certain actions on traffic from 10.1.1.0/24 to any destination address.

See the “Identifying Traffic (Layer 3/4 Class Maps)” section.

Step 2 Perform additional actions on some inspection traffic—If one of the actions you want to perform is application inspection, and you want to perform additional actions on some inspection traffic, then create an inspection policy map. The inspection policy map identifies the traffic and specifies what to do with it.

For example, you might want to drop all HTTP requests with a body length greater than 1000 bytes.

You can create a self-contained inspection policy map that identifies the traffic directly with match commands, or you can create an inspection class map for reuse or for more complicated matching. See the “Defining Actions in an Inspection Policy Map” section and the “Identifying Traffic in an Inspection Class Map” section.

Step 3 Create a regular expression—If you want to match text with a regular expression within inspected packets, you can create a regular expression or a group of regular expressions (a regular expression class map). Then, when you define the traffic to match for the inspection policy map, you can call on an existing regular expression.

For example, you might want to drop all HTTP requests with a URL including the text “example.com.”

See the “Creating a Regular Expression” section and the “Creating a Regular Expression Class Map” section.

Step 4 Define the actions you want to perform and determine on which interfaces you want to apply the policy map—Define the actions you want to perform on each Layer 3/4 class map by creating a Layer 3/4 policy map. Then, determine on which interfaces you want to apply the policy map using a service policy.

See the “Defining Actions (Layer 3/4 Policy Map)” section and the “Applying Actions to an Interface (Service Policy)” section.

Task Flow for Configuring Hierarchical Policy Maps for QoS Traffic Shaping

If you enable QoS traffic shaping for a class map, then you can optionally enable priority queueing for a subset of shaped traffic. To do so, you need to create a policy map for the priority queueing, and then within the traffic shaping policy map, you can call the priority class map. Only the traffic shaping class map is applied to an interface.

See “Information About QoS,” for more information about this feature.

Hierarchical policy maps are only supported for traffic shaping and priority queueing.

To implement a hierarchical policy map, perform the following steps:

Step 1 Identify the prioritized traffic according to the “Identifying Traffic (Layer 3/4 Class Maps)” section.

You can create multiple class maps to be used in the hierarchical policy map.

Step 2 Create a policy map according to the “Defining Actions (Layer 3/4 Policy Map)” section, and identify the sole action for each class map as priority.

Step 3 Create a separate policy map according to the “Defining Actions (Layer 3/4 Policy Map)” section, and identify the shape action for the class-default class map.

Traffic shaping can only be applied the to class-default class map.

Step 4 For the same class map, identify the priority policy map that you created in Step 2 using the service-policy priority_policy_map command.

Step 5 Apply the shaping policy map to the interface accrding to “Applying Actions to an Interface (Service Policy)” section.

Creating a Layer 3/4 Class Map for Through Traffic

A Layer 3/4 class map matches traffic based on protocols, ports, IP addresses and other Layer 3 or 4 attributes.

Detailed Steps

Examples

The following is an example for the class-map command:

Creating a Layer 3/4 Class Map for Management Traffic

For management traffic to the ASA, you might want to perform actions specific to this kind of traffic. You can specify a management class map that can match an access list or TCP or UDP ports. The types of actions available for a management class map in the policy map are specialized for management traffic. See the “Supported Features” section.

Detailed Steps

Restrictions

The maximum number of policy maps is 64, but you can only apply one policy map per interface.

Detailed Steps

Examples

The following is an example of a policy-map command for connection policy. It limits the number of connections allowed to the web server 10.1.1.1:

The following example shows how multi-match works in a policy map:

The following example shows how traffic matches the first available class map, and will not match any subsequent class maps that specify actions in the same feature domain:

When a Telnet connection is initiated, it matches class telnet_traffic. Similarly, if an FTP connection is initiated, it matches class ftp_traffic. For any TCP connection other than Telnet and FTP, it will match class tcp_traffic. Even though a Telnet or FTP connection can match class tcp_traffic, the ASA does not make this match because they previously matched other classes.

Restrictions

You can only apply one global policy, so if you want to alter the global policy, you need to either edit the default policy or disable it and apply a new one. By default, the configuration includes a global policy that matches all default application inspection traffic and applies inspection to the traffic globally. The default service policy includes the following command:

Detailed Steps

Examples

For example, the following command enables the inbound_policy policy map on the outside interface:

The following commands disable the default global policy, and enables a new one called new_global_policy on all other ASA interfaces:

Applying Inspection and QoS Policing to HTTP Traffic

In this example (see Figure 30-1), any HTTP connection (TCP traffic on port 80) that enters or exits the ASA through the outside interface is classified for HTTP inspection. Any HTTP traffic that exits the outside interface is classified for policing.

Figure 30-1 HTTP Inspection and QoS Policing

See the following commands for this example:

Applying Inspection to HTTP Traffic Globally

In this example (see Figure 30-2), any HTTP connection (TCP traffic on port 80) that enters the ASA through any interface is classified for HTTP inspection. Because the policy is a global policy, inspection occurs only as the traffic enters each interface.

Figure 30-2 Global HTTP Inspection

See the following commands for this example:

Applying Inspection and Connection Limits to HTTP Traffic to Specific Servers

In this example (see Figure 30-3), any HTTP connection destined for Server A (TCP traffic on port 80) that enters the ASA through the outside interface is classified for HTTP inspection and maximum connection limits. Connections initiated from Server A to Host A does not match the access list in the class map, so it is not affected.

Any HTTP connection destined for Server B that enters the ASA through the inside interface is classified for HTTP inspection. Connections initiated from Server B to Host B does not match the access list in the class map, so it is not affected.

Figure 30-3 HTTP Inspection and Connection Limits to Specific Servers

See the following commands for this example:

Applying Inspection to HTTP Traffic with NAT

In this example, the Host on the inside network has two addresses: one is the real IP address 192.168.1.1, and the other is a mapped IP address used on the outside network, 209.165.200.225. Because the policy is applied to the inside interface, where the real address is used, then you must use the real IP address in the access list in the class map. If you applied it to the outside interface, you would use the mapped address.

Figure 30-4 HTTP Inspection with NAT

See the following commands for this example: