Understanding Firewall Filter Match Conditions

Filter Match Conditions

In the from statement of a firewall filter term, you specify the packet conditions that trigger the action in one of the then statements: then with various options, then interface or then vlan. All conditions in the from statement must match for the action to be taken. The order in which you specify match conditions is not important, because a packet must match all the conditions in a term for a match to occur.

If you specify no match conditions in a term, that term matches all packets.

An individual condition in a from statement cannot contain a list of values. For example, you cannot specify numeric ranges or multiple source or destination addresses.

Individual conditions in a from statement cannot be negated. A negated condition is an explicit mismatch.

Numeric Filter Match Conditions

Numeric filter conditions match packet fields that are identified by a numeric value, such as port and protocol numbers. For numeric filter match conditions, you specify a keyword that identifies the condition and a single value that a field in a packet must match.

You can specify the numeric value in one of the following ways:

• Single number—A match occurs if the value of the field matches the number. For example:

• Text synonym for a single number— A match occurs if the value of the field matches the number that corresponds to the synonym. For example:

To specify more than one value in a filter term, you enter each value in its own match statement, which is a string that defines a match condition. For example, a match occurs in the following term if the value of vlan is 10 or 30.

The following restrictions apply to numeric filter match conditions:

• You cannot specify a range of values.

• You cannot specify a list of comma-separated values.

• You cannot exclude a specific value in a numeric filter match condition. For example, you cannot specify a condition that would match only if the match condition was not equal to a given value.

Interface Filter Match Conditions

Interface filter match conditions can match interface name values in a packet. For interface filter match conditions, you specify the name of the interface, for example:

Port and VLAN interfaces do not use logical unit numbers. However, a firewall filter that is applied to a router interface can specify the logical unit number in the interface filter match condition, for example:

You can include the * wildcard as part of the interface name, for example:

IP Address Filter Match Conditions

Address filter match conditions can match prefix values in a packet, such as IP source and destination prefixes. For address filter match conditions, you specify a keyword that identifies the field and one prefix of that type that a packet must match.

You specify the address as a single prefix. A match occurs if the value of the field matches the prefix. For example:

Each prefix contains an implicit 0/0 except statement, which means that any prefix that does not match the prefix that is specified is explicitly considered not to match.

To specify the address prefix, use the notation prefix/prefix-length. If you omit prefix-length, it defaults to /32. For example:

To specify more than one IP address in a filter term, you enter each address in its own match statement. For example, a match occurs in the following term if the value of the source-address field matches either of the following source-address prefixes:

MAC Address Filter Match Conditions

MAC address filter match conditions can match source and destination MAC address values in a packet. For MAC address filter match conditions, you specify a keyword that identifies the field and one value of that type that a packet must match.

You can specify the MAC address as six hexadecimal bytes in the following formats:

To specify more than one MAC address in a filter term, you enter each MAC address in its own match statement. For example, a match occurs in the following term if the value of the source-mac-address field matches either of the following addresses.

Bit-Field Filter Match Conditions

Bit-field filter conditions match packet fields if particular bits in those fields are or are not set. You can match the IP options, TCP flags, and IP fragmentation fields. For bit-field filter match conditions, you specify a keyword that identifies the field and tests to determine that the option is present in the field.

To specify the bit-field value to match, enclose the value in double quotation marks. For example, a match occurs if the RST bit in the TCP flags field is set:

Typically, you specify the bits to be tested by using keywords. Bit-field match keywords always map to a single bit value. You also can specify bit fields as hexadecimal or decimal numbers.

To match multiple bit-field values, use the logical operators, which are described in Table 1. The operators are listed in order from highest precedence to lowest precedence. Operations are left-associative.

Table 1: Logical Operators for Matching Multiple Bit-Field Operators

Logical Operators	Description
!	Negation.
&	Logical AND.
|	Logical OR.

To negate a match, precede the value with an exclamation point. For example, a match occurs only if the RST bit in the TCP flags field is not set:

In the following example of a logical AND operation, a match occurs if the packet is the initial packet on a TCP session:

In the following example of a logical OR operation, a match occurs if the packet is part of TCP session establishment or tear down:

For a logical OR operation, you can specify a maximum of two match conditions in a single term. If you need to match more than two bit-field values in a logical OR operation, configure the same match condition in consecutive terms with additional bit-field values. In the following example, the two terms configured match the SYN, ACK, FIN, or RST bit in the TCP flags field:

You can use text synonyms to specify some common bit-field matches. You specify these matches as a single keyword. In the following example of a text synonym, a match occurs if the packet is the initial packet on a TCP session:

Limitation of firewall filter address match condition

In specific cases, addition of a prefix to a prefix list can cause route summarization by the compiler which could result in a traffic loss to a prefix. The following example describes this specific corner case.

Initial configuration

In this initial configuration, the prefix-list ES-L2TP-TPOINTS-ALLOW is configured with two prefixes. A firewall filter is configured to match addresses in this prefix-list.

The following is the compiler output for the firewall.

Now with the above config the only allowed address will be 100.64.11.8 to 100.64.11.15 and 100.64.11.16 to 100.64.11.23 or 100.64.11.8 to 100.64.11.23. Any one address, either source or destination if it is in range of 100.64.11.8 to 100.64.11.23 will be allowed. As an example, source address 100.64.11.15 is within the allowed range, so ping works.

Configuration with prefix added to prefix-list

Initial configuration works, but in this case when a prefix such as 100.64.11.0/29 is added to the prefix-list, a corner case is noticed.

Compiler output of the firewall

As can be noticed from compiler output, the allowed address will be from 100.64.11.0 to 100.64.11.23. but here the firewall compiler optimizes it in better way by having allowed limit to 100.64.11.0/27 which will allow from 100.64.11.0 to 100.64.11.32 , so it added denied prefix from 100.64.11.24 to 00.64.11.32. So, in the initial configuration if ping worked, this time it doesn’t.

It is because even though source 100.64.11.15 is accepted but traffic gets dropped as destination address 100.64.11.24 is in denied list. Match with allowed and denied list is an AND operation which means traffic will only be allowed if it passes both allowed and denied list. It also implies that for address match to work both source address and destination address should not be in denied list.