Information About Service Policies
This section describes how service policies work and includes the following topics:
Supported Features
Table 1-1
lists the features supported by service policy rules.
Table 1-1 Service Policy Rule Features
|
|
|
|
Application inspection (multiple types)
|
All
except RADIUS accounting
|
RADIUS accounting
only
|
|
ASA CSC
|
Yes
|
No
|
Chapter32, “Configuring the ASA CSC Module”
|
ASA IPS
|
Yes
|
No
|
Chapter31, “Configuring the ASA IPS Module”
|
ASA CX
|
Yes
|
No
|
Chapter30, “Configuring the ASA CX Module”
|
NetFlow Secure Event Logging filtering
|
Yes
|
Yes
|
“Configuring NetFlow Secure Event Logging (NSEL),” in the general operations configuration guide.
|
QoS input and output policing
|
Yes
|
No
|
Chapter23, “Configuring QoS”
|
QoS standard priority queue
|
Yes
|
No
|
Chapter23, “Configuring QoS”
|
QoS traffic shaping, hierarchical priority queue
|
Yes
|
Yes
|
Chapter23, “Configuring QoS”
|
TCP and UDP connection limits and timeouts, and TCP sequence number randomization
|
Yes
|
Yes
|
Chapter22, “Configuring Connection Settings”
|
TCP normalization
|
Yes
|
No
|
Chapter22, “Configuring Connection Settings”
|
TCP state bypass
|
Yes
|
No
|
Chapter22, “Configuring Connection Settings”
|
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
Table 1-2
for the directionality of each feature.
Table 1-2 Feature Directionality
|
Single Interface Direction
|
|
Application inspection (multiple types)
|
Bidirectional
|
Ingress
|
ASA CSC
|
Bidirectional
|
Ingress
|
ASA CX
|
Bidirectional
|
Ingress
|
ASA CX authentication proxy
|
Ingress
|
Ingress
|
ASA IPS
|
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
|
QoS traffic shaping, hierarchical 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
See the following information for how a packet matches rules in a policy for a given interface:
1. A packet can match only one rule for an interface for each feature type.
2. When the packet matches a rule for a feature type, the ASA does not attempt to match it to any subsequent rules for that feature type.
3. If the packet matches a subsequent rule for a different feature type, however, then the ASA also applies the actions for the subsequent rule, 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 rule for connection limits, and also matches a rule for an application inspection, then both actions are applied.
If a packet matches a rulefor HTTP inspection, but also matches another rule that includes HTTP inspection, then the second rule actions are not applied.
If a packet matches a rulefor HTTP inspection, but also matches another rule that includes FTP inspection, then the second rule actions are not applied because HTTP and FTP inspections cannpt be combined.
If a packet matches a rule for HTTP inspection, but also matches another rule 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 service policy are performed is independent of the order in which the actions appear in the table.
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. 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. HTTP inspection can be combined with the Cloud Web Security inspection. Other 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.
-
The ASA CX is not compatible with Cloud Web Security.
Note The Default Inspection Traffic traffic class, 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.
This traffic class does not include the default ports for Cloud Web Security inspection (80 and 443).
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.
Adding a Service Policy Rule for Through Traffic
See the “Supported Features” section for more information. To add a service policy rule for through traffic, perform the following steps:
Step 1 Choose
Configuration
>
Firewall
>
Service Policy Rules
pane, and click
Add
.
The Add Service Policy Rule Wizard - Service Policy dialog box appears.
Note When you click the Add button, and not the small arrow on the right of the Add button, you add a through traffic rule by default. If you click the arrow on the Add button, you can choose between a through traffic rule and a management traffic rule.
Step 2 In the Create a Service Policy and Apply To area, click one of the following options:
-
Interface
. This option applies the service policy to a single interface. Interface service policies take precedence over the global service policy for a given feature. For example, if you have a global policy with FTP inspection, and an interface policy with TCP connection limits, then both FTP inspection and TCP connection limits are applied to the interface. However, if you have a global policy with FTP inspection, and an interface policy with FTP inspection, then only the interface policy FTP inspection is applied to that interface.
a. Choose an interface from the drop-down list.
If you choose an interface that already has a policy, then the wizard lets you add a new service policy rule to the interface.
b. If it is a new service policy, enter a name in the Policy Name field.
c. (Optional) Enter a description in the Description field.
d. (Optional) Check the
Drop and log unsupported IPv6 to IPv6 traffic
check box to generate a syslog (767001) for IPv6 traffic that is dropped by application inspections that do not support IPv6 traffic. By default, syslogs are not generated. For a list of inspections that support IPv6, see the “IPv6 Guidelines” section.
-
Global - applies to all interfaces
. This option applies the service policy globally to all interfaces. By default, a global policy exists that includes a service policy rule for default application inspection. See the “Default Settings” section for more information. You can add a rule to the global policy using the wizard.
a. If it is a new service policy, enter a name in the Policy Name field.
b. (Optional) Enter a description in the Description field.
c. (Optional) Check the
Drop and log unsupported IPv6 to IPv6 traffic
check box to generate a syslog (767001) for IPv6 traffic that is dropped by application inspections that do not support IPv6 traffic. By default, syslogs are not generated. For a list of inspections that support IPv6, see the “IPv6 Guidelines” section.
Step 3 Click
Next
.
The Add Service Policy Rule Wizard - Traffic Classification Criteria dialog box appears.
Step 4 Click one of the following options to specify the traffic to which to apply the policy actions:
-
Create a new traffic class
. Enter a traffic class name in the Create a new traffic class field, and enter an optional description.
Identify the traffic using one of several criteria:
–
Default Inspection Traffic
—The class matches the default TCP and UDP ports used by all applications that the ASA can inspect.
This option, which is used in the default global policy, is a special shortcut that when used in a rule, 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 rule (See the “Incompatibility of Certain Feature Actions” section for more information about combining actions). Normally, the ASA does not use the port number to determine the inspection applied, thus giving you the flexibility to apply inspections to non-standard ports, for example.
See the “Default Settings and NAT Limitations” section for a list of default ports. The ASA includes a default global policy that matches the default inspection traffic, and applies common inspections to the traffic on all interfaces. Not all applications whose ports are included in the Default Inspection Traffic class are enabled by default in the policy map.
You can specify a Source and Destination IP Address (uses ACL) class along with the Default Inspection Traffic class to narrow the matched traffic. Because the Default Inspection Traffic class specifies the ports and protocols to match, any ports and protocols in the ACL are ignored.
–
Source and Destination IP Address (uses ACL)
—The class matches traffic specified by an extended ACL. If the ASA is operating in transparent firewall mode, you can use an EtherType ACL.
Note When you create a new traffic class of this type, you can only specify one access control entry (ACE) initially. After you finish adding the rule, you can add additional ACEs by adding a new rule to the same interface or global policy, and then specifying Add rule to existing traffic class on the Traffic Classification dialog box (see below).
–
Tunnel Group
—The class matches traffic for a tunnel group to which you want to apply QoS. You can also specify one other traffic match option to refine the traffic match, excluding Any Traffic, Source and Destination IP Address (uses ACL), or Default Inspection Traffic.
–
TCP or UDP Destination Port
—The class matches a single port or a contiguous range of ports.
Tip For applications that use multiple, non-contiguous ports, use the Source and Destination IP Address (uses ACL) to match each port.
–
RTP Range
—The class map matches RTP traffic.
–
IP DiffServ CodePoints (DSCP)
—The class matches up to eight DSCP values in the IP header.
–
IP Precedence
—The class map matches up to four precedence values, represented by the TOS byte in the IP header.
–
Any Traffic
—Matches all traffic.
-
Add rule to existing traffic class
. If you already have a service policy rule on the same interface, or you are adding to the global service policy, this option lets you add an ACE to an existing ACL. You can add an ACE to any ACL that you previously created when you chose the Source and Destination IP Address (uses ACL) option for a service policy rule on this interface. For this traffic class, you can have only one set of rule actions even if you add multiple ACEs. You can add multiple ACEs to the same traffic class by repeating this entire procedure. See the “Managing the Order of Service Policy Rules” section for information about changing the order of ACEs.
-
Use an existing traffic class.
If you created a traffic class used by a rule on a different interface, you can reuse the traffic class definition for this rule. Note that if you alter the traffic class for one rule, the change is inherited by all rules that use that traffic class. If your configuration includes any
class-map
commands that you entered at the CLI, those traffic class names are also available (although to view the definition of the traffic class, you need to create the rule).
-
Use class default as the traffic class
. This option uses the class-default class, which matches all traffic. The class-default class is created automatically by the ASA and placed at the end of the policy. If you do not apply any actions to it, it is still created by the ASA, but for internal purposes only. You can apply actions to this class, if desired, which might be more convenient than creating a new traffic class that matches all traffic. You can only create one rule for this service policy using the class-default class, because each traffic class can only be associated with a single rule per service policy.
Step 5 Click
Next
.
Step 6 The next dialog box depends on the traffic match criteria you chose.
Note The Any Traffic option does not have a special dialog box for additional configuration.
-
Default Inspections—This dialog box is informational only, and shows the applications and the ports that are included in the traffic class.
-
Source and Destination Address—This dialog box lets you set the source and destination addresses:
a. Click
Match
or
Do Not Match
.
The Match option creates a rule where traffic matching the addresses have actions applied. The Do Not Match option exempts the traffic from having the specified actions applied. For example, you want to match all traffic in 10.1.1.0/24 and apply connection limits to it, except for 10.1.1.25. In this case, create two rules, one for 10.1.1.0/24 using the Match option and one for 10.1.1.25 using the Do Not Match option. Be sure to arrange the rules so that the Do Not Match rule is above the Match rule, or else 10.1.1.25 will match the Match rule first.
b. In the Source field, enter the source IP address, or click the
...
button to choose an IP address that you already defined in ASDM.
Specify the address and subnet mask using prefix/length notation, such as 10.1.1.0/24. If you enter an IP address without a mask, it is considered to be a host address, even if it ends with a 0.
Enter
any
to specify any source address.
Separate multiple addresses by a comma.
c. In the Destination field, enter the destination IP address, or click the
...
button to choose an IP address that you already defined in ASDM.
Specify the address and subnet mask using prefix/length notation, such as 10.1.1.0/24. If you enter an IP address without a mask, it is considered to be a host address, even if it ends with a 0.
Enter
any
to specify any destination address.
Separate multiple addresses by a comma.
d. In the Service field, enter an IP service name or number for the destination service, or click the
...
button to choose a service.
If you want to specify a TCP or UDP port number, or an ICMP service number, enter
protocol
/
port
. For example, enter TCP/8080.
By default, the service is IP.
Separate multiple services by a comma.
e. (Optional) Enter a description in the Description field.
f. (Optional) To specify a source service for TCP or UDP, click the
More Options
area open, and enter a TCP or UDP service in the Source Service field.
The destination service and source service must be the same. Copy and paste the destination Service field to the Source Service field.
g. (Optional) To make the rule inactive, click the
More Options
area open, and uncheck
Enable Rule
.
This setting might be useful if you do not want to remove the rule, but want to turn it off.
h. (Optional) To set a time range for the rule, click the
More Options
area open, and from the Time Range drop-down list, choose a time range.
To add a new time range, click the
...
button. See the “Configuring Time Ranges” section in the general operations configuration guide for more information.
This setting might be useful if you only want the rule to be active at predefined times.
To police each flow, check
Match flow destination IP address
. All traffic going to a unique IP destination address is considered a flow.
-
Destination Port—Click
TCP
or
UDP
.
In the Service field, enter a port number or name, or click
...
to choose one already defined in ASDM.
-
RTP Range—Enter an RTP port range, between 2000 and 65534. The maximum number of port sin the range is 16383.
-
IP DiffServ CodePoints (DSCP)—In the DSCP Value to Add area, choose a value from the
Select Named DSCP Values
or enter a value in the
Enter DSCP Value (0-63) field
, and click
Add
.
Add additional values as desired, or remove them using the
Remove
button.
-
IP Precedence—From the Available IP Precedence area, choose a value and click
Add
.
Add additional values as desired, or remove them using the
Remove
button.
Step 7 Click
Next
.
The Add Service Policy Rule - Rule Actions dialog box appears.
Step 8 Configure one or more rule actions. See the “Supported Features” section for a list of features.
Step 9 Click
Finish
.
Adding a Service Policy Rule for Management Traffic
You can create a service policy for traffic directed to the ASA for management purposes. See the “Supported Features” section for more information. This section includes the following topics:
Configuring a Service Policy Rule for Management Traffic
To add a service policy rule for management traffic, perform the following steps:
Step 1 From the Configuration > Firewall > Service Policy Rules pane, click the down arrow next to Add.
Step 2 Choose
Add Management Service Policy Rule
.
The Add Management Service Policy Rule Wizard - Service Policy dialog box appears.
Step 3 In the Create a Service Policy and Apply To area, click one of the following options:
-
Interface
. This option applies the service policy to a single interface. Interface service policies take precedence over the global service policy for a given feature. For example, if you have a global policy with RADIUS accounting inspection, and an interface policy with connection limits, then both RADIUS accounting and connection limits are applied to the interface. However, if you have a global policy with RADIUS accounting, and an interface policy with RADIUS accounting, then only the interface policy RADIUS accounting is applied to that interface.
a. Choose an interface from the drop-down list.
If you choose an interface that already has a policy, then the wizard lets you add a new service policy rule to the interface.
b. If it is a new service policy, enter a name in the Policy Name field.
c. (Optional) Enter a description in the Description field.
-
Global - applies to all interfaces
. This option applies the service policy globally to all interfaces. By default, a global policy exists that includes a service policy rule for default application inspection. See the “Default Settings” section for more information. You can add a rule to the global policy using the wizard.
Step 4 Click
Next
.
The Add Management Service Policy Rule Wizard - Traffic Classification Criteria dialog box appears.
Step 5 Click one of the following options to specify the traffic to which to apply the policy actions:
-
Create a new traffic class
. Enter a traffic class name in the Create a new traffic class field, and enter an optional description.
Identify the traffic using one of several criteria:
–
Source and Destination IP Address (uses ACL)
—The class matches traffic specified by an extended ACL. If the ASA is operating in transparent firewall mode, you can use an EtherType ACL.
Note When you create a new traffic class of this type, you can only specify one access control entry (ACE) initially. After you finish adding the rule, you can add additional ACEs by adding a new rule to the same interface or global policy, and then specifying Add rule to existing traffic class on the Traffic Classification dialog box (see below).
–
TCP or UDP Destination Port
—The class matches a single port or a contiguous range of ports.
Tip For applications that use multiple, non-contiguous ports, use the Source and Destination IP Address (uses ACL) to match each port.
-
Add rule to existing traffic class
. If you already have a service policy rule on the same interface, or you are adding to the global service policy, this option lets you add an ACE to an existing ACL. You can add an ACE to any ACL that you previously created when you chose the Source and Destination IP Address (uses ACL) option for a service policy rule on this interface. For this traffic class, you can have only one set of rule actions even if you add multiple ACEs. You can add multiple ACEs to the same traffic class by repeating this entire procedure. See the “Managing the Order of Service Policy Rules” section for information about changing the order of ACEs.
-
Use an existing traffic class.
If you created a traffic class used by a rule on a different interface, you can reuse the traffic class definition for this rule. Note that if you alter the traffic class for one rule, the change is inherited by all rules that use that traffic class. If your configuration includes any
class-map
commands that you entered at the CLI, those traffic class names are also available (although to view the definition of the traffic class, you need to create the rule).
Step 6 Click
Next
.
Step 7 The next dialog box depends on the traffic match criteria you chose.
-
Source and Destination Address—This dialog box lets you set the source and destination addresses:
a. Click
Match
or
Do Not Match
.
The Match option creates a rule where traffic matching the addresses have actions applied. The Do Not Match option exempts the traffic from having the specified actions applied. For example, you want to match all traffic in 10.1.1.0/24 and apply connection limits to it, except for 10.1.1.25. In this case, create two rules, one for 10.1.1.0/24 using the Match option and one for 10.1.1.25 using the Do Not Match option. Be sure to arrange the rules so that the Do Not Match rule is above the Match rule, or else 10.1.1.25 will match the Match rule first.
b. In the Source field, enter the source IP address, or click the
...
button to choose an IP address that you already defined in ASDM.
Specify the address and subnet mask using prefix/length notation, such as 10.1.1.0/24. If you enter an IP address without a mask, it is considered to be a host address, even if it ends with a 0.
Enter
any
to specify any source address.
Separate multiple addresses by a comma.
c. In the Destination field, enter the destination IP address, or click the
...
button to choose an IP address that you already defined in ASDM.
Specify the address and subnet mask using prefix/length notation, such as 10.1.1.0/24. If you enter an IP address without a mask, it is considered to be a host address, even if it ends with a 0.
Enter
any
to specify any destination address.
Separate multiple addresses by a comma.
d. In the Service field, enter an IP service name or number for the destination service, or click the
...
button to choose a service.
If you want to specify a TCP or UDP port number, or an ICMP service number, enter
protocol
/
port
. For example, enter TCP/8080.
By default, the service is IP.
Separate multiple services by a comma.
e. (Optional) Enter a description in the Description field.
f. (Optional) To specify a source service for TCP or UDP, click the
More Options
area open, and enter a TCP or UDP service in the Source Service field.
The destination service and source service must be the same. Copy and paste the destination Service field to the Source Service field.
g. (Optional) To make the rule inactive, click the
More Options
area open, and uncheck
Enable Rule
.
This setting might be useful if you do not want to remove the rule, but want to turn it off.
h. (Optional) To set a time range for the rule, click the
More Options
area open, and from the Time Range drop-down list, choose a time range.
To add a new time range, click the
...
button. See the “Configuring Time Ranges” section in the general operations configuration guide for more information.
This setting might be useful if you only want the rule to be active at predefined times.
-
Destination Port—Click
TCP
or
UDP
.
In the Service field, enter a port number or name, or click
...
to choose one already defined in ASDM.
Step 8 Click
Next
.
The Add Management Service Policy Rule - Rule Actions dialog box appears.
Step 9 To configure RADIUS accounting inspection, choose an inspect map from the RADIUS Accounting Map drop-down list, or click
Configure
to add a map.
See the “Supported Features” section for more information.
Step 10 To configure connection settings, see the “Configuring Connection Settings” section.
Step 11 Click
Finish
.