Summary

Add support for nftables concatenations in VyOS firewall groups.

nftables supports concatenated set keys, where multiple packet fields are combined and matched as a single value. This allows a set to contain specific combinations of values rather than matching each field independently.

The proposed VyOS implementation calls these flow groups, with separate group types for IPv4 and IPv6:

firewall group ipv4-flow-group <name>
firewall group ipv6-flow-group <name>

A flow group would define which packet fields form the concatenation using parameter nodes. Individual entries in the set would then be defined using match nodes.

For example:

set firewall group ipv4-flow-group WEB parameter ipv4-source-address
set firewall group ipv4-flow-group WEB parameter destination-port

set firewall group ipv4-flow-group WEB match office ipv4-source-address 192.0.2.10
set firewall group ipv4-flow-group WEB match office destination-port 443

set firewall group ipv4-flow-group WEB match guest ipv4-source-address 198.51.100.10
set firewall group ipv4-flow-group WEB match guest destination-port 8443

This could generate an nftables set similar to:

type ipv4_addr . inet_service
elements = {
    192.0.2.10 . 443,
    198.51.100.10 . 8443
}

Use case

nftables concatenations allow relationships between multiple packet attributes to be represented efficiently in a single set.

Current VyOS firewall groups contain individual values. When multiple independent groups or match criteria are used, each criterion is evaluated independently. This cannot represent a specific relationship between values without creating additional rules.

For example, consider two source addresses:

192.0.2.10
198.51.100.10

and two destination ports:

443
8443

Independent source-address and port groups match every possible combination of those values. They cannot express that only these specific combinations should match:

192.0.2.10 . 443
198.51.100.10 . 8443

nftables concatenated sets are specifically designed to represent this type of relationship.

This becomes increasingly useful as more fields are included. Potential flow-group parameters include:

inbound-interface
outbound-interface
ipv4-source-address
ipv4-destination-address
ipv6-source-address
ipv6-destination-address
source-port
destination-port
protocol
mark
icmp-type
icmp-code
icmpv6-type
icmpv6-code

This would allow VyOS to take advantage of nftables concatenations without requiring users to understand or directly configure nftables set datatypes and concatenation syntax.

Additional information

Proposed flow-group syntax

flow-group is the proposed user-facing name for the VyOS implementation of nftables concatenated sets.

IPv4 and IPv6 would use separate group types:

ipv4-flow-group
ipv6-flow-group

A group could look like:

ipv4-flow-group WEB {
    parameter ipv4-source-address
    parameter destination-port

    match office {
        ipv4-source-address 192.0.2.10
        destination-port 443
    }

    match guest {
        ipv4-source-address 198.51.100.10
        destination-port 8443
    }
}

parameter defines which fields are included in the nftables concatenation.

Each match represents one element of the resulting nftables set and must contain values corresponding to the configured parameters.

The match tagNode is only an identifier. It does not represent evaluation priority because nftables set elements are unordered. It could therefore allow both numeric and descriptive identifiers, for example:

match 10
match office
match guest-web

Concatenation limits

nftables limits the maximum size of a concatenated set key to 64 bytes. Since the size of a concatenated key depends on the datatypes used, the maximum number of supported parameters varies. For example, a traditional IPv6 5-tuple fits comfortably within the limit, while combinations including larger datatypes such as interface names may exceed it.

Rather than imposing a fixed parameter limit, VyOS could calculate the total key size during validation based on the configured parameters and present a descriptive error if the nftables limit would be exceeded.

For example:

Flow group key size is 66 bytes (maximum 64 bytes).

Parameter sizes:
  inbound-interface         16 bytes
  outbound-interface        16 bytes
  ipv6-source-address       16 bytes
  ipv6-destination-address  16 bytes
  destination-port           2 bytes

This provides users with enough information to understand which parameters contribute to the key size and how to modify the flow group to fit within the nftables limit.

If possible, it would also be useful to reference the upstream nftables issue documenting the concatenation key-size limitation.