Understanding Multiple Firewall Filters Applied as a List

The Challenge: Simplify Large-Scale Firewall Filter Administration

Typically, you apply a single firewall filter to an interface in the input or output direction or both. However, this approach might not be practical when you have a device configured with many interfaces. In large environments, you want the flexibility of being able to modify filtering terms common to multiple interfaces without having to reconfigure the filter of every affected interface.

In general, the solution is to apply an effectively “chained” structure of multiple firewall filters to a single interface. You partition your filtering terms into multiple firewall filters that each perform a filtering task. You can then choose which filtering tasks you want to perform for a given interface and apply the filtering tasks to that interface. In this way, you only manage the configuration for a filtering task in a single firewall filter.

The Junos filter infrastructure provides two options for managing the application of multiple separate firewall filters to individual router interfaces. One option is to apply multiple filters as a single input list or output list. The other option is to reference a firewall filter from within the term of another firewall filter. See Example: Applying Lists of Multiple Firewall Filters and Example: Nesting References to Multiple Firewall Filters .

A Solution: Apply Lists of Firewall Filters

The most straightforward way to avoid configuring duplicate filtering terms common to multiple firewall filters is to configure multiple firewall filters and then apply a customized list of filters to each interface. The Junos OS uses the filters—in the order in which they appear in the list—to evaluate packets that transit the interface. If you need to modify filtering terms shared across multiple interfaces, you only need to modify one firewall filter that contains those terms.

Configuration of Multiple Filters for Filter Lists

Configuring firewall filters to be applied in unique lists for each router interface involves separating shared packet-filtering rules from interface-specific packet-filtering rules as follows:

• Unique filters—For each set of packet-filtering rules unique to a specific interface, configure a separate firewall filter that contains only the filtering terms for that interface.

• Shared filters—For each set of packet-filtering rules common across two or more interfaces, consider configuring a separate firewall filter that contains the shared filtering terms.

  Tip:

  When planning for a large number firewall filters to be applied using filter lists, administrators often organize the shared filters by filtering criteria, by the services to which customers subscribe, or by the purposes of the interfaces.

Application of Filter Lists to a Router Interface

Applying a list of firewall filters to an interface is a matter of selecting the filters that meet the packet-filtering requirements of that interface. For each interface, you can include an input-list or output-list statement (or both) within the filter stanza to specify the relevant filters in the order in which they are to be used:

• Include any filters that contain common filtering terms relevant to the interface.

• Include the filter that contain only the filtering terms unique to the interface.

Interface-Specific Names for Filter Lists

Because a filter list is configured under an interface, the resulting concatenated filter is interface-specific.

Note:

When a filter list is configured under an interface, the resulting concatenated filter is interface-specific, regardless whether the firewall filters in the filter list are configured as interface-specific or not. Furthermore, the instantiation of interface-specfic firewall filters not only creates separate instances of any firewall filter counters, but also separate instances of any policer actions. Any policers applied through an action specified in the firewall filter configuration are applied separately to each interface in the interface group.

The system-generated name of an interface-specific filter consists of the full interface name followed by either ’-i’ for an input filter list or ’-o’ for an output filter list.

• Input filter list name—For example, if you use the input-list statement to apply a chain of filters to logical interface ge-1/3/0.0, the Junos OS uses the following name for the filter:

• Output filter list name—For example, if you use the output-list statement to apply a chain of filters to logical interface fe-0/1/2.0, the Junos OS uses the following name for the filter:

Note:

For Junos OS Evolved, the filter names are different. For example, if the filters are bound to the inet family, the filters are named ge-1/3/0/0-inet-i and fe-0/1/2.0-inet-o.

You can use the interface-specific name of a filter list when you enter a Junos OS operational mode command that specifies a firewall filter name.

How Filter Lists Evaluate Packets When the Matched Term Includes Terminating or Next Term Actions

The device evaluates a packet against the filters in a list sequentially, beginning with the first filter in the list until either a terminating action occurs or the packet is implicitly discarded.

Table 1 describes how a firewall filter list evaluates a packet based on whether the matched term specifies a terminating action and the next term action. The next term action is neither a terminating action nor a nonterminating action but a flow control action.

Table 1: Firewall Filter List Behavior

Firewall Filter Actions Included in the Matched Term		Term Description	Packet-Filtering Behavior
Terminating	next term
Yes	—	The matched term includes a terminating action (such as discard) but not the next term action	The device executes the terminating action. No subsequent terms in the filter and no subsequent filters in the list are used to evaluate the packet.
—	Yes	The matched term includes the next term action, but it does not include any terminating actions.	The device executes any nonterminating actions, then the device evaluates the packet against the next term in the filter or the next filter in the list. Note: On 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.
—	—	The matched term includes neither the next term action nor any terminating actions.	The device executes any nonterminating actions, then the device implicitly accepts the packet. Because the accept action is a terminating action, no subsequent terms in the filter and no subsequent filters in the list are used to evaluate the packet.

For information about terminating actions, see Firewall Filter Terminating Actions.

Note:

You cannot configure the next term action with a terminating action in the same firewall filter term.

How Filter Lists Evaluate Packets When the List Includes Protocol-Independent and IP Firewall Filters

On a single interface associated with a protocol-independent (family any) firewall filter and a protocol-specific (family inet or family inet6) firewall filter simultaneously, the protocol-independent firewall filter executes first.

The terminating action of the first filter determines whether the second filter also evaluates the packet:

• If the first filter terminates by executing the accept action, the second filter doesn't evaluate the packet.

• If the first filter terminates without any terms matching the packet (an implicit discard action), the second filter also evaluates the packet.

• If the first filter terminates by executing an explicit discard action, the second filter does not evaluate the packet.