Stateless Firewall Filter Components
This topic covers the following information:
Protocol Family
Under the firewall
statement, you can specify the
protocol family for which you want to filter traffic.
Table 1 describes the firewall filter protocol families.
Type of Traffic to Be Filtered |
Configuration Statement |
Comments |
---|---|---|
Protocol Independent |
|
All protocol families configured on a logical interface. |
Internet Protocol version 4 (IPv4) |
|
The |
Internet Protocol version 6 (IPv6) |
|
|
MPLS |
|
|
MPLS-tagged IPv4 |
|
Supports matching on IP addresses and ports, up to five MPLS stacked labels. |
MPLS-tagged IPv6 |
|
Supports matching on IP addresses and ports, up to five MPLS stacked labels. |
Virtual private LAN service (VPLS) |
|
|
Layer 2 Circuit Cross-Connection |
|
|
Layer 2 Bridging |
|
MX Series routers and EX Series switches only. |
Filter Type
Under the family family-name
statement, you can specify the type and name of the filter you want
to configure.
Table 2 describes the firewall filter types.
Filter Type |
Configuration Statement |
Description |
---|---|---|
Standard Firewall Filter |
|
Filters the following traffic types:
|
Service Filter |
|
Defines packet-filtering to be applied to ingress or egress before it is accepted for service processing or applied to returning service traffic after service processing has completed. Filters the following traffic types:
Supported at logical interfaces configured on the following hardware only:
|
Simple Filter |
|
Defines packet filtering to be applied to ingress traffic only. Filters the following traffic type:
Supported at logical interfaces configured on the following hardware only:
|
Terms
Under the filter
, service-filter
, or simple-filter
statement, you must configure at least one firewall
filter term. A term is a named structure in which
match conditions and actions are defined. Within a firewall filter,
you must configure a unique name for each term.
For each protocol family on an interface, you can apply no more than one filter in each direction. If you try to apply additional filters for the same protocol family in the same direction, the last filter overwrites the previous filter. You can, however, apply filters from the same protocol family to the input and output direction of the same interface.
All stateless firewall filters contain one or more terms, and each term consists of two components—match conditions and actions. The match conditions define the values or fields that the packet must contain to be considered a match. If a packet is a match, the corresponding action is taken. By default, a packet that does not match a firewall filter is discarded.
If a packet arrives on an interface for which no firewall filter is applied for the incoming traffic on that interface, the packet is accepted by default.
A firewall filter with a large number of terms can adversely affect both the configuration commit time and the performance of the Routing Engine.
Additionally, you can configure a stateless firewall filter within the term of another filter. This method enables you to add common terms to multiple filters without having to modify all filter definitions. You can configure one filter with the desired common terms, and configure this filter as a term in other filters. Consequently, to make a change in these common terms, you need to modify only one filter that contains the common terms, instead of multiple filters.
Match Conditions
A firewall filter term must contain at least one packet-filtering criteria, called a match condition, to specify the field or value that a packet must contain in order to be considered a match for the firewall filter term. For a match to occur, the packet must match all the conditions in the term. If a packet matches a firewall filter term, the router (or switch) takes the configured action on the packet.
If a firewall filter term contains multiple match conditions, a packet must meet all match conditions to be considered a match for the firewall filter term.
If a single match condition is configured with multiple values, such as a range of values, a packet must match only one of the values to be considered a match for the firewall filter term.
The scope of match conditions you can specify in a firewall filter term depends on the protocol family under which the firewall filter is configured. You can define various match conditions, including the IP source address field, IP destination address field, TCP or UDP source port field, IP protocol field, Internet Control Message Protocol (ICMP) packet type, IP options, TCP flags, incoming logical or physical interface, and outgoing logical or physical interface. These are pre-defined, or fixed, match conditions.
On MX Series 3D Universal Edge Routers with MPCs or MICs, it is possible to build flexible match conditions for IPv4, IPv6, Layer 2 bridge, CCC, and VPLS protocol families. These flexible match conditions allow a user to specify start location, byte offset, match length, and other parameters within the packet.
Each protocol family supports a different set of match conditions, and some match conditions are supported only on certain routing devices. For example, a number of match conditions for VPLS traffic are supported only on the MX Series 3D Universal Edge Routers.
In the from
statement in a firewall filter term,
you specify characteristics that the packet must have for the action
in the subsequent then
statement to be performed. The characteristics
are referred to as match conditions. The packet
must match all conditions in the from
statement for the
action to be performed, which also means that the order of the conditions
in the from
statement is not important.
If an individual match condition can specify a list of values (such as multiple source and destination addresses) or a range of numeric values, a match occurs if any of the values matches the packet.
If a filter term does not specify match conditions, the
term accepts all packets and the actions specified in the term’s then
statement are optional.
Some of the numeric range and bit-field match conditions allow you to specify a text synonym. For a complete list of synonyms:
If you are using the J-Web interface, select the synonym from the appropriate list.
If you are using the CLI, type a question mark (
?
) after thefrom
statement.
Actions
The actions specified in a firewall filter term define the actions to take for any packet that matches the conditions specified in the term.
Actions that are configured within a single term are all taken on traffic that matches the conditions configured.
We strongly recommend that you explicitly configure one or more actions per firewall filter term. Any packet that matches all the conditions of the term is automatically accepted unless the term specifies other or additional actions.
Firewall filter actions fall into the following categories:
Filter-Terminating Actions
A filter-terminating action halts all evaluation of a firewall filter for a specific packet. The router (or switch) performs the specified action, and no additional terms are examined.
Nonterminating Actions
Nonterminating actions are used to perform other functions on a packet, such as incrementing a counter, logging information about the packet header, sampling the packet data, or sending information to a remote host using the system log functionality.
The presence of a nonterminating action, such as count
, log
, or syslog
, without an explicit terminating
action, such as accept
, discard
, or reject
, results in a default terminating action of accept
. If
you do not want the firewall filter action to terminate, use the next term
action after the nonterminating action.
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.
In this example, term 2 is never evaluated, because term 1 has
the implicit default accept
terminating action.
[edit firewall filter test] term 1 { from { source-address { 0.0.0.0/0; } } then { log; <accept> #By default if not specified } } term 2 { then { reject; } }
In this example, term 2 is evaluated, because term 1 has the
explicit next term
flow control action.
[edit firewall filter test] term 1 { from { source-address { 0.0.0.0/0; } } then { log; next term; } } term 2 { then { reject; } }
Flow Control Action
For standard stateless firewall filters only, the action next term
enables the router (or switch) to perform configured
actions on the packet and then evaluate the following term in the
filter, rather than terminating the filter.
A maximum of 1024 next term
actions are supported
per standard stateless firewall filter configuration. If you configure
a standard filter that exceeds this limit, your candidate configuration
results in a commit error.