Page MenuHomeVyOS Platform

nftables: Add ability to use maps in VyOS
Open, NormalPublicFEATURE REQUEST

Description

NOTE: I looked for an existing feature request for this, but couldn't find anything. Sorry if this is a duplicate.

Summary

Using maps in nftables can radically reduce the processing of rules in a large ruleset, since lookups are done against a hashmap, instead of sequentially.

Use case

These would be created under the global firewall configuration, similar to how sets are defined. They can even be moved under the groups section if that makes more sense.

Additional information

Proposed Configuration:

The parameters of the map would need to be defined. These would then need to match in a rule. Values outside of the defined parameters would trigger an error. Any parameters not defined in the set would be assumed to be match all (unless a value doesn't support a match-all function or wildcard).

Define the parameters:

set firewall ipv4-map my_map parameters source-address
set firewall ipv4-map my_map parameters destination-address
set firewall ipv4-map my_map parameters destination-port
set firewall ipv4-map my_map parameters protocol

Create the rules:

set firewall ipv4-map my_map rule 10 action accept
set firewall ipv4-map my_map rule 10 description "Some description"
set firewall ipv4-map my_map rule 10 source-address 10.0.0.0/24
set firewall ipv4-map my_map rule 10 destination-address 10.0.1.0/24
set firewall ipv4-map my_map rule 10 destination-port 443
set firewall ipv4-map my_map rule 10 protocol tcp
					  
set firewall ipv4-map my_map rule 20 action accept
set firewall ipv4-map my_map rule 20 description "Some description"
set firewall ipv4-map my_map rule 20 source-address 10.0.2.0/24
set firewall ipv4-map my_map rule 20 destination-address 10.0.3.0/24
set firewall ipv4-map my_map rule 20 destination-port 22
set firewall ipv4-map my_map rule 20 protocol tcp
# You can see that this rule doesn't have the source-address parameter defined, which would map to 0.0.0.0/0 when applied to nft

set firewall ipv4-map my_map rule 30 action accept
set firewall ipv4-map my_map rule 30 description "Some description"
set firewall ipv4-map my_map rule 30 destination-address 10.0.5.0/24
set firewall ipv4-map my_map rule 30 destination-port 179
set firewall ipv4-map my_map rule 30 protocol tcp
# This rule tries to define a source-port, which was not defined in the parameters, so it would throw an error upon commit:

set firewall ipv4-map my_map rule 40 action accept
set firewall ipv4-map my_map rule 40 description "Some description"
set firewall ipv4-map my_map rule 40 source-port 12345
set firewall ipv4-map my_map rule 40 destination-address 10.0.5.0/24
set firewall ipv4-map my_map rule 40 destination-port 179
set firewall ipv4-map my_map rule 40 protocol tcp

  Error: source-port not within defined parameters

Apply to a firewall rule:

You would then apply the map to a rule in your normal firewall chains:

set firewall ipv4 output filter rule 10 ipv4-map my_map

Generated nftables config:

This would generate the following configuration elements within nft:

table ip vyos_filter {
        map my_map {
                type ipv4_addr . ipv4_addr . inet_service . inet_proto : verdict
                flags interval
                counter
                elements = { 10.0.0.0/24 . 10.0.1.0/24 . 443 . tcp counter packets 0 bytes 0 : accept,
                             10.0.2.0/24 . 10.0.3.0/24 . 22 . tcp counter packets 0 bytes 0 : accept,
                             0.0.0.0/0 . 10.0.5.0/24 . 179 . tcp counter packets 170 bytes 10200 : accept }
        }

        chain VYOS_OUTPUT_filter {
                type filter hook output priority filter; policy accept;
                ip saddr . ip daddr . tcp dport . ip protocol vmap @my_map counter packets 0 bytes 0
                counter packets 10582 bytes 1379357 accept comment "OUT-filter default-action accept"
        }
}

Limitations:

When using maps, you can't use logging. When having a large enough firewall config to need maps, logging everything is not really all that beneficial, since you're likely just logging denies.

Details

Version
-
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Feature (new functionality)