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.