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{ # handle 29
type ipv4_addr . ipv4_addr . inet_service . inet_proto : verdict
flags interval
elements = { 10.0.0.0/24 . 10.0.1.0/24 . 443 . tcp : accept,
10.0.2.0/24 . 10.0.3.0/24 . 22 . tcp : accept,
0.0.0.0/0 . 10.0.5.0/24 . 179 . tcp : 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 counters or logging. When having a large enough firewall config to need maps, logging and counters are not really all that beneficial, since you're likely just logging denies, and will have something like netflow to validate traffic.