Firewall Filter Flexible Match Conditions
Standard firewall filter match conditions vary based on the protocol family of the traffic being matched. For example, the terms available for bridge protocol traffic are different from those available for the inet or inet6 protocol families. The fields available for matching within each protocol family are, however, fixed or pre-defined. This means that filters can match on patterns within those pre-defined fields only.
Using flexible match conditions, firewall filters can be constructed that start the match at layer-2, layer-3, layer-4 or payload locations. From there, additional offset criteria can be specified thereby enabling pattern matches at custom, user-defined locations within a packet.
Flexible match filter terms are applied to MPC or MIC interfaces as either input or
output filters just as any other firewall filter terms. Flexible match filter terms can also
be created as templates at the [edit firewall] hierarchy level. These templates
can then be referenced within a flexible match term.
For MX series routers, flexible match conditions are only supported with MPCs or MICs. For environments where FPCs, PICs, and or DPCs are installed along with MPCs or MICs, be sure to only apply the flexible match firewall filter criteria to the MPC or MIC interfaces.
For MX Series routers with MPCs, you need to initialize the filter counter for Trio-only
match filters in the MIB by walking the corresponding SNMP MIB. For example, for any filter
that is configured or changed with respect to their Trio-only filters, you need to run a command
such as the following: show snmp mib walk (ascii | decimal) object-id. This forces Junos to learn the filter counters and ensure that the filter statistics are
displayed (this is because the first poll to filter statistics may not show all counters).
Trio-only match filters are those that include at least one match condition or action that
is only supported by the Trio chipset.
This guidance applies to all enhanced-mode firewall filters. It also applies to Firewall Filter Match Conditions for IPv4 Traffic with flexible
match filter terms for offset-range or offset-mask, gre-key, and Firewall Filter Match Conditions for IPv6 Traffic with any of the following match conditions: payload-protocol, extension
headers, is_fragment. It also applies to filters with either of the following Firewall Filter Terminating Actions: encapsulate or decapsulate, or either of the following Firewall Filter Nonterminating Actions: policy-map, and clear-policy-map.
Statement Hierarchy
Flexible match filter terms are available in three variations as shown in Table 1. The flexible-match variation is
configured at the [edit firewall] hierarchy level. It is used to define flexible
match templates. The flexible-filter-match-mask and flexible-match-range are configured at the [edit firewall family [inet|inet6|bridge|ethernet-switching|ccc|vpls]
filter <filter-name> term <term-name> from] hierarchy. Use the family ethernet-switching filter for EX9200 switches.
Flexible Filter Match Types
Flexible Filter Match Type |
Available Attributes |
Description |
|---|---|---|
|
|
Create a flexible-match template named as the <name> attribute. |
|
Length of the data to be matched in bits, not needed for string input (0..32) For QFX5120 and EX4650 switches, 16 and 32 are the only valid bit lengths. |
|
|
Bit offset after the (match-start + byte) offset (0..7) |
|
|
Byte offset after the match start point |
|
|
Start point to match in packet |
|
|
|
Length of the data to be matched in bits, not needed for string input (0..128) |
|
Bit offset after the (match-start + byte) offset (0..7) |
|
|
Byte offset after the match start point |
|
|
Select a flexible match from predefined template field. Required unless |
|
|
Mask out bits in the packet data to be matched. |
|
|
Start point to match in packet. Required unless |
|
|
Value data/string to be matched. |
|
|
|
Length of the data to be matched in bits. (0..32) Required unless |
|
Bit offset after the (match-start + byte) offset. (0..7) |
|
|
Byte offset after the match start point |
|
|
Select a flexible match from predefined template. |
|
|
Start point to match in packet. Required unless |
|
|
Range of values to be matched. |
|
|
Range of values to be not matched. |
Flexible Filter Match Start Locations
Flexible match filter terms are constructed by giving a start location or anchor point
within the packet. The start locations can be any of: layer-2, layer-3, layer-4 or payload,
depending on the protocol family in use. Table 2 shows available flexible filter match start locations by protocol family. You use
these available start locations as the match-start locations for the flexible match
filter terms.
From these start locations, specific byte and bit offsets can be utilized to allow the filter to match patterns at very specific locations within the packet.
Protocol Family |
Available Start Locations |
|---|---|
|
For QFX5120 and EX4650 switches, support for layer-2 and layer-3 (only) flexible match filters was added in Junos Release 20.1R1. |
|
For QFX5120 and EX4650 switches, support for layer-2 and layer-3 (only) flexible match filters was added in Junos Release 20.1R1. |
|
|
|
|
|
|
|
|
|
(EX9200 switches) For, QFX5120 and EX4650 switches, support for layer-2 and layer-3 (only) flexible match filters was added in Junos Release 20.1R1. An example of using a layer-2 packet offset and match length can be found below. |
Flexible Filter Match Examples
The following example illustrates the use and context for flexible-match-mask.
from {
flexible-match-mask {
flexible-mask-name <mask-name>;
mask-in-hex <mask>;
prefix <pattern>;
}
}The <mask-name> specifies for flexible-mask-name which predefined template is used for the flexible match condition. Templates can be defined to specify at which place (position) in the packet the flexible match condition should be executed.
The <mask> for mask-in-hex is in hexadecimal
format. For example, a configured mask of 0xf0fc specifies a match
for the fist four bits in first byte (as referred by <mask-name>),
and for the first six bits in the second byte. If the packet is IPv4 packet, and <mask-name> refers to first two bytes in L3 header, the search is for the IP
version field and DSCP field. As another example, a configured mask 0xffc0 specifies a search for entire first byte and for two bits from the second byte. If the <mask-name> refers to first two bytes in L3 header, and the packet is IPv6
packet, this specifies the IP version field and DSCP in the Traffic Class field.
The <pattern> specified for prefix is an
ASCII string. If first two characters are 0x, then the string is
processed as a hexadecimal number encoding appropriate bits. For example, the configured prefix 0x40c0 in combination with mask 0xf0fc and <mask-name> referring first two bytes in L3 header, indicates a search for 0100 in the first four bits (version field is equal to 4) and 1100 00 in IPv4 DSCP field (DSCP is equal to cs6). Or, using the configured
prefix 0x6c00 in combination with mask 0xffc0 and <mask-name> referring first two bytes in L3 header, specifies
a search for for 0110 in the first four bits (version field is
equal to 6), and 1100 00 in IPv6 DSCP field (DSCP is equal to cs6).
The first example defines a mask template that selects first two bytes (16 bits) from L3 header for flexible match:
firewall {
flexible-match FM-FIRST-TWO-L3-BYTES {
match-start layer-3;
byte-offset 0;
bit-offset 0;
bit-length 16;
}
}The next example defines a mask template that selects the third through sixth byte (32 bits) of the packet payload for flexible match:
firewall {
flexible-match FM-FOUR-PAYLOAD-BYTES {
match-start payload;
byte-offset 2;
bit-offset 0;
bit-length 32;
}
}This example shows an ASCII character match for the string JNPR (ASCII characters: 0x4a, 0x4e, 0x50, 0x52) in the third through sixth byte of the
packet payload. The filter uses the FM-FOUR-PAYLOAD-BYTES mask
template defined in the previous example.
firewall {
family ccc filter FF-COUNT-JNPR-PACKETS {
term JNPR-STRING {
from {
flexible-match-mask {
mask-in-hex 0xffffffff;
prefix JNPR;
flexible-mask-name FM-FOUR-PAYLOAD-BYTES;
}
}
then {
count CNT-JNPR-YES
accept;
}
}
term DEAFULT {
then {
count CNT-JNPR-NO
accept;
}
}
}
}This example shows a family ccc filter looking for DSCP equal to cs6 and DSCP ef, regardless whether the encapsulated packets are
IPv4 or IPv6. It uses the the FM-FIRST-TWO-L3-BYTES mask template
defined in the first example.
firewall {
family ccc filter FF-DSCP-CLASSIFY {
term ROUTING-IPV4 {
from {
flexible-match-mask {
mask-in-hex 0xf0fc;
prefix 0x40c0; # DSCP=cs6 in IPv4 header
flexible-mask-name FM-FIRST-TWO-L3-BYTES;
}
}
then {
count ROUTING-IPV4;
accept;
}
}
term ROUTING-IPV6 {
from {
flexible-match-mask {
mask-in-hex 0xffc0;
prefix 0x6c00; # DSCP=cs6 in IPv6 header
flexible-mask-name FM-FIRST-TWO-L3-BYTES;
}
}
then {
count ROUTING-IPV6;
accept;
}
}
term VOICE-IPV4 {
from {
flexible-match-mask {
mask-in-hex 0xf0fc;
prefix 0x40b8; # DSCP=ef in IPv4 header
flexible-mask-name FM-FIRST-TWO-L3-BYTES;
}
}
then {
count VOICE-IPV4;
accept;
}
}
term VOICE-IPV6 {
from {
flexible-match-mask {
mask-in-hex 0xffc0;
prefix 0x6b80; # DSCP=ef in IPv6 header
flexible-mask-name FM-FIRST-TWO-L3-BYTES;
}
}
then {
count VOICE-IPV6;
accept;
}
}
term DEFAULT {
then {
accept;
}
}
}
}This example shows how to use a match length, starting from a layer-2 packet offset,
in a firewall filter for a QFX5120-32C, QFX5120-48Y, or EX4650 device running Junos Release
20.1R1. Here, we use a bit-length of 32 bits and the ethernet-switching family
(inet and inet6 are also supported, as is using a layer-3 offset).
user@device# show firewall family ethernet-switching
filter udf_eth {
term t1 {
from {
flexible-match-mask {
match-start layer-2;
byte-offset 8;
bit-length 32;
prefix 168430090;
}
}
then count c1;
}
}