How Standard Firewall Filters Evaluate Packets

Firewall Filter Packet Evaluation Overview

The following sequence describes how the device evaluates a packet entering or exiting an interface if the input or output traffic at a device interface is associated with a firewall filter. Packet evaluation proceeds as follows:

1. The device evaluates the packet against the terms in the firewall filter sequentially, beginning with the first term in the filter.

   • If the packet matches all the conditions specified in a term, the device performs all the actions specified in that term.

   • If the packet does not match all the conditions specified in a term, the device proceeds to the next term in the filter (if a subsequent term exists) and evaluates the packet against that term.

   • If the packet does not match any term in the firewall filter, the device implicitly discards the packet.

2. Unlike service filters and simple filters, firewall filters support the next term action, which is neither a terminating action nor a nonterminating action but a flow control action.

   Note:

   On Junos and Junos OS Evolved, next term cannot appear as the last term of the action. A filter term where next term is specified as an action but without any match conditions configured is not supported.

   • If the matched term includes the next term action, the device continues evaluation of the packet at the next term within the firewall filter.

   • If the matched term does not include the next term action, evaluation of the packet against the given firewall filter ends at this term. The device does not evaluate the packet against any subsequent terms in this filter.

   A maximum of 1024 next term actions are supported per firewall filter configuration. If you configure a firewall filter that exceeds this limit, your candidate configuration results in a commit error.

3. The device stops evaluating a packet against a given firewall filter when either the packet matches a term without the next term action or the packet fails to match the last term in the firewall filter.

4. If a local packet arrives at a router interface that is associated with an ingress firewall filter, the filter evaluates the packet twice. The first evaluation occurs in the Packet Forwarding Engine, which is the central processing element of the router's forwarding plane, and the second evaluation occurs in the Routing Engine, which runs the router's control plane software.

   Note:

   Local packets--chunks of data that are destined for or sent by the router itself--usually contain routing protocol data, data for IP services such as Telnet or SSH, and data for administrative protocols such as the Internet Control Message Protocol (ICMP).

   If the first evaluation of the firewall filter modifies the incoming local packet or packet context values, the second evaluation of the firewall filter is based on the updated packet or packet context values.

   For example, suppose that the filter includes a match condition based on the forwarding class or loss priority value associated with the packet and that the filter includes an action that modifies the forwarding class or loss priority value associated with the packet. If an ingress local packet arrives at an associated interface and the filter evaluation in the Packet Forwarding Engine modifies (rather than drops) the packet, then the filter evaluation in the Routing Engine is based on the modified packet context (rather than the original packet context).

Packet Evaluation at a Single Firewall Filter

Table 1 describes packet-filtering behaviors at a device interface associated with a single firewall filter.

term t_explicit_discard {
    then discard;
}

Best Practice: Explicitly Accept Any Traffic That Is Not Specifically Discarded

You might want a firewall filter to accept any traffic that the filter does not specifically discard. In this case, we recommend that you configure the firewall filter with a final term that specifies the accept terminating action.

In the following example snippet, configuring the t_allow_all_else term as the final term in the firewall filter explicitly configures the firewall filter to accept any traffic that the filter did not specifically discard :

term t_allow_all_else {
    then accept;
}

Following this best practice can simplify troubleshooting of the firewall filter.

Best Practice: Explicitly Reject Any Traffic That Is Not Specifically Accepted

On the other hand, you might want a firewall filter to reject any traffic that the firewall filter does not specifically accept. In this case, we recommend that you configure the firewall filter with a final term that specifies the reject terminating action.

In the following example snippet, configuring the t_deny_all_else term as the final term in the firewall filter explicitly configures the firewall filter to reject any traffic that the filter did not specifically accept:

term t_deny_all_else {
    then reject;
}

Following this best practice can simplify troubleshooting of the firewall filter.

Multiple Firewall Filters Attached to a Single Interface

On supported device interfaces, you can attach multiple firewall filters to a single interface. For more information, see Understanding Multiple Firewall Filters Applied as a List.

Single Firewall Filter Attached to Multiple Interfaces

On supported interfaces, you can associate a single firewall filter with multiple interfaces, and Junos OS creates an interface-specific instance of that firewall filter for each associated interface.

• Junos OS associates each interface-specific instantiation of a firewall filter with a system-generated, interface-specific name.

• For any count actions in the filter terms, the Packet Forwarding Engine maintains separate, interface-specific counters, and Junos OS associates each counter with a system-generated, interface-specific name.

• For any policer actions in the filter terms, Junos OS creates separate, interface-specific instances of the policer actions.

For more information, see Interface-Specific Firewall Filter Instances Overview.