About Firepower Threat Defense Service Policies
You can use Firepower Threat Defense Service Policies to apply services to specific traffic classes. With service policies, you are not limited to applying the same services to all connections that enter the device or a given interface.
A traffic class is a combination of the interface and an extended access control list (ACL). The ACL “allow” rules determine which connections are part of the class. Any “denied” traffic in the ACL simply does not have the service applied to it: these connections are not actually dropped. You can use IP addresses and TCP/UCP ports to identify matching connections as precisely as you require.
There are two types of traffic class:
-
Interface-based rules—If you specify a security zone or interface group in a service policy rule, the rule applies to the ACL “allowed” traffic that goes through any interface that is part of the interface objects.
For a given feature, interface-based rules applied to the ingress interface always take precedence over global rules: if an ingress interface-based rule applies to a connection, any matching global rule is ignored. If no ingress interface or global rule applies, then an interface service rule on the egress interface is applied.
-
Global rules—These rules apply to all interfaces. If an interface-based rule does not apply to a connection, the global rules are checked and applied to any connections that the ACL “allows.” If none apply, then the connections proceed without any services applied.
A given connection can match only one traffic class, either interface-based or global, for a given feature. There should be at most one rule for a given interface object/traffic flow combination.
Service policy rules are applied after access control rules. These services are configured only for connections you are allowing.
How Service Policies Relate to FlexConfig and Other Features
Prior to version 6.3(0), you could configure connection-related service rules using the TCP_Embryonic_Conn_Limit and TCP_Embryonic_Conn_Timeout pre-defined FlexConfig objects. You should remove those objects and redo your rules using the Firepower Threat Defense Service Policy. If you created any custom FlexConfig objects to implement any of these connection-related features (that is, set connection commands), you should also remove those objects and implement the features through the service policy.
Because connection-related service policy features are treated as a separate feature group from other service-rule implemented features, you should not run into problems with overlapping traffic classes. However, please be mindful when configuring the following:
-
QoS Policy rules are implemented using the service policy CLI. These rules are applied before connection-based service policy rules. However, both QoS and connection settings can be applied to the same or overlapping traffic classes.
-
You can use FlexConfig policies to implement customized application inspections and NetFlow. Use the show running-config command to examine the CLI that already configures service rules, including the policy-map , class-map , and service-policy commands. Netflow and application inspection are compatible with QoS and connection settings, but you need to understand the existing configuration before implementing FlexConfig. Connection settings are applied before application inspections and Netflow.
![]() Note |
Traffic classes that are created from the Firepower Threat Defense Service Policy are named class_map_ACLname , where ACLname is the name of the extended ACL object used in the service policy rule. |
What Are Connection Settings?
Connection settings comprise a variety of features related to managing traffic connections, such as a TCP flow through the FTD. Some features are named components that you would configure to supply specific services.
Connection settings include the following:
-
Global timeouts for various protocols—All global timeouts have default values, so you need to change them only if you are experiencing premature connection loss. You configure global timeouts in the Firepower Threat Defense Platform policy. Select .
-
Connection timeouts per traffic class—You can override the global timeouts for specific types of traffic using service policies. All traffic class timeouts have default values, so you do not have to set them.
-
Connection limits and TCP Intercept—By default, there are no limits on how many connections can go through (or to) the FTD. You can set limits on particular traffic classes using service policy rules to protect servers from denial of service (DoS) attacks. Particularly, you can set limits on embryonic connections (those that have not finished the TCP handshake), which protects against SYN flooding attacks. When embryonic limits are exceeded, the TCP Intercept component gets involved to proxy connections and ensure that attacks are throttled.
-
Dead Connection Detection (DCD)—If you have persistent connections that are valid but often idle, so that they get closed because they exceed idle timeout settings, you can enable Dead Connection Detection to identify idle but valid connections and keep them alive (by resetting their idle timers). Whenever idle times are exceeded, DCD probes both sides of the connection to see if both sides agree the connection is valid. The show service-policy command output includes counters to show the amount of activity from DCD.
-
TCP sequence randomization—Each TCP connection has two initial sequence numbers (ISN): one generated by the client and one generated by the server. By default, the FTD randomizes the ISN of the TCP SYN passing in both the inbound and outbound directions. Randomization prevents an attacker from predicting the next ISN for a new connection and potentially hijacking the new session. However, TCP sequence randomization effectively breaks TCP SACK (Selective Acknowledgement), as the sequence numbers the client sees are different from what the server sees. You can disable randomization per traffic class if desired.
-
TCP Normalization—The TCP Normalizer protects against abnormal packets. You can configure how some types of packet abnormalities are handled by traffic class. You can configure TCP Normalization using the FlexConfig policy.
-
TCP State Bypass—You can bypass TCP state checking if you use asymmetrical routing in your network.