Description

When using firewall flexible-match, up to 128 bit should be supported. However, what we can actually match on is limited to 32 bits for integers.

This article provides a workaround to support 128 bit match.

Symptoms

When configuring values larger than 32 bits, we encounter commit errors.

user@router# set firewall flexible-match source-ipv6-match bit-length ?

Possible completions:

<bit-length> Length of the data to be matched in bits, not needed for string input (1..128)

In version 17.3R3.9:

[edit]
user@router# set firewall flexible-match source-ipv6-match bit-length 120    

[edit]
user@router# commit check
re1:
commit-check failed
  commit-check failed
error: configuration check-out failed

In version 15.1F2-S10:

[edit]
user@router# set firewall flexible-match source-ipv6-match bit-length 120

[edit]
user@router# commit check
re0:
dfwc: bit-length can't be more than 32 for flex range match
error: configuration check-out failed

Solution

By design:

  • 32 bit matches are supported for integer or hexadecimal value. 
  • 128 bit matches are supported for string type matches like searching any pattern "html" in payload similar to DPI application.

The help string in the CLI was misleading and this was fixed through PR1389103 - firewall flexible match syntax clarification in later releases.

If we want to match for more than 32 bit, such as in an IP-IP tunneled situation where the address part is more than 32 bit, we can use a workaround to match it.

For example, if we need to match 16 Bytes, we know that one flex match takes 4 Byte string at a time. So if we have to match on 16 bytes then we need to create 4 terms each having one 4 Bytes range match along with action next-term, so that it can serially match on 16 byte pattern. However, we have to think of the scenario where packet may match any of the 4 terms. So we also need some type of cookie/token to make sure the final action (term 4) should only be executed if packet matches on all 4 terms. We need policy-map action to use it as a cookie here.

The sample config is given below.

     filter f6 {
        term 1 {
            from {
                flexible-match-range {
                    match-start layer-3;
                    byte-offset 24;  <-- Initial 4B IPV6 Dest address
                    bit-offset 0;
                    bit-length 32;
                    range 0x00000000-0x02000000;
                }
            }
            then {
                policy-map term1;  <-- Set policy map to indicate packet do hit term1
                count c1;
                next term;  <-- Move to next term
            }
        }
        term 2 {
            from {
                flexible-match-range {
                    match-start layer-3;
                    byte-offset 28;  <-- Next 4B of IPV6 Dest address
                    bit-offset 0;
                    bit-length 32;
                    range 0x11000000-0x33000000;
                }
                policy-map term1;  <-- Match on policy of previous terms
            }
            then {
                policy-map term2;  <-- Set policy map to indicate packet do hit term2
                count c2;
                next term;
            }
        }
        term 3 {
            from {
                flexible-match-range {
                    match-start layer-3;
                    byte-offset 32;
                    bit-offset 0;
                    bit-length 32;
                    range 0x11000000-0x33000000;
                }
                policy-map [ term1 term2 ];  <-- Match on policy of previous terms
            }
            then {
                policy-map term3;  <-- Set policy map to indicate packet do hit term3
                count c2;
                next term;
            }
        }
    }
This example should be changed and validated according to user's configuration and requirements.

Those corresponding configuration for policy-map term1, term2, and term3..etc are required to be defined under [class-of-service] hierarchy for completion. Otherwise the commit will fail. Policy-map is used to assign the rewrite rules, mainly to change the COS code-point of packets, which requires extra care when deciding the policy-map for the use of the above filter. The general suggestion for using firewall filter flexible-match is mostly for troubleshooting purposes, hence the use is temporal, not a permanent deployment. The code-point of packets being changed by this setup can be removed after the troubleshooting finishes.
 

Modification History

2024-09-25: Adding reminder of configuring policy-map in the solution field