Introduction to Prefiltering
Prefiltering is the first phase of access control, before the system performs more resource-intensive evaluation. Prefilter policies deployed to managed devices use limited outer-header criteria to quickly handle traffic.
Contrasted with the rest of access control, which uses inner headers and has more robust inspection capabilities, prefiltering is simple, fast, and early.
Configure prefiltering if you want 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.
For details, see Prefiltering vs Access Control.
Prefiltering Model Restrictions
In the Firepower System. prefiltering is supported on Firepower Threat Defense devices only.
Prefilter policies deployed to Classic devices (7000 and 8000 Series, NGIPSv, ASA FirePOWER) have no effect. Instead, use early-placed Trust and Block access control rules to approximate prefilter functionality, keeping in mind the differences between the two features.
8000 Series devices—Device-specific fastpath rules can bypass access control (but cannot block traffic); see Configuring Fastpath Rules (8000 Series).
Classic devices—All Classic devices can match entire GRE-encapsulated tunnels using access control rules, with some limitations; see Port and ICMP Code Conditions.