Prefilter vs Access Control: When to Fast-Path

By Taylor Thomas · 2026-08-30

For traffic governed by an access control policy on a Cisco Secure Firewall, prefiltering is the first phase of access control: a new connection’s first packet meets the prefilter policy before the connection reaches the access control rules. That ordering is the entire point: the prefilter exists to make cheap decisions early, using simple outer-header criteria, so that traffic which does not need deep inspection never consumes the resources of the inspection engine. Its most consequential action, Fastpath, is a deliberate decision to stop looking — which makes it both a genuine performance tool and the easiest way to create a blind spot you will forget you made.

Two Rule Types, Three Actions

The prefilter policy contains two kinds of rules.

Prefilter rules match on early, inexpensive criteria — interface, source and destination network, port, and protocol. They are the ordinary case, and they operate on the outermost header the device sees.

Tunnel rules exist because encapsulated traffic is judged at two different depths. Prefiltering works on the outer headers; when the tunnel is passed on for analysis, the access control policy evaluates the connections carried inside it individually, on their inner addressing. A tunnel rule matches that outer encapsulation explicitly — plaintext tunneling protocols such as GRE or IP-in-IP — which lets you make a decision about the tunnel itself rather than about each conversation within it. A tunnel rule using the Analyze action can also assign a tunnel zone, and this is the more interesting capability: it tags the tunnel so that access control rules can recognize inner connections by the tunnel they arrived through — each inner connection is still evaluated individually, but the rules can now say “for traffic carried by this tunnel, do this.”

Three actions are available. Analyze hands the flow onward to the access control policy — the normal path, and the default when nothing matches. Block drops it immediately, before any deeper processing occurs. Fastpath permits it and bypasses all inspection after the prefilter decision.

What Fastpath Actually Costs

Fastpath is not a lighter inspection. It is the end of inspection: after the prefilter’s own match, no inspection subsystem examines the flow. A fast-pathed flow does not reach the Snort engine, which means no intrusion rules evaluate it, no file or malware inspection occurs, no application identification takes place, and no URL or identity-based conditions are applied. Beyond a connection event — which a prefilter rule can still be configured to log — the flow contributes nothing from the inspection subsystems it bypassed — no findings, no discovery data, no application or URL metadata. On platforms that support flow offload, fast-pathed traffic can additionally be handed off so that subsequent packets are switched without returning to the main path — which is where the throughput benefit becomes substantial.

That trade is defensible in a narrow set of cases. High-volume flows between endpoints you already trust and already control — storage replication, backup windows, cluster interconnects — carry an inspection cost that a documented risk decision may judge not worth paying — trusted does not mean incompromisable, so the call deserves a written justification and compensating telemetry — and moving them out of the inspection path can meaningfully change how much capacity remains for traffic that does need scrutiny. Latency-sensitive internal flows can qualify for the same reason.

The rule that keeps this honest is scope. A fast-path rule written to specific hosts, specific ports, and a specific direction is an engineering decision. A fast-path rule written broadly — a whole subnet, any port — is an inspection bypass that will outlive everyone who remembers why it exists. Document each one with its justification and review them, because the cost of a stale fast-path rule is invisible by construction: it produces no inspection findings, which is exactly what makes it feel harmless.

Choosing Between Prefilter and Access Control

The practical question is which policy should carry a given decision.

Use the prefilter when the criteria are simple, the volume is high, and the intent is to spend as little as possible on the flow — either dropping obviously unwanted traffic at the earliest opportunity, or exempting a well-understood high-throughput flow. Use it also whenever the decision is genuinely about a tunnel rather than about the traffic inside it.

Use the access control policy for everything that depends on richer context: application, user identity, URL category, or any condition that requires the flow to be identified before it can be judged. Trust as an access control action still skips deep inspection, but it does so after the access control policy has evaluated the flow, so it can be conditioned on criteria the prefilter cannot see. Where a decision could reasonably live in either policy, keeping it in access control usually wins on maintainability — one policy to read, one place to audit.

The architectural shift that makes any of this relevant is covered in ASA vs FTD, and the inspection engine that fast-path bypasses is the subject of what is Snort. Policy layering and packet flow through a Secure Firewall are foundational to the SNCF 300-710 exam, and they are far easier to internalize by tracing a real packet than by memorizing a diagram. Start with the first lesson.

Frequently Asked Questions

What is the difference between fast-path in the prefilter and trust in access control?

Both skip deep inspection, but they decide at different points. A Fastpath rule in the prefilter acts on early Layer 3 and Layer 4 criteria before the flow reaches the access control policy and its inspection engine. Trust is an access control action, so the flow has already been evaluated by that policy. Fastpath is the earlier and cheaper exit; trust is the one that can be conditioned on richer criteria.

What do tunnel rules in the prefilter policy do?

They match the outer encapsulation of plaintext tunneling protocols such as GRE or IP-in-IP, which lets you act on a tunnel as a whole rather than on the connections inside it — when the tunnel is analyzed, those are evaluated individually by the access control policy on their inner headers. A tunnel rule can block the encapsulation, fastpath it, or pass it on for analysis, and a rule using the Analyze action can additionally assign a tunnel zone, so access control rules can identify the inner connections — still evaluated individually — by the tunnel that carried them.

Is a prefilter policy required on every device?

An access control policy always has a prefilter policy associated with it, and the default behavior is to analyze traffic rather than bypass it, so a deployment that never touches the prefilter is not missing a step. You add custom rules only when you have a specific reason to block early or to exempt a known flow from inspection.