About Prefiltering
Prefiltering is the first phase of access control, before the system performs more resource-intensive evaluation. Prefiltering is simple, fast, and early. Prefiltering uses limited outer-header criteria to quickly handle traffic. Compare this to subsequent evaluation, which uses inner headers and has more robust inspection capabilities.
Configure prefiltering to:
-
Improve performance— The sooner you exclude traffic that does not require inspection, the better. You can fastpath or block certain types of plaintext, passthrough tunnels based on their outer encapsulation headers, without inspecting their encapsulated connections. You can also fastpath or block any other connections that benefit from early handling.
-
Tailor deep inspection to encapsulated traffic—You can rezone certain types of tunnels so that you can later handle their encapsulated connections using the same inspection criteria. Rezoning is necessary because after prefiltering, access control uses inner headers.
About Prefilter Policies
Prefiltering is a policy-based feature. To assign it to a device, you assign it to the access control policy that is assigned to the device.
Policy Components: Rules and Default Action
In a prefilter policy, tunnel rules, prefilter rules, and a default action handle network traffic:
-
Tunnel and prefilter rules—First, rules in a prefilter policy handle traffic in the order you specify. Tunnel rules match specific tunnels only and support rezoning. Prefilter rules have a wider range of constraints and do not support rezoning. For more information, see Tunnel vs Prefilter Rules.
-
Default action (tunnels only)—If a tunnel does not match any rules, the default action handles it. The default action can block these tunnels, or continue access control on their individual encapsulated connections. You cannot rezone tunnels with the default action.
There is no default action for nonencapsulated traffic. If a nonencapsulated connection does not match any prefilter rules, the system continues with access control.
Connection Logging
You can log connections fastpathed and blocked by the prefilter policy. See Other Connections You Can Log in the Cisco Secure Firewall Management Center Administration Guide for more information.
Connection events contain information on whether and how logged connections—including entire tunnels—were prefiltered. You can view this information in event views (workflows), dashboards, and reports, and use it as correlation criteria. Keep in mind that because fastpathed and blocked connections are not subject to deep inspection, associated connection events contain limited information.
Default Prefilter Policy
Every access control policy has an associated prefilter policy.
The system uses a default policy if you do not configure custom prefiltering. Initially, this system-provided policy passes all traffic to the next phase of access control. You can change the policy's default action and configure its logging options, but you cannot add rules to it or delete it.
Prefilter Policy Inheritance and Multitenancy
Access control uses a hierarchical implementation that complements multitenancy. Along with other advanced settings, you can lock a prefilter policy association, enforcing that association in all descendant access control policies. For more information, see Access Control Policy Inheritance.
Tunnel vs Prefilter Rules
Whether you configure a tunnel or prefilter rule depends on the specific type of traffic you want to match and the actions or further analysis you want to perform.
Characteristic |
Tunnel Rules |
Prefilter Rules |
---|---|---|
Primary function |
Quickly fastpath, block, or rezone plaintext, passthrough tunnels. |
Quickly fastpath or block any other connection that benefits from early handling. |
Encapsulation and port/protocol criteria |
Encapsulation conditions match only plaintext tunnels over selected protocols, listed in Encapsulation Rule Conditions. |
Port conditions can use a wider range of port and protocol constraints than tunnel rules; see Port, Protocol, and ICMP Code Rule Conditions. |
Network criteria |
Tunnel endpoint conditions constrain the endpoints of the tunnels you want to handle; see Network Rule Conditions. |
Network conditions constrain the source and destination hosts in each connection; see Network Rule Conditions. |
Direction |
Bidirectional or unidirectional (configurable). Tunnel rules are bidirectional by default, so they can handle all traffic between tunnel endpoints. |
Unidirectional only (nonconfigurable). Prefilter rules match source-to-destination traffic only. Return traffic for allowed connections is also permitted. |
Rezone sessions for further analysis |
Supported, using tunnel zones; see Tunnel Zones and Prefiltering. |
Not supported. |
Prefiltering vs Access Control
Prefilter and access control policies both allow you to block and trust traffic, though the prefiltering "trust" functionality is called "fastpathing" because it skips more inspection. The following table explains this and other differences between prefiltering and access control, to help you decide whether to configure custom prefiltering.
If you do not configure custom prefiltering, you can only approximate—not replicate—prefilter functionality with early-placed Block and Trust rules in the access control policy.
Characteristic |
Prefiltering |
Access Control |
For more information, see... |
---|---|---|---|
Primary function |
Quickly fastpath or block certain types of plaintext, passthrough tunnels (see Encapsulation Rule Conditions), or tailor subsequent inspection to their encapsulated traffic. Fastpath or block any other connections that benefit from early handling. |
Inspect and control all network traffic, using simple or complex criteria, including contextual information and deep inspection results. |
|
Implementation |
Prefilter policy. The prefilter policy is invoked by the access control policy. |
Access control policy. The access control policy is a main configuration. In addition to invoking subpolicies, access control policies have their own rules. |
|
Sequence within access control |
First. The system matches traffic to prefilter criteria before all other access control configurations. |
— |
— |
Rule actions |
Fewer. You can stop further inspection (Fastpath and Block) or allow further analysis with the rest of access control (Analyze). |
More. Access control rules have a larger variety of actions, including monitoring, deep inspection, block with reset, and interactive blocking. |
|
Bypass capability |
Fastpath rule action. Fastpathing traffic in the prefilter stage bypasses all further inspection and handling, including:
|
Trust rule action. Traffic trusted by access control rules is only exempt from deep inspection and discovery. |
|
Rule criteria |
Limited. Rules in the prefilter policy use simple network criteria: IP address, VLAN tag, port, and protocol. For tunnels, tunnel endpoint conditions specify the IP address of the routed interfaces of the network devices on either side of the tunnel. |
Robust. Access control rules use network criteria, but also user, application, requested URL, and other contextual information available in packet payloads. Network conditions specify the IP address of source and destination hosts. |
|
IP headers used (tunnel handling) |
Outermost. Using outer headers allows you to handle entire plaintext, passthrough tunnels. For nonencapsulated traffic, prefiltering still uses "outer" headers—which in this case are the only headers. |
Innermost possible. For a nonencrypted tunnel, access control acts on its individual encapsulated connections, not the tunnel as a whole. |
|
Rezone encapsulated connections for further analysis |
Rezones tunneled traffic. Tunnel zones allow you to tailor subsequent inspection to prefiltered, encapsulated traffic. |
Uses tunnel zones. Access control uses the tunnel zones you assign during prefiltering. |
|
Connection logging |
Fastpathed and blocked traffic only. Allowed connections may still be logged by other configurations. |
Any connection. |
Other Connections You Can Log in the Cisco Secure Firewall Management Center Administration Guide |
Supported devices |
Secure Firewall Threat Defense only. |
All. |
— |
Passthrough Tunnels and Access Control
Plaintext (nonencrypted) tunnels can encapsulate multiple connections, often flowing between discontinuous networks. These tunnels are especially useful for routing custom protocols over IP networks, IPv6 traffic over IPv4 networks, and so on.
An outer encapsulation header specifies the source and destination IP addresses of the tunnel endpoints—the routed interfaces of the network devices on either side of the tunnel. Inner payload headers specify the source and destination IP addresses of the encapsulated connections' actual endpoints.
Often, network security devices handle plaintext tunnels as passthrough traffic. That is, the device is not one of the tunnel endpoints. Instead, it is deployed between the tunnel endpoints and monitors the traffic flowing between them.
Some network security devices enforce security policies using outer IP headers. Even for plaintext tunnels, these devices have no control over or insight into individual encapsulated connections and their payloads.
By contrast, the system leverages access control as follows:
-
Outer header evaluation—First, prefiltering uses outer headers to handle traffic. You can block or fastpath entire plaintext, passthrough tunnels at this stage.
-
Inner header evaluation—Next, the rest of access control (and other features such as QoS) use the innermost detectable level of headers to ensure the most granular level of inspection and handling possible.
If a passthrough tunnel is not encrypted, the system acts on its individual encapsulated connections at this stage. You must rezone a tunnel (see Tunnel Zones and Prefiltering) to act on all its encapsulated connections.
Access control has no insight into encrypted passthrough tunnels. For example, access control rules see a passthrough VPN tunnel as one connection. The system handles the entire tunnel using only the information in its outer, encapsulation header.