Prefiltering is the first phase of access control in Cisco Secure Firewall, providing a high-performance mechanism to streamline traffic processing. By implementing a prefilter policy, administrators can exclude specific traffic types from deep inspection or even allow them to fastpath through the device. This optimization is especially valuable for tunneled or trusted traffic, helping to reduce load on the inspection engine.

 

What Is a Prefilter Policy?

Prefilter policies were introduced in Cisco Secure Firewall version 6.1 and are exclusive to the Secure Firewall platform (not available on the previous ASA with Firepower Services platform). These policies serve three primary purposes:

  • Match traffic on both inner and outer headers, especially useful for tunnel-based traffic.
  • Provide early access control, allowing trusted flows to bypass the Snort inspection engine entirely.
  • Act as placeholders for ACEs (Access Control Entries) during ASA-to-Secure Firewall migration via Cisco’s migration tools.

 

Why Use Prefiltering?

Using prefiltering gives administrators the ability to decide what traffic should be passed directly to the Secure Firewall threat inspection engine (Snort) and what traffic can safely bypass it. This early decision-making process reduces latency and CPU usage, particularly for traffic that doesn’t require deep packet inspection.

 

Tunnel Rule Types in Prefilter Policies

Secure Firewall prefilter policies support Tunnel Rule Types, allowing filtering based on both the outer and inner IP headers of encapsulated traffic. Supported tunnel types include:

  • GRE
  • IP-in-IP
  • IPv6-in-IPv4
  • Teredo (UDP Port 3544)

This feature is particularly useful in environments where multiple encapsulation protocols are in use and specific flows need to be allowed or blocked before entering deeper inspection stages.

 

Advanced Filtering Capabilities

With a prefilter policy, Secure Firewall can:

  • Match and process traffic based on inner and outer headers, especially for tunneled packets.
  • Block tunneled non-encrypted traffic such as ICMP inside GRE tunnels (e.g., clear-text GRE carrying ICMP payloads).
  • Allow precise, early-stage control over traffic routing and inspection.

 

Rule Types Inside a Prefilter Policy

A Secure Firewall prefilter policy supports two types of rules:

  1. Tunnel Rules – For identifying and handling tunneled traffic based on header values.
  2. Prefilter Rules – For general traffic filtering before it reaches the main access control policy.

 

Logging and Event Correlation

When logging is enabled, Secure Firewall records block or drop actions enforced by the prefilter policy. These events can be reviewed in Analysis > Connections > Events

This provides visibility into traffic that was filtered before hitting the main access control policy, which is essential for troubleshooting and auditing purposes.

Prefiltering in Cisco Secure Firewall offers a strategic advantage for improving performance and enforcing early traffic decisions. By matching on tunnel types and header content, you can offload unnecessary inspection and streamline trusted communications without sacrificing visibility or control.

 

Creating and Deploying a Prefilter Policy

After understanding the purpose and benefits of a prefilter policy, let’s walk through how to create and apply one within the Secure Firewall Management Center (FMC).

Step 1: Navigate to the Prefilter Policy Menu

  • To begin creating a new prefilter policy, go to Policies > Access Control > Prefilter

 

  • Click on New Policy
  • Enter a name and an optional description. This will create a new prefilter policy instance.
  • Once created, this policy will allow you to define rules based on traffic types, tunnel characteristics, and header values.

 

 

Step 2: Define Prefilter and Tunnel Rules

Within a prefilter policy, you can configure two types of rules:

  • Prefilter Rules – General traffic handling rules for early-stage processing.
  • Tunnel Rules – Special rules for matching and managing tunneled traffic such as GRE, IP-in-IP, and Teredo.

 

By default:

  • Non-tunneled traffic is allowed.
  • Tunneled traffic is analyzed.

You can modify this behavior under the Default Action settings at the bottom of the policy editor.

 

 

Step 3: Configuring Prefilter Rule Actions

When creating a Prefilter Rule or Tunnel Rule, you have three options under the Action field:

  • Analyze – Passes traffic to the Snort engine for further inspection and policy enforcement.
  • Block – Immediately drops traffic without inspection.
  • Fastpath – Allows traffic to bypass all further inspection, including:
    • Security Intelligence
    • Access Control Rules
    • Deep Packet Inspection (DPI)
    • SSL decryption
    • Identity policies
    • Rate limiting and discovery mechanisms
  • Based on the action specified, you may or may not be able to log under the Logging tab:
    • Analyze – No logging events generated
    • Block – May optionally configure Log at Beginning of Connection
    • Fastpath – May optionally configure Log at Beginning of Connection or Log at End of Connection

 

Fastpath is best used for trusted traffic where performance is critical and inspection is unnecessary. However, it’s important to note that Fastpath is unidirectional—return traffic must also be explicitly fastpathed if needed.

  • When creating the prefilter rule, you can define the matched traffic based on one or many of the following criteria:
    • Source Interface Object
    • Destination Interface Object
    • Source Network
    • Destination Network
    • VLAN tag
    • Source Port
    • Destination Port
  • Prefilter rules can also be configured with a time range in which the rule would apply.

 

 

Step 4: Configuring a Tunnel Rule in Secure Firewall

Tunnel Rule Considerations

When creating Tunnel Rules in a prefilter policy, remember:

  • The tunnel must be unencrypted in order for Secure Firewall to inspect beyond the outer IP header.
  • Tunnel rules can be configured in one of two modes:
    • Match tunnels only from source
    • Match tunnels from both source and destination (for bidirectional control)

This is particularly useful when controlling GRE or IP-in-IP traffic between known endpoints.

  • Click Add Tunnel Rule Link.
  • Enter a name and choose your action (Analyze, Block, or Fastpath).
  • When you assign a tunnel zone in a tunnel rule and set the action to Analyze, Secure Firewall rezones the matching tunnel traffic. This rezoning lets access control and other policies treat all encapsulated connections as part of a single flow. Using the tunnel zone as an interface constraint allows you to apply targeted inspection to those encapsulated connections. Assign the rule to a Tunnel Zone if required.
  • A tunnel rule’s direction determines how traffic matches against source and destination criteria. Unidirectional rules match traffic flowing from the defined source to the destination, while bidirectional rules match both directions, effectively acting like two mirrored unidirectional rules. It’s important to note that prefilter rules are always unidirectional, regardless of configuration. You may select Match tunnels only from source or Match tunnels from source and destination in the rule. The default is Match tunnels from source and destination.
  • Define source and destination tunnel endpoints under the Tunnel Endpoints tab:
    • For example: 1.2.3.4/32 as the source and 198.19.30.10/32 as the destination.

 

  • In the Encapsulation & Ports tab, you can specify the encapsulation protocol used in the tunnel. Secure Firewall supports:
    • GRE
    • IP-in-IP
    • IPv6-in-IP
    • Teredo (Port 3544)
  • This allows you to target specific tunnel types for inspection, blocking, or bypassing. This flexibility is vital in complex enterprise environments where multiple tunneling protocols coexist.
  • You can also optionally match traffic for this rule based on:
    • Source Interface Objects
    • Destination Interface Objects
    • VLAN tags
  • The Tunnel Rule can also be configured with a time range in which the rule would apply.
  • Based on the action specified, you may or may not be able to log under the Logging tab:
    • Analyze – No logging events generated
    • Block – May optionally configure Log at Beginning of Connection
    • Fastpath – May optionally configure Log at Beginning of Connection or Log at End of Connection

 

 

Step 5: Assign the Prefilter Policy to an Access Control Policy

After defining your rules, you need to bind the prefilter policy to an existing Access Control Policy.

  • To do this, go to Policies > Access Control > Access Control
  • Edit the access control policy in use

 

  • Assign your newly created prefilter policy under the Prefilter Policy section.

Important Note: You can only assign one prefilter policy per access control policy, and only one access control policy per device.

 

 

Step 6: Verifying and Fine-Tuning Your Prefilter Policy

Verifying the Prefilter Policy from the CLI

Once your prefilter policy has been created and deployed via FMC, you can validate its presence on the Secure Firewall device using the CLI. Run the following command:

show running-config access-list

This will display the access lists applied on the device, including those generated by prefilter rules.

 

Verifying the Prefilter Policy in the GUI

  • Navigate to Analysis> Unified Events to view traffic hitting a specific prefilter policy if logging is enabled

 

  • Click on the column icon, check the box next to Prefilter Policy, and click Apply.

 

  • Scroll all the way to the right. You should now see the Prefilter Policy column. Highlight one of the empty spaces in the column.
  • Click on the three dots on the right.

 

  • From the dropdown menu, choose Add Inclusion to Filter

 

  • You can click x to remove the policy that pre-populated in the top filter
  • Type in the name of the prefilter policy that you would like to view traffic for. Note: If logging is not turned on for the rule or policy, this will show nothing.
  • Optionally, you can click the Go Live button to see the connection events that hit the policy in real time as they are logged by the Secure Firewall devices.

Implementing a prefilter policy in Cisco Secure Firewall allows administrators to streamline traffic flows by filtering early based on simple yet powerful logic. Key benefits include:

  • Reduced inspection overhead
  • Improved device performance
  • Granular control over tunnel and non-tunnel traffic
  • Enhanced ability to scale inspection with intelligence
  • Optimize performance by excluding traffic from deep inspection
  • Secure environments by selectively allowing or blocking tunnel traffic
  • Maintain visibility and control over encapsulated flows

By combining Tunnel Rules and Prefilter Rules, Secure Firewall offers flexible, high-performance traffic control before deeper inspection begins.