About Service Policies
The following topics describe how service policies work.
The Components of a Service Policy
The point of service policies is to apply advanced services to the traffic you are allowing. Any traffic permitted by access rules can have service policies applied, and thus receive special processing, such as being redirected to a service module or having application inspection applied.
You can have these types of service policy:
-
One global policy that gets applied to all interfaces.
-
One service policy applied per interface. The policy can be a mix of classes for traffic going through the device and management traffic directed at the ASA interface rather than going through it,
Each service policy is composed of the following elements:
-
Service policy map, which is the ordered set of rules, and is named on the service-policy command. In ASDM, the policy map is represented as a folder on the Service Policy Rules page.
-
Rules, each rule being a class command within the service policy map and the commands associated with the class command. In ASDM, each rule is shown on a separate row, and the name of the rule is the class name.
The class command defines the traffic matching criteria for the rule.
The commands associated with class, such as inspect, set connection timeout, and so forth, define the services and constraints to apply to matching traffic. Note that inspect commands can point to inspection policy maps, which define actions to apply to inspected traffic. Keep in mind that inspection policy maps are not the same as service policy maps.
The following example compares how service policies appear in the CLI with how they appear in ASDM. Note that there is not a one-to-one mapping between the figure call-outs and lines in the CLI.
The following CLI is generated by the rules shown in the figure above.
: Access lists used in class maps.
: In ASDM, these map to call-out 3, from the Match to the Time fields.
access-list inside_mpc line 1 extended permit tcp 10.100.10.0 255.255.255.0 any eq sip
access-list inside_mpc_1 line 1 extended deny udp host 10.1.1.15 any eq snmp
access-list inside_mpc_1 line 2 extended permit udp 10.1.1.0 255.255.255.0 any eq snmp
access-list inside_mpc_2 line 1 extended permit icmp any any
: SNMP map for SNMP inspection. Denies all but v3.
: In ASDM, this maps to call-out 4, rule actions, for the class-inside policy.
snmp-map snmp-v3only
deny version 1
deny version 2
deny version 2c
: Inspection policy map to define SIP behavior.
: The sip-high inspection policy map must be referred to by an inspect sip command
: in the service policy map.
: In ASDM, this maps to call-out 4, rule actions, for the sip-class-inside policy.
policy-map type inspect sip sip-high
parameters
rtp-conformance enforce-payloadtype
no traffic-non-sip
software-version action mask log
uri-non-sip action mask log
state-checking action drop-connection log
max-forwards-validation action drop log
strict-header-validation action drop log
: Class map to define traffic matching for the inside-class rule.
: In ASDM, this maps to call-out 3, from the Match to the Time fields.
class-map inside-class
match access-list inside_mpc_1
: Class map to define traffic matching for the sip-class-inside rule.
: In ASDM, this maps to call-out 3, from the Match to the Time fields.
class-map sip-class-inside
match access-list inside_mpc
: Class map to define traffic matching for the inside-class1 rule.
: In ASDM, this maps to call-out 3, from the Match to the Time fields.
class-map inside-class1
match access-list inside_mpc_2
: Policy map that actually defines the service policy rule set named test-inside-policy.
: In ASDM, this corresponds to the folder at call-out 1.
policy-map test-inside-policy
: First rule in test-inside-policy, named sip-class-inside. Inspects SIP traffic.
: The sip-class-inside rule applies the sip-high inspection policy map to SIP inspection.
: In ASDM, each rule corresponds to call-out 2.
class sip-class-inside
inspect sip sip-high
: Second rule, inside-class. Applies SNMP inspection using an SNMP map.
class inside-class
inspect snmp snmp-v3only
: Third rule, inside-class1. Applies ICMP inspection.
class inside-class1
inspect icmp
: Fourth rule, class-default. Applies connection settings and enables user statistics.
class class-default
set connection timeout embryonic 0:00:30 half-closed 0:10:00 idle 1:00:00
reset dcd 0:15:00 5
user-statistics accounting
: The service-policy command applies the policy map rule set to the inside interface.
: This command activates the policies.
service-policy test-inside-policy interface inside
Features Configured with Service Policies
The following table lists the features you configure using service policies.
Feature |
For Through Traffic? |
For Management Traffic? |
See: |
---|---|---|---|
Application inspection (multiple types) |
All except RADIUS accounting |
RADIUS accounting only |
|
NetFlow Secure Event Logging filtering |
Yes |
Yes |
See the NetFlow implementation guide. |
QoS input and output policing |
Yes |
No |
|
QoS standard priority queue |
Yes |
No |
|
TCP and UDP connection limits and timeouts, and TCP sequence number randomization |
Yes |
Yes |
|
TCP normalization |
Yes |
No |
|
TCP state bypass |
Yes |
No |
|
User statistics for Identity Firewall |
Yes |
Yes |
See the user-statistics command in the command reference. |
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 the following table for the directionality of each feature.
Feature |
Single Interface Direction |
Global Direction |
---|---|---|
Application inspection (multiple types) |
Bidirectional |
Ingress |
NetFlow Secure Event Logging filtering |
N/A |
Ingress |
QoS input policing |
Ingress |
Ingress |
QoS output policing |
Egress |
Egress |
QoS standard priority queue |
Egress |
Egress |
TCP and UDP connection limits and timeouts, and TCP sequence number randomization |
Bidirectional |
Ingress |
TCP normalization |
Bidirectional |
Ingress |
TCP state bypass |
Bidirectional |
Ingress |
User statistics for Identity Firewall |
Bidirectional |
Ingress |
Feature Matching Within a Service Policy
A packet matches class maps in a policy map for a given interface according to the following rules:
-
A packet can match only one class map in the policy map for each feature type.
-
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.
-
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 Incompatibility of Certain Feature Actions 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.
Examples of Packet Matching
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 cannot 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.
Actions are performed in the following order:
-
QoS input policing
-
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 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.
-
Application inspections that can be combined with other inspections:
-
IPv6
-
IP options
-
WAAS
-
-
Application inspections that cannot be combined with other inspections. See Incompatibility of Certain Feature Actions for more information.
-
QoS output policing
-
QoS standard priority queue
Note |
NetFlow Secure Event Logging filtering and User statistics for Identity Firewall are order-independent. |
Incompatibility of Certain Feature Actions
Some features are not compatible with each other for the same traffic. The following list might not include all incompatibilities; for information about compatibility of each feature, see the chapter or section for the feature:
-
You cannot configure QoS priority queuing 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. Exceptions are listed in Order in Which Multiple Feature Actions are Applied.
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 the first example, traffic destined to port 21 is mistakenly configured for both FTP and HTTP inspection. In the second example, 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 1: Misconfiguration for FTP packets: HTTP Inspection Also Configured
class-map ftp
match port tcp eq 21
class-map http
match port tcp eq 21 [it should be 80]
policy-map test
class ftp
inspect ftp
class http
inspect http
Example 2: Misconfiguration for HTTP packets: FTP Inspection Also Configured
class-map ftp
match port tcp eq 80 [it should be 21]
class-map http
match port tcp eq 80
policy-map test
class ftp
inspect ftp
class http
inspect http
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.