Prefilter Policies

The prefilter policy is the first security policy applied to incoming connections. Prefilter rules evaluate traffic on layer 3/4 criteria only, that is, protocol and source/destination IP address and port. They give you a chance to make early decisions on connections so you can avoid further processing and improve device performance.

The following topics explain prefilter policies.

About prefilter policies

The prefilter policy is the first security policy applied to incoming connections. Prefilter rules evaluate traffic on layer 3/4 criteria only, that is, protocol and source/destination IP address and port. They give you a chance to make early decisions on connections so you can avoid further processing and improve device performance.

Use prefilter policies to implement the following main actions:

  • Improve performance—The sooner you exclude traffic that does not require inspection, the better. Specifically, you can:

    • Offload trusted flows—If your device supports flow offload, use the prefilter Fastpath action to identify flows you trust to be eligible for offloading to NIC processing. No further processing, including inspection, is needed for these connections. See Best practices for fastpath prefiltering and Large flow offloads.

    • Block unwanted connections—For example, if you know you want to block entire subnets, or entire protocols or TCP/UDP ports, this is ideally done in the prefilter policy.

  • Rezone plain text encapsulated tunnels so you can handle them as a unit in the access control policy. Some protocols, such as GRE, create a plain-text tunnel that includes many connections within the tunnel. By rezoning a tunnel, you give the tunnel a tag, which you can then select in access control rules as a source/destination zone, and thus apply customized intrusion or other rules to the tunneled traffic. This provides granular insight and control for plain-text tunnels.


    Note

    VPN or other encrypted tunnels are not plain-text tunnels and cannot be rezoned.

You must assign each access control policy a prefilter policy. However, the system comes with a pre-defined prefilter policy that might work for you.

The following topics provide more detail about the prefilter policy.

The default prefilter policy

Every access control policy must have an assigned prefilter policy. For convenience, the system includes a default prefilter policy that is automatically assigned when you create a new access control policy. You cannot delete this policy.

The default prefilter policy does one thing: it analyzes plain-text encapsulated tunnels. This makes it possible for the access control policy to act on the connections that are contained within the tunnel.

You can instead change the default policy to block all plain-text tunnels. See Configuring the default action.

If you want to do any other customization, including adding prefilter or tunnel rules, you must create your own prefilter policy and assign it to the appropriate access control policies, as explained in Assigning devices to an access control policy.

Prefilter policy rule order

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. Prefilter rules have a wider range of constraints.

    Rules are match in top-down order, first match wins. Thus, rule order is critical. For example, you might want to block an entire subnet except for two specific IP addresses on the subnet. In that case:

    • The first rule should specify the two allowable IP addresses as the source network, and the rule action would be Analyze. Connections from these two IP addresses would match this rule, and the next rule would not be processed.

    • The next rule should specify the entire subnet as the source network, with Block for the rule action.

    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 (Analyze 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. These connections might subsequently be blocked by other policies, or ultimately allowed.

Changing Rule Order

If you need to change rule order, you can:

  • Drag and drop the rule to the right location.

  • Right click the rule and Cut, then find the right location, right click, and select Paste Above or Paste Below.

  • Edit the rule and use the Insert control to change its location.

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: GRE, IP-in-IP, IPv6-in-IP, Toredo.

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.

Network conditions constrain the source and destination hosts in each connection.

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 Using tunnel zones to apply access control at the tunnel level.

Not applicable.

How the system processes plain-text tunnels

Some protocols, such as GRE, create plain-text (not encrypted) tunnels that contain (or encapsulate) multiple inner connections. These connections might flow between discontinuous networks. These tunnels are especially useful for routing custom protocols over IP networks, IPv6 traffic over IPv4 networks, and so on.

Thus, a plain-text tunnel has two sets of IP headers:

  • Outer header—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.

    The prefilter policy uses outer headers to handle traffic. You can block or fast path entire plaintext, passthrough tunnels at this stage.

  • Inner headers—Inner payload headers specify the source and destination IP addresses of the encapsulated connections' actual endpoints. There are separate headers for each connection contained within the tunnel.

    Any tunnels that you analyze (that is, not block or fast path) have these inner headers exposed for use by the rest of the security policies and other features such as QoS. These features use the innermost detectable level of headers to ensure the most granular level of inspection and handling possible. This ensures that bad actors cannot hide illegitimate traffic within a plain-text tunnel.

For regular, non-tunneled connections, there is only the “outer” header, as the connection does not contain any subordinate connections.

If you do not want to allow plain-text tunnels at all, you can set the default action in the prefilter policy to block all plain-text tunnels. This block does not apply to encrypted tunnels such as VPN.

Alternatively, you can use tunnel zones to re-tag tunneled traffic so that you can write access control rules specifically for select tunnels. This lets you customize intrusion inspection or other layer 7 filtering to connections contained with a tunnel. See Using tunnel zones to apply access control at the tunnel level.

Using tunnel zones to apply access control at the tunnel level

As explained in How the system processes plain-text tunnels, once a plain-text tunneled connection passes through the prefilter policy, the access control policy applies its rules to each connection contained within the tunnel.

However, you might want to apply the same policy to all the connections within a tunnel. For example, you might have a special intrusion policy you want to use for tunneled connections.

To make it possible to apply access control rules to all connections within a tunnel, you must use the prefilter policy to re-zone the tunnel. Re-zoning applies a tunnel zone tag to the plain-text tunnel. You can then use that tunnel zone instead of a security zone when you define the source interface criterion of an access control rule.

Because a tunnel zone does not contain interfaces, the source interface through which the tunnel enters the device is not relevant. You can apply the tunnel zone tag to multiple different tunnels that enter the device through different interfaces and have access control treat them all in a like manner.


Note

Connections in rezoned tunnels do not match security zone constraints in an access control rule. After you rezone a tunnel, access control rules can match its encapsulated connections with their newly assigned tunnel zone, but not with any original security zone.

See How to rezone tunnels for customized inspection for a walkthrough of a tunnel zone implementation, and a discussion of the implications of rezoning without explicitly handling rezoned traffic.

Large flow offloads

For the following models, certain traffic that you configure to be fastpathed by a prefilter policy is handled by the hardware (specifically, in the NIC), not by the Firewall Threat Defense software:

  • Firepower 4100/9300

  • Secure Firewall 3100 (static only)

Offloading these flows results in higher throughput and lower latency, especially for data-intensive applications such as large file transfers. This feature is especially useful for data centers. This is called static flow offload.

In addition, by default, devices offload flows based on other criteria, including trust. This is called dynamic flow offload. Dynamic flow offload is not supported on the Secure Firewall 3100.

Offloaded flows continue to receive limited stateful inspection, such as basic TCP flag and option checking. The system can selectively escalate packets to the firewall system for further processing if necessary.

Examples of applications that can benefit from offloading large flows are:

  • High Performance Computing (HPC) Research sites, where the firewall is deployed between storage and high compute stations. When one research site backs up using FTP file transfer or file sync over NFS, the large amount of data traffic affects all connections. Offloading FTP file transfer and file sync over NFS reduces the impact on other traffic.

  • High Frequency Trading (HFT), where the firewall is deployed between workstations and the Exchange, mainly for compliance purposes. Security is usually not a concern, but latency is a major concern.

The following flows can be offloaded:

  • (Static flow offload only.) Connections that are fastpathed by the prefilter policy.

  • Standard or 802.1Q tagged Ethernet frames only.

  • (Dynamic flow offload only):

    • Inspected flows that the inspection engine decides no longer need inspection. These flows include:

      • Flows handled by access control rules that apply the Trust action and are based on security zone, source and destination network and port matching only.

      • TLS/SSL flows that are not selected for decryption using a decryption policy.

      • Flows that are trusted by the Intelligent Application Bypass (IAB) policy either explicitly or due to exceeding flow bypass thresholds.

      • Flows that match file or intrusion policies that result in trusting the flow.

      • Any allowed flow that no longer needs to be inspected.

    • The following IPS preprocessor inspected flows:

      • SSH and SMTP.

      • FTP preprocessor secondary connections.

      • Session Initiation Protocol (SIP) preprocessor secondary connections.

    • Intrusion rules that use keywords (also referred to as options)


Important

For details, exceptions, and limitations to the above, see Flow offload limitations.

Use static flow offload

To offload eligible traffic to hardware, create a prefilter policy rule that applies the Fastpath action. Use prefilter rules for TCP/UDP, and tunnel rules for GRE.

(Not recommended.) To disable flow offload, use FlexConfig:

  • Disable static (and thereby dynamic) flow offload: no flow-offload enable

  • Re-enable flow offload: flow-offload enable

For more information, see Cisco Secure Firewall ASA Series Command Reference.

Use dynamic flow offload

Dynamic flow offload is enabled by default. However, dynamic offload occurs only if static flow offload is enabled, regardless of whether prefiltering is configured.

To disable dynamic flow offload, use the device CLI:

  • Disable dynamic offload: configure flow-offload dynamic whitelist disable

  • Re-enable dynamic offload: configure flow-offload dynamic whitelist enable

Flow offload limitations

Not all flows can be offloaded. Even after offload, a flow can be removed from being offloaded under certain conditions. Following are some of the limitations:

Device limitations

The feature is supported on the following devices:

  • Secure Firewall 3100

  • Firepower 4100/9300

Flows that cannot be offloaded

The following types of flows cannot be offloaded.

  • Any flows that do not use IPv4 addressing, such as IPv6 addressing.

  • Flows for any protocol other than TCP, UDP, and GRE.


    Note

    PPTP GRE connections cannot be offloaded.

  • Flows on interfaces configured in passive, inline, or inline tap mode. Routed and switched interfaces are the only types supported.

  • (3100.) Offload based on inner header for tunnelled flows.

  • (3100.) Multi-instance offload.

  • Flows that require inspection by Snort or other inspection engines. In some cases, such as FTP, the secondary data channel can be offloaded although the control channel cannot be offloaded.

  • IPsec and TLS/DTLS VPN connections that terminate on the device.

  • Flows that require encryption or decryption. For example, connections decrypted due to a decryption policy.

  • Multicast flows in routed mode. They are supported in transparent mode if there are only two member interfaces in a bridge group.

  • TCP Intercept flows.

  • TCP state bypass flows. You cannot configure flow offload and TCP state bypass on the same traffic.

  • Flows tagged with security groups.

  • Reverse flows that are forwarded from a different cluster node, in the case of asymmetric flows in a cluster.

  • Centralized flows in a cluster, if the flow owner is not the control unit.

  • Flows that include IP options cannot be dynamically offloaded.

Additional limitations

  • Flow offload and Dead Connection Detection (DCD) are not compatible. Do not configure DCD on connections that can be offloaded.

  • If more than one flow that matches flow offload conditions are queued to be offloaded at the same time to the same location on the hardware, only the first flow is offloaded. The other flows are processed normally. This is called a collision. Use the show flow-offload flow command in the CLI to display statistics for this situation.

  • Dynamic flow offload disables all TCP normalizer checks.

  • Although offloaded flows pass through FXOS interfaces, statistics for these flows do not appear on the logical device interface. Thus, logical device interface counters and packet rates do not reflect offloaded flows.

Dynamic flow offload not supported on certain devices

Dynamic flow offload is not supported on the Secure Firewall 3100.

Conditions for reversing offload

After a flow is offloaded, packets within the flow are returned to the Firewall Threat Defense for further processing if they meet the following conditions:

  • They include TCP options other than Timestamp.

  • They are fragmented.

  • They are subject to Equal-Cost Multi-Path (ECMP) routing, and ingress packets move from one interface to another.

  • A change to the routing table applies to the flow. A packet is returned to the device to determine the new route.

Prefilter vs access control policy

Prefilter and access control policies both allow you to block and trust traffic, though the prefilter "trust" functionality is called "fastpathing" because it skips more inspection. The following table explains this and other differences between the prefilter and access control policies, to help you decide whether to configure a custom prefilter policy.

If you do not configure a custom prefilter policy, you can only approximate—not replicate—prefilter functionality with early-placed Block and Trust rules in the access control policy.

Characteristic

Prefilter Policy

Access Control Policy

Primary function

Quickly fastpath or block certain types of plaintext, passthrough tunnels, 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.

Sequence within access control

First.

The system matches traffic to prefilter criteria before all other access control configurations.

Thus, fast-pathing in a prefilter policy skips many other policies and inspections.

Last.

Other policies that might inspect a connection, including Security Intelligence and decryption, are applied before access control rules are evaluated.

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. See Access control rule actions.

Bypass capability

Fastpath rule action.

Fastpathing traffic in the prefilter stage bypasses all further inspection and handling, including:

  • Security Intelligence

  • User identity discovery (identity policy)

  • Decryption

  • Access control rules

  • Deep inspection of packet payloads

  • Discovery

  • Rate limiting

Trust rule action.

Traffic trusted by access control rules is only exempt from intrusion inspection and discovery. If another policy that requires inspection is applied to a connection that is eventually trusted, the connection is inspected anyway.

Trust really just means you are not applying intrusion or file policies to the connection.

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.

See How the system processes plain-text tunnels.

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. See Using tunnel zones to apply access control at the tunnel level.

Connection logging

Fastpathed and blocked traffic only. Allowed connections may still be logged by other configurations.

Any connection.

Requirements and prerequisites for prefilter olicies

Model support

Firewall Threat Defense

Supported domains

Any

User roles

  • Admin

  • Access Admin

  • Network Admin

Guidelines and limitations for the prefilter policy

  • You can log connections fast pathed and blocked by the prefilter policy. Prefilter connection events contain information on whether and how logged connections—including entire tunnels—were prefiltered. However, because fast pathed and blocked connections are not subject to deep inspection, associated connection events contain limited information.

  • 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.

  • When you deploy a prefilter policy, its rules are not applied on the existing connections. Hence, traffic on an existing connection is not bound by the new policy that is deployed. In addition, the policy hit count is incremented only for the first packet of a connection that matches a policy. Thus, the traffic on an existing connection that could match a policy is omitted from the hit count. To have the rules effectively applied, clear the existing connections, and then deploy the policy.

  • For a prefilter rule with action as Fastpath and logging options disabled, you might observe that the end-of-flow events are still generated in the system. However, the events are not visible on the management center event pages.

Guidelines and limitations for encapsulated traffic handling

This topic discusses guidelines for the following types of encapsulated traffic:

  • Generic Routing Encapsulation (GRE)

  • Point-to-Point Protocol (PPTP). (This protocol is not handled by tunnel rules in the prefilter policy.)

  • IPinIP

  • IPv6inIP

  • Teredo

GRE Tunnel Limitations

GRE tunnel processing is limited to IPv4 and IPv6 passenger flows. Other protocols, such as PPTP and WCCP, are not supported within the GRE tunnel.

GRE v1 and PPTP bypass outer flow processing

GRE v1 (sometimes referred to as stateful GRE) and PPTP traffic bypass outer flow processing.

Passenger flow processing is supported for IPv6inIP and Teredo but the following limitations apply:

  • Sessions are over a single tunnel that is not load-balanced.

  • There is no HA or clustering replication.

  • Primary and secondary flow relationships are not maintained.

  • Prefilter policy white and black lists are not supported.

GRE v0 sequence number field must be optional

All endpoints sending traffic on the network must send GREv0 traffic with the sequence number field as optional; otherwise, the sequence number field is removed. RFC 1701 and RFC 2784 both specify the sequence field as optional.

How tunnels work with interfaces

Prefilter and access control policy rules are applied to all tunnel types on routed, transparent, inline-set, inline-tap, and passive interfaces.

References

For more information about the GRE and PPTP protocols, see the following:

Best practices for fastpath prefiltering

When you use the fastpath action in a prefilter rule, the matching traffic bypasses inspection and is simply transmitted through the device. Use this action for traffic that you can trust and that would not benefit from any of the security features available.

The following types of traffic are ideal for fastpathing. For example, you could configure the rules to fastpath any traffic from or to the IP addresses of the endpoints or servers. You can further limit the rule based on ports used.

  • VPN traffic that is going through the device. That is, the device is not an endpoint in the VPN topology.

  • SQL traffic between trusted endpoints on the internal network.

  • Scanner traffic. Scanner probes can create a lot of false-positive responses from intrusion policies.

  • Voice/video.

  • Backups.

  • Management traffic (sftunnel) that traverses Firewall Threat Defense devices. Performing deep inspection on management traffic (using access control policies) can cause issues. You can prefilter based on port TCP/8305 between the management center and managed devices.

Configure prefilter policies

To perform custom prefiltering, configure prefilter policies and assign the policies to access control policies. It is through the access control policy that prefilter policies get assigned to managed devices.

Only one person should edit a policy at a time, using a single browser window. If multiple users save the same policy, the last saved changes are retained. For your convenience, the system displays information on who (if anyone) is currently editing each policy. To protect the privacy of your session, a warning appears after 30 minutes of inactivity on the policy editor. After 60 minutes, the system discards your changes.

Procedure

Step 1

Choose Policies > Access Control heading > Prefilter.

At the top of the page, there are convenient links to some related features: object management and access control.

You cannot tell from the prefilter page, or when editing a prefilter policy, whether it is used by an access control policy or which policies use it.

Step 2

Do any of the following:

  • Create—Click New Policy to create a custom prefilter policy. You are prompted for a name and an optional description. The new policy is opened for edit after you click Save. A new prefilter policy has no rules and a default action of Analyze all tunnel traffic.

  • Edit—Click Edit (edit icon) to open a policy so that you can add rules or otherwise modify it.

  • Copy—Click Copy (copy icon). You are prompted for a name. The copy is added to the list when you click OK, but it is not opened for edit.

  • Delete—Click Delete (delete icon) to remove a policy. You cannot delete a policy that is currently being used by an access control policy.

Step 3

When editing a prefilter policy, you can do the following:

  • Set the default action—Set the default action for tunnels at the bottom of the policy. See Configuring the default action.

  • Add prefilter rules—Click Add Prefilter Rule. The rule is added to the bottom of the policy. See Configuring prefilter rules.

  • Add tunnel rules—Click Add Tunnel Rule. The rule is added to the bottom of the policy. See Configuring tunnel rules.

  • Insert rules—Right click the rule before where you want to add the new rule, and select either Insert New Prefilter Rule or Insert New Tunnel Rule, as appropriate.

  • Copy/cut and paste rules—To copy a rule, right-click the rule and select Copy. You can also cut the rule (remove it) by selecting Cut. Then, select where you want to insert the rule, right click, and select either Paste Above or Paste Below. When copying, a number in parentheses is added to the rule name; you should edit the rule and change the name and other criteria as needed. Cut rules retain the original name.

  • Edit a rule—Click Edit (edit icon) to open the rule editor. You can also click on any element for the rule in the table. See Configuring prefilter rules and Configuring tunnel rules.

  • Delete rules—Click Delete (delete icon) to remove a rule.

  • Move a rule—Click a rule and drag and drop it to the right location. Alternatively, cut the rule and then paste it in the right location. You can also change the rule location while editing it.

    Properly creating and ordering rules is a complex task, but one that is essential to building an effective deployment. If you do not plan carefully, rules can preempt other rules or contain invalid configurations. For more information, see Prefilter policy rule order.

  • Move a prefilter rule to an associated access control policy—To move a prefilter rule from the prefilter policy to an associated access control policy, right-click the rule and select Move to another policy. You cannot move tunnel rules to an access control policy. See Moving prefilter rules to an access control policy.

  • View hit counts—To view statistics on how many connections matched each rule, click Analyze Hit Counts. See Viewing rule hit counts.

  • Search for rules—Use the Search Rules box to do a plain text search. Type the string and press enter. The search box shows the number of hits and up/down buttons to move through them.

    Matches are highlighted in the table. Matches include partial hits, but only to explicitly set items. For example, entering “any” does not match the default network, but “any-ipv4” will match because it is a network object and not a passive default. Action and rule type do not match the search string.

  • View object details—To see the contents of an object used in a rule, right click the object and select Object Details.

  • Change the policy description—To modify the description of a policy, click in the description text below the policy name at the top of the page. Click away from the description to save changes.

Be sure to click Save to save any changes you make.

Step 4

Use the prefilter policy in the appropriate access control policies.

For each access control policy that should use a custom prefilter policy:

  • Edit the access control policy and select the prefilter policy in the Prefilter Policy link or in the advanced settings. See Associating other policies with access control.

  • If you applied tunnel zone tags in any tunnel rules, create access control rules that use those tunnel zones as source interface criteria.

What to do next

You can now deploy changes.

If you will deploy time-based rules, specify the time zone of the device to which the policy is assigned. See Time Zone.

Configuring the default action

Use the default action to determine how plain-text encapsulated tunnels that do not match any tunnel rules should be handled.

The default action does not apply to non-tunnel traffic. Any other connections that do not match prefilter rules are passed on for processing by subsequent policies.

Procedure

Step 1

Choose Policies > Access Control heading > Prefilter and create or edit a prefilter policy.

Step 2

Choose a Default Action: Tunneled Traffic option:

  1. Analyze all tunnel traffic—These tunnels are allowed and their encapsulated connections are evaluated by the access control and other policies

    Block all tunnel traffic—Tunnels are dropped and no longer evaluated.

Step 3

If you select Block all tunnel traffic, click Logging (logging icon) next to the default action.

See Logging Connections with a Policy Default Action in the Cisco Secure Firewall Management Center Administration Guide You can configure default action logging for blocked tunnels only.

Configuring prefilter rules

Use prefilter rules in a non-default prefilter policy to provide early blocking for unwanted traffic, and to fast path traffic that does not benefit from access control inspection.

If your device supports flow offload, fast path traffic is eligible for flow offload if it meets all other criteria. See Large flow offloads.

Before you begin

You cannot create rules in the default prefilter policy. If you have not created a custom prefilter policy, do so now.

Procedure

Step 1

Choose Policies > Access Control heading > Prefilter and create or edit a prefilter policy.

Step 2

Click Add Prefilter Rule.

You can also right-click a rule and select Insert New Prefilter Rule.

Step 3

Enter a Name for the rule.

Step 4

Select whether the rule should be Enabled. A rule must be enabled to affect traffic through the device.

Step 5

Select the Action to be taken on matching traffic.

  • Fastpath—Exempts matching traffic from all further inspection and control, including access control, identity requirements, and rate limiting. These connections are eligible for flow offload if the device supports it.

  • Block—Blocks matching traffic without further inspection of any kind.

  • Analyze—Allows traffic to continue to be analyzed by the rest of access control. If passed by access control and any related deep inspection, this traffic may also be rate limited.

Step 6

Select where to Insert the rule.

The default is to insert the rule at the end of the policy, but you can select an existing rule and insert the new rule before or after that rule. The action of the first rule that matches a connection is applied to that connection, so order matters.

Step 7

(Optional.) Select the object that defines the Time Range for the rule.

You can limit what times of day, or which days, a rule is operational. For example, the rule could apply during business hours only. Select an existing time range object or create a new one. For more information, see Creating Time Range Objects.

Step 8

Configure the traffic matching conditions for the rule.

The rule is applied to connections that match all of the conditions. Within a condition type, separate elements are OR’ed, so that matching any of the selected items counts as a match. For the rule as a whole, all condition types are AND’ed: a connection must match at least one item on each tab to match the rule. You can use the following types of conditions:

  • Interface Objects—Select the security zones or interface groups that contain the interfaces to which the rule should apply. The default, no objects selected, applies the rule to all interfaces on the device.

  • Networks—Select the network objects that define the source (Add to Source) or destination (Add to Destination) IP addresses, or both. The default (no objects selected) matches all source and destination IP addresses.

  • VLAN tags—Select the objects that define the VLANs to which the rule should apply. For more information, see VLAN tags rule conditions.

  • Ports—Select the TCP/UDP ports, or other protocol, for the connections and add them to the source or destination criteria. Source criteria is TCP/UDP only, but you can select other protocols for the destination. For more information, see Port rule conditions for prefilter rules.

Step 9

(Fastpath and Block rules only.) Click Logging and configure how matching connections should be logged.

For more information, see Logging Connections with Tunnel and Prefilter Rules in the Cisco Secure Firewall Management Center Administration Guide.

Step 10

(Optional.) Click Comment and add comments to the rule. Use comments to help you understand the purpose of the rule and its change history.

Step 11

Click Add. If you need to move the rule, do so now.

Step 12

Click Save to save the policy.

VLAN tags rule conditions


Note

VLAN tags in access rules only apply to inline sets. Access rules with VLAN tags do not match traffic on firewall interfaces.

VLAN rule conditions control VLAN-tagged traffic, including Q-in-Q (stacked VLAN) traffic. The system uses the innermost VLAN tag to filter VLAN traffic, with the exception of the prefilter policy, which uses the outermost VLAN tag in its rules.

Note the following Q-in-Q support:

  • Firewall Threat Defense on Firepower 4100/9300—Does not support Q-in-Q (supports only one VLAN tag).

  • Firewall Threat Defense on all other models:

    • Inline sets and passive interfaces—Supports Q-in-Q, up to 2 VLAN tags.

    • Firewall interfaces—Does not support Q-in-Q (supports only one VLAN tag).

You can use predefined objects to build VLAN conditions, or manually enter any VLAN tag from 1 to 4094. Use a hyphen to specify a range of VLAN tags.

In a cluster, if you encounter problems with VLAN matching, edit the access control policy advanced options, Transport/Network Preprocessor Settings, and select the Ignore the VLAN header when tracking connections option.

Port rule conditions for prefilter rules

Port conditions match traffic based on the source and destination ports. Depending on the rule type, “port” can represent any of the following:

  • TCP and UDP—You can control TCP and UDP traffic based on the port. The system represents this configuration using the protocol number in parentheses, plus an optional associated port or port range. For example: TCP(6)/22. TCP and UDP are the only source ports supported. You can also specify them as destination ports.

  • ICMP—You can control ICMP and ICMPv6 (IPv6-ICMP) traffic based on its internet layer protocol plus an optional type and code. For example: ICMP(1):3:3. When you select ICMP as a destination port, you are prompted to specify the type and code.

  • Protocol—You can control traffic using other protocols that do not use ports. Not all protocols are supported. You must select the protocol as a destination port.

Using Source and Destination Port Constraints

If you add both source and destination port constraints, you can only add ports that share a single transport protocol (TCP or UDP). For example, if you add DNS over TCP as a source port, you can add Yahoo Messenger Voice Chat (TCP) as a destination port but not Yahoo Messenger Voice Chat (UDP).

If you add only source ports or only destination ports, you can add ports that use different transport protocols. For example, you can add both DNS over TCP and DNS over UDP as destination port conditions in a single access control rule.

Matching Non-TCP Traffic with Port Conditions

You can match non-port-based protocols. By default, if you do not specify a port condition, you are matching IP traffic. Although you can configure port conditions to match other protocols in prefilter rules, you should use tunnel rules instead when matching GRE, IP in IP, IPv6 in IP, and Toredo Port 3544.

Configuring tunnel rules

Use tunnel rules in a non-default prefilter policy to

  • Provide early blocking for unwanted encapsulated tunnel traffic.

  • Fast path tunnels that do not benefit from access control inspection.

  • Place encapsulated tunnels into a tunnel zone, called rezoning, so that you can write access control rules to apply inspection to the connections within the tunnel as a whole.

Before you begin

The prefilter policy’s default action applies to encapsulated tunnels. Thus, create rules for tunnel traffic only to apply different actions to specific tunnels.

For example, if the default action is to analyze tunnels, this means that all tunnels are passed on to the access control policies and other policies that inspect, allow, and potentially block connections, and these policies will evaluate the inner connections. If that default action is what you want for all tunnels, then you do not need to create any tunnel rules.

If instead:

  • The default action is to block encapsulated tunnels, use rules to exempt specific tunnels from blocking and either pass them to other access control policies (analyze action) or bypass any additional processing (fastpath).

  • There are tunnels where you want to apply access control rules to all encapsulated connections, create rules to rezone the tunnels to the appropriate tunnel zone tag and also write rules in the access control policy for those tunnel zone tags.

Procedure

Step 1

Choose Policies > Access Control heading > Prefilter and create or edit a prefilter policy.

Step 2

Click Add Tunnel Rule.

You can also right-click a rule and select Insert New Tunnel Rule.

Step 3

Enter a Name for the rule.

Step 4

Select whether the rule should be Enabled. A rule must be enabled to affect traffic through the device.

Step 5

Select the Action to be taken on matching traffic.

  • Fastpath—Exempts matching traffic from all further inspection and control, including access control, identity requirements, and rate limiting. Fastpathing a tunnel fastpaths all encapsulated connections. These connections are eligible for flow offload if the device supports it.

  • Block—Blocks matching traffic without further inspection of any kind. Blocking a tunnel blocks all encapsulated connections.

  • Analyze—Allows traffic to continue to be analyzed by the rest of access control using inner headers.. If passed by access control and any related deep inspection, this traffic may also be rate limited.

Step 6

Select where to Insert the rule.

The default is to insert the rule at the end of the policy, but you can select an existing rule and insert the new rule before or after that rule. The action of the first rule that matches a connection is applied to that connection, so order matters.

Step 7

(Analyze rules only; when rezoning only.) Select a tunnel zone tag in Assign Tunnel Zone if your intention is to rezone the tunnel.

Leave this option blank if you want access control to apply to the encapsulated connections within the tunnel without special processing. For more information about rezoning and tunnel group tags, see:

Caution

 

Exercise caution when assigning tunnel zones. Connections in rezoned tunnels may not match security zone constraints in later evaluation. See How to rezone tunnels for customized inspection for a brief walkthrough of a tunnel zone implementation, and a discussion of the implications of rezoning without explicitly handling rezoned traffic.

Step 8

(Optional.) Select the object that defines the Time Range for the rule.

You can limit what times of day, or which days, a rule is operational. For example, the rule could apply during business hours only. Select an existing time range object or create a new one. For more information, see Creating Time Range Objects.

Step 9

Select one of the following options to set the direction for the rule:

  • Match tunnels only from source (unidirectional)—Match source-to-destination traffic only. Matching traffic must originate from one of the specified source interfaces or tunnel endpoints, and leave through one of the destination interfaces or tunnel endpoints. Return traffic for allowed connections is also permitted. (Note that prefilter rules are always unidirectional.)

  • Match tunnels from source and destination (bidirectional)—Match both source-to-destination traffic and destination-to-source traffic. The effect is identical to writing two unidirectional rules, one the mirror of the other. This is the default.

Step 10

Click the Encapsulation & Ports tab and select the protocols for this rule.

You must select at least one of these options in a tunnel rule to specify the encapsulation protocol used. The list includes the IP protocol number for the option.

  • GRE (47)

  • IP-in-IP (4)

  • IPv6-in-IP (41)

  • Teredo (UDP (17)/3455)

Step 11

Configure the traffic matching conditions for the rule.

The rule is applied to connections that match all of the conditions. Within a condition type, separate elements are OR’ed, so that matching any of the selected items counts as a match. For the rule as a whole, all condition types are AND’ed: a connection must match at least one item on each tab to match the rule. You can use the following types of conditions:

  • Interface Objects—Select the security zones or interface groups that contain the interfaces to which the rule should apply. The default, no objects selected, applies the rule to all interfaces on the device.

  • Tunnel Endpoints—The network objects that define the source (Add to Source) and destination (Add to Destination) IP addresses of the tunnel. The default (no objects selected) matches all source and destination IP addresses.

  • VLAN tags—Select the objects that define the VLANs to which the rule should apply. For more information, see VLAN tags rule conditions.

Step 12

(Fastpath and Block rules only.) Click Logging and configure how matching connections should be logged.

For more information, see Logging Connections with Tunnel and Prefilter Rules in the Cisco Secure Firewall Management Center Administration Guide.

Step 13

(Optional.) Click Comment and add comments to the rule. Use comments to help you understand the purpose of the rule and its change history.

Step 14

Click Add. If you need to move the rule, do so now.

Step 15

Click Save to save the policy.

Creating tunnel zones

A tunnel zone represents certain types of plaintext, passthrough tunnels that you explicitly tag for special analysis. A tunnel zone is not an interface object, even though you can use it as an interface constraint in access control rules, as explained in Using tunnel zones to apply access control at the tunnel level.

The following procedure explains how to create a tunnel zone in the object manager. You can also create zones when editing a tunnel rule.

Procedure

Step 1

Choose Objects > Object Management.

Step 2

Choose Tunnel Zone from the list of object types.

Step 3

Click Add Tunnel Zone.

You can also edit an existing tunnel or delete a tunnel zone that is not being used in a tunnel rule.

Step 4

Enter a Name and, optionally, a Description.

Step 5

Click Save.

What to do next

  • Assign the tunnel zone to plaintext, passthrough tunnels as part of a tunnel rule. See Configuring tunnel rules.

  • Use the tunnel zone as source interface criteria in an access control rule.

Moving prefilter rules to an access control policy

You can move prefilter rules from a prefilter policy to the associated access control policy.

Before you begin

Note the following conditions before you proceed:

  • Only prefilter rules can be moved to an access control policy. Tunnel rules cannot be moved.

  • The prefilter rules can be moved only to an access control policy that uses the prefilter policy. Because you can use the same prefilter policy in multiple access control policies, you need to select the policies to which the rule should be moved.

  • The prefilter rules that use interface groups to define interface criteria cannot be moved. You can move only those rules that use security zones, or that include no interface criteria.

  • The Action parameter in the prefilter rule is changed to a suitable action in the access control rule when moved.

    • Analyze becomes allow.

    • Block becomes block.

    • Fastpath becomes trust.

  • The logging configuration in the rule is retained.

  • The comments in the prefilter rule configuration are lost after moving the rule. However, a new comment is added in the moved rule mentioning the source prefilter policy.

  • While moving rules from the source policy, if another user modifies those rules, you are warned. You can continue with the process after refreshing the page.

Procedure

Step 1

In the prefilter policy editor, select the rules that you want to move with a left-click on your mouse.

Tip

 

To select multiple rules, use Shift+click.

Step 2

Right-click the selected rules and choose Move to another policy.

Step 3

Select the destination access control policies and click Add to add them to the list of selected policies.

Step 4

From the Place Rules drop-down list, choose where you want to position the moved rules:

  • To position as the last set of rules in the Default section, choose At the bottom (within the Default section).
  • To position as the first set of rules in the Mandatory section, choose At the top (within the Mandatory section).

Step 5

Click Move.

What to do next

Examples of the prefilter policy

The following topics provide examples of using the prefilter policy.

How to rezone tunnels for customized inspection

This example procedure summarizes how you might rezone GRE tunnels for further analysis, using tunnel zones. You can adapt the concepts described in this example to other scenarios where you need to tailor traffic inspection to connections encapsulated in plaintext, passthrough tunnels.

Consider a situation where your organization's internal traffic flows through the Trusted security zone. The Trusted security zone represents a set of interfaces across multiple managed devices deployed in various locations. Your organization's security policy requires that you allow internal traffic after deep inspection for exploits and malware.

Internal traffic sometimes includes plaintext, passthrough, GRE tunnels between particular endpoints. Because the traffic profile of this encapsulated traffic is different from your "normal" interoffice activity—perhaps it is known and benign—you can limit inspection of certain encapsulated connections while still complying with your security policy.

In this example, after you deploy configuration changes:

  • Plaintext, passthrough, GRE-encapsulated tunnels detected in the Trusted zone have their individual encapsulated connections evaluated by one set of intrusion and file policies.

  • All other traffic in the Trusted zone is evaluated with a different set of intrusion and file policies.

You accomplish this task by rezoning GRE tunnels. Rezoning ensures that access control associates GRE-encapsulated connections with a custom tunnel zone, rather than their original Trusted security zone. Rezoning is required due to the way access control handles encapsulated traffic; see How the system processes plain-text tunnels and Using tunnel zones to apply access control at the tunnel level.

Procedure

Step 1

Configure custom intrusion and file policies that tailor deep inspection to encapsulated traffic, and another set of intrusion and file policies tailored to nonencapsulated traffic.

Step 2

Configure custom prefiltering to rezone GRE tunnels flowing through the Trusted security zone.

Create a custom prefilter policy and associate it with access control. In that custom prefilter policy, create a tunnel rule (in this example, GRE_tunnel_rezone) and a corresponding tunnel zone (GRE_tunnel). For more information, see Configuring tunnel rules.

Table 1. GRE_tunnel_rezone tunnel rule

Rule Component

Description

Interface object condition

Match internal-only tunnels by using the Trusted security zone as both a Source Interface Object and Destination Interface Object constraint.

Tunnel endpoint condition

Specify the source and destination endpoints for the GRE tunnels used in your organization.

Tunnel rules are bidirectional by default. If you do not change the Match tunnels from... option, it does not matter which endpoints you specify as source and which as destination.

Encapsulation condition

Match GRE traffic.

Assign Tunnel Zone

Create the GRE_tunnel tunnel zone, and assign it to tunnels that match the rule.

Action

Analyze (with the rest of access control).

Step 3

Configure access control to handle connections in rezoned tunnels.

In the access control policy deployed to your managed devices, ensure that the prefilter policy is used. Then, configure a rule (in this example, GRE_inspection) that handles the traffic you rezoned. For more information, see Create and edit access control rules.

Table 2. GRE_inspection access control rule

Rule Component

Description

Security zone condition

Match rezoned tunnels by using the GRE_tunnel tunnel zone as a Source Zone constraint.

Action

Allow, with deep inspection enabled.

Choose the file and intrusion policies tailored to inspect encapsulated internal traffic.

Caution

 

If you skip this step, the rezoned connections may match any access control rule not constrained by security zone. If the rezoned connections do not match any access control rules, they are handled by the access control policy default action. Make sure this is your intent.

Step 4

Configure access control to handle nonencapsulated connections flowing through the Trusted security zone.

In the same access control policy, configure a rule (in this example, internal_default_inspection) that handles non-rezoned traffic in the Trusted security zone.

Table 3. internal_default_inspection access control rule

Rule Component

Description

Security zone condition

Match non-rezoned internal-only traffic by using the Trusted security zone as both a Source Zone and Destination Zone constraint.

Action

Allow, with deep inspection enabled.

Choose the file and intrusion policies tailored to inspect nonencapsulated internal traffic.

Step 5

Evaluate the position of the new access control rules relative to preexisting rules. Change rule order if necessary.

If you place the two new access control rules next to each other, it does not matter which you place first. Because you rezoned GRE tunnels, the two rules cannot preempt each other.

Step 6

Save all changes.

What to do next

How to offload large flows

You can use the prefilter policy to configure static flow offload. If your hardware model supports it, flow offload moves eligible fast path connections to NIC processing, avoiding performance intensive inspection.

Some hardware models will dynamically identify off-loadable connections automatically, but you can proactively identify connections as being offload eligible by matching them to a prefilter fastpath rule. This static configuration helps you improve performance quickly for large connections that you know you can trust.

In the following example, it is assumed that two servers are behind sufficient protection so that you can trust the connections between them. Perhaps one server is using the other for backups. Thus, you can write a fastpath rule for any traffic going from the main server, 10.100.1.20/24, to the backup server, 10.100.2.2/24. The example assumes the servers are accessible through regular, physical routed interfaces.

Procedure

Step 1

Choose Policies > Access Control heading > Prefilter and create or edit a custom prefilter policy.

Step 2

Click Add Prefilter Rule.

You can also right-click a rule and select Insert New Prefilter Rule.

Step 3

Enter a Name for the rule. For example, Offload_Server_A.

Step 4

In Action, select Fastpath.

Step 5

In Insert, select the rule above or below which the rule should be inserted.

You can also move the rule after you create it.

Step 6

Click the Networks tab and specify the source and destination servers.

  • In the edit box below Source Networks, type 10.100.1.20 and click Add.

  • In the edit box below Destination Networks, type 10.100.2.2 and click Add.

Step 7

(Optional.) Configure the other traffic matching characteristics for the flow.

Click the following tabs to fill in the criteria. Only the Networks tab needs to be configured for this example, so configure these settings only if they make sense for your situation.

  • Interface objects—The security zones or interface objects that define the source or destination interfaces, or both. This specification is not needed for this example.

  • VLANs—Because this example uses routed physical interfaces instead of switch interfaces, this setting is not relevant. Even in those circumstances, you do not need to limit the rule based on VLAN.

  • Ports—If you want to limit the offload to specific TCP/UDP ports, you can specify them. This limits the scope of the rule to these ports only.

Step 8

(Optional.) Click Logging and decide whether you want to see syslog events for matching traffic.

Step 9

Click Add to add the rule.

Take the time to move the rule to the right location in the policy if it is not already there.

Step 10

Click Save to save the policy.

The next time you deploy the configuration, the rule will be applied to the target devices.

History for the prefilter policy

Feature

Minimum Firewall Management Center

Minimum Firewall Threat Defense

Details

Moving prefilter rules to an access control policy

6.7

Any

You can move prefilter rules from a prefilter policy to the associated access control policy.

New/modified pages: In the prefilter policy page, the right-click menu for the selected rules provides a new Move to another policy option.

Supported platforms: Firewall Management Center

Time-based rules

6.6

Any

Ability to apply prefilter and tunnel rules depending on the date and time, as determined by the time zone of the device.

View Object Details from prefilter rule page

6.6

Any

Feature introduced: Option to view details for an object or object group when viewing prefilter rules.

New options: Right-clicking a value in any of the following columns in the prefilter rule list offers an option to view object details: Source Networks, Destination Networks, Source Port, Destination Port, and VLAN Tag.