http://wiki.nftables.org/wiki-nftables/api.php?action=feedcontributions&user=Jeff.welling&feedformat=atomnftables wiki - User contributions [en]2024-03-28T14:42:38ZUser contributionsMediaWiki 1.36.4http://wiki.nftables.org/wiki-nftables/index.php?title=User_talk:Jeff.welling&diff=289User talk:Jeff.welling2018-03-06T06:07:37Z<p>Jeff.welling: Blanked the page</p>
<hr />
<div></div>Jeff.wellinghttp://wiki.nftables.org/wiki-nftables/index.php?title=Configuring_tables&diff=264Configuring tables2018-01-27T06:53:37Z<p>Jeff.welling: Note about flush ruleset vs flush table</p>
<hr />
<div>= Adding tables =<br />
<br />
<source lang="bash"><br />
% nft add table ip filter<br />
</source><br />
<br />
= Show/List tables =<br />
<br />
<source lang="bash"><br />
% nft list tables<br />
</source><br />
<br />
= Deleting tables =<br />
<br />
<source lang="bash"><br />
% nft delete table ip foo<br />
</source><br />
<br />
'''Troubleshooting''': Since Linux kernel 3.18, you can delete tables and its content with this command. However, before that version, you need to delete its content first, otherwise you hit an error that look like this:<br />
<br />
<source lang="bash"><br />
% nft delete table filter<br />
<cmdline>:1:1-19: Error: Could not delete table: Device or resource busy<br />
delete table filter<br />
^^^^^^^^^^^^^^^^^^^<br />
</source><br />
<br />
= Flushing tables =<br />
<br />
You can delete all the rules that belong to this table with the following command:<br />
<br />
<source lang="bash"><br />
% nft flush table ip filter<br />
</source><br />
<br />
This removes the rules ''for every chain'' that you register in that table.<br />
<br />
'''Note:''' ''nft flush table ip filter'' will not flush '''Sets''' defined within that table, and will cause an error if the table to be flushed does not exist and you're using Linux <4.9.0, which you can overcome by flushing the ruleset.<br />
<br />
==== Flush Ruleset ====<br />
<br />
Flush your whole configuration, tables sets and all:<br />
<br />
<source lang="bash"><br />
% nft flush ruleset<br />
</source></div>Jeff.wellinghttp://wiki.nftables.org/wiki-nftables/index.php?title=Advanced_ruleset_for_dynamic_environments&diff=263Advanced ruleset for dynamic environments2018-01-27T00:32:36Z<p>Jeff.welling: Figured out and documented kernel versions for table creation implicit vs explicit</p>
<hr />
<div>'''This page is an unvetted draft'''<br />
<br />
Today's modern computing environments require features like Service Discovery and the environments themselves can be quite dynamic and rapidly changing. One of the ways nftables can help is by breaking firewall config into small pieces which can by dynamically generated by the likes of [https://www.consul.io/ Consul] and [https://www.hashicorp.com/blog/introducing-consul-template Consul Template], [https://www.vaultproject.io/ Vault], or config management like [https://www.chef.io/solutions/infrastructure-automation/ Chef] [https://puppet.com/ Puppet] or [https://www.ansible.com/ Ansible].<br />
<br />
An example use case would be if you had a number of servers, and you detected traffic on one host that you'd like to block across your entire fleet. You could add the IP to block into Consul, which will propagate it out and then Consul Template on each hosts updates nftables blacklist set definition with the new blacklisted IP and reloads nftables. Alternatively if you don't trust Consul due to the lack of an execution guarantee, you could put the blocked IP in an Ansible var and deploy it everywhere through your configuration management system. <br />
<br />
By default your Systemd service file likely lives in ''/lib/systemd/system/'', the values suggested on this page are not default so you may wish to change those values. If you do, it's [https://unix.stackexchange.com/questions/206315/what-is-difference-between-usr-lib-and-etc-systemd best practice] to copy the nftables.service file to ''/etc/systemd/system'' where it will override the system-provided version without the need to modify files provided by the package.<br />
<br />
There's nothing wrong with using a different layout, or even having everything in one file. This author prefers to split out rules and sets into individual files so that grouping them together by application or purpose is easier, you can use any configuration structure you wish.<br />
<br />
'''''TODO:''''' Is ''/etc/nftables.start.conf'' really necessary? In a Debian test system on Linux 4.9.0, Debian Stretch, Nftables version v0.7, this file is not necessary - table creation is implicit from the table definition, for both 'inet' and 'ip' table types. This differs from my tests on the system I've lost access to at the moment, this needs to be explored once the host is reset. Note version numbers if the behaviour changed. <br />
<br />
<br />
'''/etc/nftables.start.conf'''<br />
<br />
Creates tables<br />
<br />
Loads ''/etc/nftables.conf''<br />
<br />
Called from Systemd service file for nftables in ''ExecStart=''<br />
<br />
The table creation statements are kept intentionally separate in this example so that its compatible with both config file formats. With the nftables-output config format, table creation statements cannot be used after the table is already created or an error is thrown, aborting the config reload. <br />
<br />
'''Note:''' If you use Debian Stretch or a newer kernel (Linux Kernel >=4.9.0), this isn't necessary - the table creation will be handled implicitly so you can just add a 'flush ruleset' to ''/etc/nftables.conf'', update ''/etc/systemd/system/nftables.service'' so ''ExecStart='' points to ''/etc/nftables.conf'', and delete ''/etc/nftables.start.conf''.<br />
<br />
Example contents of ''/etc/nft.conf.d/nftables.start.conf'':<br />
<br />
<source lang="bash"><br />
create table ip filter<br />
create table ip nat<br />
include "/etc/nftables.conf"<br />
</source><br />
<br />
<br />
'''/etc/nftables.conf'''<br />
<br />
Loads table-specific entries like ''/etc/nft.conf.d/nftables.ip.filter.conf'' and ''/etc/nft.conf.d/nftables.ip.nat.conf''<br />
<br />
Loads Sets main file ''/etc/nft.conf.d/sets.d/main.conf''<br />
<br />
Called from Systemd service file for nftables in ''ExecReload=''<br />
<br />
Example content of ''/etc/nftables.conf'':<br />
<br />
<source lang="bash"><br />
include "/etc/nft.conf.d/sets.d/main.conf"<br />
include "/etc/nft.conf.d/nftables.ip.filter.conf"<br />
include "/etc/nft.conf.d/nftables.ip.nat.conf"<br />
include "/etc/nft.conf.d/nftables.test1.conf"<br />
include "/etc/nft.conf.d/nftables.test2.conf"<br />
</source><br />
<br />
<br />
'''/etc/nft.conf.d/sets.d/main.conf'''<br />
<br />
Loads each individual Set, because nftables doesn't support wildcards in ''include'' statements (yet?)<br />
<br />
Called only from the include in ''/etc/nftables.conf''<br />
<br />
Example content of ''/etc/nft.conf.d/sets.d/main.conf'':<br />
<br />
<source lang="bash"><br />
include "/etc/nft.conf.d/sets.d/trusted_ips1.conf"<br />
include "/etc/nft.conf.d/sets.d/trusted_ips2.conf"<br />
include "/etc/nft.conf.d/sets.d/family_ips.conf"<br />
</source><br />
<br />
Example of an included set ''/etc/nft.conf.d/sets.d/trusted_ips1.conf'':<br />
<br />
<source lang="bash"><br />
table ip filter {<br />
set trusted_ips {<br />
type ipv4_addr<br />
elements = { 192.168.1.1}<br />
}<br />
}<br />
</source><br />
<br />
Example of included set ''/etc/nft.conf.d/sets.d/trusted_ips2.conf'':<br />
<br />
<source lang="bash"><br />
table ip filter {<br />
set trusted_ips {<br />
type ipv4_addr<br />
elements = { 192.168.2.2}<br />
}<br />
}<br />
</source><br />
<br />
Example of included set ''/etc/nft.conf.d/sets.d/family_ips.conf'':<br />
<br />
<source lang="bash"><br />
table ip filter {<br />
set family_ips {<br />
type ipv4_addr<br />
elements = { 192.168.3.3}<br />
}<br />
}<br />
</source><br />
<br />
Example of how the configuration is combined:<br />
<br />
<source lang="bash"><br />
% nft list table ip filter<br />
table ip filter {<br />
set trusted_ips {<br />
type ipv4_addr<br />
elements = { 192.168.2.2, 192.168.1.1}<br />
}<br />
set family_ips {<br />
type ipv4_addr<br />
elements = { 192.168.3.3}<br />
}<br />
}<br />
</source><br />
<br />
<br />
'''/etc/nft.conf.d/nftables.ip.filter.conf'''<br />
<br />
Configures the 'ip filter' table<br />
<br />
Called from ''/etc/nftables.conf''<br />
<br />
Example content:<br />
<br />
<source lang="bash"><br />
flush table ip filter<br />
table ip filter {<br />
set trusted_ips {<br />
type ipv4_addr<br />
elements = { 192.168.2.2, 192.168.1.1}<br />
}<br />
<br />
chain input {<br />
#This is required to get input traffic to process this chain<br />
type filter hook input priority 0; policy drop;<br />
<br />
#Accept all traffic from the LAN, and any traffic related to already-active connections<br />
ip saddr 192.168.1.0/24 counter packets 0 bytes 0 accept<br />
ct state established,related counter packets 6471 bytes 337740 accept<br />
<br />
#Accept SSH connections from everywhere, not just the LAN<br />
tcp dport ssh counter packets 0 bytes 0 accept<br />
<br />
#We want logs of the drops. If you don't, remove this line.<br />
log prefix "nft-input-drop " level debug counter packets 112 bytes 8404 drop<br />
}<br />
<br />
chain output {<br />
#This is required to get output traffic to process this chain<br />
type filter hook output priority 0; policy drop;<br />
<br />
#Accept all outbound traffic <br />
oif "eth1" counter packets 0 bytes 0 accept<br />
<br />
#We want logs of the drops. If you don't, remove this line.<br />
log prefix "nft-output-drop " level debug counter packets 0 bytes 0 drop<br />
}<br />
<br />
chain forward {<br />
#This is required to get forward traffic to process this chain<br />
type filter hook forward priority 0; policy drop;<br />
<br />
#We want logs of the drops. If you don't, remove this line.<br />
log prefix "nft-forward-drop " level debug counter packets 104 bytes 4910 drop<br />
}<br />
}<br />
</source><br />
<br />
<br />
'''/etc/nft.conf.d/nftables.ip.nat.conf'''<br />
<br />
Configures the 'ip nat' table<br />
<br />
Called from ''/etc/nftables.conf''<br />
<br />
Example contents of ''/etc/nft.conf.d/nftables.ip.nat.conf'':<br />
<br />
<source lang="bash"><br />
flush table nat<br />
table ip nat {<br />
chain prerouting {<br />
type filter hook prerouting priority 0<br />
}<br />
chain postrouting {<br />
type filter hook postrouting priority 100<br />
}<br />
}<br />
</source></div>Jeff.wellinghttp://wiki.nftables.org/wiki-nftables/index.php?title=Atomic_rule_replacement&diff=262Atomic rule replacement2018-01-27T00:24:42Z<p>Jeff.welling: Moar details about when table creation must be done manually</p>
<hr />
<div>== Warning about Shell scripting + nftables ==<br />
<br />
With iptables it was common to use a bash script comprised of multiple iptables commands to configure a firewall. This is sub-optimal because it is not atomic, that is to say that during the few fractions of a second that your bash script takes to run your firewall is in a partially configured state. Nftables introduces atomic rule replacement with the ''-f'' option. This is different from bash scripts because nftables will read in all of the included config files, create the config object in memory alongside the existing config, and then in one atomic operation it swaps the old config for the new one meaning there is no moment when the firewall is partially configured. <br />
<br />
== Atomic Rule Replacement ==<br />
<br />
You can use the ''-f'' option to atomically update your rule-set:<br />
<br />
<source lang="bash"><br />
% nft -f file<br />
</source><br />
<br />
Where ''file'' contains your rule-set.<br />
<br />
You can save your rule-set by storing the existing listing in a file, ie.<br />
<br />
<source lang="bash"><br />
% nft list table filter > filter-table<br />
</source><br />
<br />
Then you can restore it by using the ''-f'' option:<br />
<br />
<source lang="bash"><br />
% nft -f filter-table<br />
</source><br />
<br />
'''Notes:''' <br />
<br />
'''''Table Creation''''' - you may have to create the table with ''nft create table ip filter'' before you can load the file exported with ''nft list table filter > filter-table'' otherwise you will hit errors because the table does not exist. Table creation is implied in Debian Stretch and above, Debian Jessie (via backports) will require that you create the tables manually.<br />
<br />
'''''Comments''''' - You can also add comments to the ''filter-table'' file. Comments are bash style, starting with # and go to the end of the line.<br />
<br />
'''''Duplicate Rules''''' - If you prepend the ''flush table filter'' line at the very beginning of the ''filter-table'' file, you achieve atomic rule-set replacement equivalent to what ''iptables-restore'' provides. The kernel handles the rule commands in the file in one single transaction, so basically the flushing and the load of the new rules happens in one single shot. If you choose not to flush your tables then you will see duplicate rules for each time you reloaded the config.<br />
<br />
'''''Flushing Sets''''' - ''flush table filter'' will not flush any sets defined in that table. To flush sets as well, use ''flush ruleset'' (not available in Linux 3.16 or below) or delete the sets explicitly. Early versions (Linux <=3.16) do not allow you to import a set if it already exists, but this is allowed in later versions.<br />
<br />
'''''Nftables Config File Formats''''' - ''nft -f <filename>'' accepts 2 formats, the first is the format seen in the output of ''nft list table''. The second is [[Scripting]] and is the format you typically see on this website.<br />
<br />
Example of nftables output format:<br />
<br />
<source lang="bash"><br />
create table ip nat<br />
#flush table nat<br />
table ip nat {<br />
chain prerouting {<br />
type filter hook prerouting priority 0; policy accept;<br />
}<br />
<br />
chain postrouting {<br />
type filter hook postrouting priority 100; policy accept;<br />
}<br />
}<br />
</source><br />
<br />
Example of scripted config format:<br />
<br />
<source lang="bash"><br />
#!/usr/sbin/nft -f<br />
<br />
define ntp_servers = { 84.77.40.132, 176.31.53.99, 81.19.96.148, 138.100.62.8 }<br />
<br />
add table filter<br />
add chain filter input { type filter hook input priority 0; }<br />
add rule filter input ip saddr $ntp_servers counter<br />
</source><br />
<br />
'''Combining multiple files'''<br />
<br />
''What happens when you include 2 files which each have a statement for the filter table?''<br />
<br />
If you have two files, both ''include''d, both with statements for the filter table, but one adds a rule allowing traffic from 192.168.1.1 and the other allows traffic from 192.168.1.2 then both rules will be included in the chain, even if one or both files contains a flush statement.<br />
<br />
''What about flush statements in either, or neither file?''<br />
<br />
If there are any flush commands in any included file then those will be run at the moment the config swap is executed, not at the moment the file is loaded. If you do not include a flush statement in any included file, you will get duplicate rules. If you do include a flush statement, you will not get duplicate rules and the config from *both* files will be included. <br />
<br />
'''Converting between formats'''<br />
<br />
The easiest way to convert from scripted config format to output-based is to run the commands and then show the nftables config with ''nft list table ip filter'' and then copy/paste that into your config file.<br />
The easiest way to convert from output-based to scripted based is to lookup the equivalent on this wiki.</div>Jeff.wellinghttp://wiki.nftables.org/wiki-nftables/index.php?title=Nftables_and_Iptables&diff=261Nftables and Iptables2018-01-27T00:17:05Z<p>Jeff.welling: Merged info but can't figure out how to delete page</p>
<hr />
<div>(Merged into https://wiki.nftables.org/wiki-nftables/index.php/Troubleshooting#Question_4._How_do_nftables_and_iptables_interact_when_used_on_the_same_system.3F)</div>Jeff.wellinghttp://wiki.nftables.org/wiki-nftables/index.php?title=Troubleshooting&diff=260Troubleshooting2018-01-27T00:15:46Z<p>Jeff.welling: Documented iptables and nftables interaction</p>
<hr />
<div>In this section, you can find frequently asked questions that has been posted on the [http://www.netfilter.org/mailinglists.html Netfilter mailing list].<br />
<br />
== Question 1: Address family not supported by protocol problems ==<br />
<br />
If I try to start ''nft'', I get this error:<br />
<br />
<source lang="bash"><br />
% nft list table filter<br />
<cmdline>:1:1-17: Error: Could not receive sets from kernel: Address family not supported by protocol<br />
list table filter<br />
^^^^^^^^^^^^^^^^^<br />
</source><br />
<br />
Answer: You have to create the table before you can actually list it, ie. ''nft add table filter''. Please, see [[Configuring_tables|how to configure tables]]. Moreover, make sure [[Building_and_installing_nftables_from_sources#Validating_your_installation|you also compiled family support]], eg. CONFIG_NF_TABLES_IPV4 and that the module can be loaded (eg. ''nf_tables_ipv4'').<br />
<br />
== Question 2: No such file or directory when adding chain ==<br />
<br />
<source lang="bash"><br />
nft> add chain arp filter input {type nat hook input priority 0 ;} <br />
<cli>:1:1-64: Error: Could not add chain: No such file or directory <br />
add chain arp filter input {type nat hook input priority 0 ;} <br />
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br />
</source><br />
<br />
This means that the chain type for the specified family does not exist. In the example above, the problem is that the NAT chain type does not exist for the ARP family.<br />
<br />
You may also hit this problem if you forgot to compile the module that enables this chain type in your Linux kernel.<br />
<br />
== Question 3: Operation not supported when adding chain ==<br />
<br />
For example:<br />
<br />
<source lang="bash"><br />
nft> add chain ip filter forward {type nat hook forward priority 0 ;} <br />
<cli>:1:1-64: Error: Could not add chain: Operation not supported <br />
add chain filter forward {type nat hook forward priority 0 ;} <br />
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br />
</source><br />
<br />
This means that the chain type for the specified family is not available in that hook. In the example above, the problem is that the available hooks for the NAT chain type are: prerouting, input, output and postrouting.<br />
<br />
== Question 4. How do nftables and iptables interact when used on the same system? ==<br />
<br />
What happens when you mix Iptables and Nftables? How do they interact?<br />
<br />
{|<br />
|'''nft'''<br />
|Empty<br />
|Accept<br />
|Accept<br />
|Block<br />
|Blank<br />
|-<br />
|'''iptables'''<br />
|Empty<br />
|Empty<br />
|Block<br />
|Accept<br />
|Accept<br />
|-<br />
|'''Results'''<br />
|Pass<br />
|Pass<br />
|Unreachable<br />
|Unreachable<br />
|Pass<br />
|}</div>Jeff.wellinghttp://wiki.nftables.org/wiki-nftables/index.php?title=Nftables_and_iptables&diff=259Nftables and iptables2018-01-27T00:12:13Z<p>Jeff.welling: Jeff.welling moved page Nftables and iptables to Nftables and Iptables: Match capitalization</p>
<hr />
<div>#REDIRECT [[Nftables and Iptables]]</div>Jeff.wellinghttp://wiki.nftables.org/wiki-nftables/index.php?title=Nftables_and_Iptables&diff=258Nftables and Iptables2018-01-27T00:12:13Z<p>Jeff.welling: Jeff.welling moved page Nftables and iptables to Nftables and Iptables: Match capitalization</p>
<hr />
<div>== Nftables and Iptables ==<br />
<br />
What happens when you mix Iptables and Nftables? How do they interact?<br />
<br />
{|<br />
|'''nft'''<br />
|Empty<br />
|Accept<br />
|Accept<br />
|Block<br />
|Blank<br />
|-<br />
|'''iptables'''<br />
|Empty<br />
|Empty<br />
|Block<br />
|Accept<br />
|Accept<br />
|-<br />
|'''Results'''<br />
|Pass<br />
|Pass<br />
|Unreachable<br />
|Unreachable<br />
|Pass<br />
|}</div>Jeff.wellinghttp://wiki.nftables.org/wiki-nftables/index.php?title=Nftables_and_Iptables&diff=257Nftables and Iptables2018-01-27T00:11:53Z<p>Jeff.welling: Created page with "== Nftables and Iptables == What happens when you mix Iptables and Nftables? How do they interact? {| |'''nft''' |Empty |Accept |Accept |Block |Blank |- |'''iptables''' |Emp..."</p>
<hr />
<div>== Nftables and Iptables ==<br />
<br />
What happens when you mix Iptables and Nftables? How do they interact?<br />
<br />
{|<br />
|'''nft'''<br />
|Empty<br />
|Accept<br />
|Accept<br />
|Block<br />
|Blank<br />
|-<br />
|'''iptables'''<br />
|Empty<br />
|Empty<br />
|Block<br />
|Accept<br />
|Accept<br />
|-<br />
|'''Results'''<br />
|Pass<br />
|Pass<br />
|Unreachable<br />
|Unreachable<br />
|Pass<br />
|}</div>Jeff.wellinghttp://wiki.nftables.org/wiki-nftables/index.php?title=Configuring_tables&diff=256Configuring tables2018-01-27T00:01:25Z<p>Jeff.welling: Mention the gotcha re flushing tables doesn't flush sets within that table</p>
<hr />
<div>= Adding tables =<br />
<br />
<source lang="bash"><br />
% nft add table ip filter<br />
</source><br />
<br />
= Show/List tables =<br />
<br />
<source lang="bash"><br />
% nft list tables<br />
</source><br />
<br />
= Deleting tables =<br />
<br />
<source lang="bash"><br />
% nft delete table ip foo<br />
</source><br />
<br />
'''Troubleshooting''': Since Linux kernel 3.18, you can delete tables and its content with this command. However, before that version, you need to delete its content first, otherwise you hit an error that look like this:<br />
<br />
<source lang="bash"><br />
% nft delete table filter<br />
<cmdline>:1:1-19: Error: Could not delete table: Device or resource busy<br />
delete table filter<br />
^^^^^^^^^^^^^^^^^^^<br />
</source><br />
<br />
= Flushing tables =<br />
<br />
You can delete all the rules that belong to this table with the following command:<br />
<br />
<source lang="bash"><br />
% nft flush table ip filter<br />
</source><br />
<br />
This removes the rules ''for every chain'' that you register in that table.<br />
<br />
'''Note:''' ''nft flush table ip filter'' will not flush '''Sets''' defined within that table, to do that you must explicitly delete the set or you can use ''nft flush ruleset''.</div>Jeff.wellinghttp://wiki.nftables.org/wiki-nftables/index.php?title=Advanced_ruleset_for_dynamic_environments&diff=255Advanced ruleset for dynamic environments2018-01-26T22:42:32Z<p>Jeff.welling: Note Consul's lack of execution guarantee, suggest Ansible in example use case.</p>
<hr />
<div>'''This page is an unvetted draft'''<br />
<br />
Today's modern computing environments require features like Service Discovery and the environments themselves can be quite dynamic and rapidly changing. One of the ways nftables can help is by breaking firewall config into small pieces which can by dynamically generated by the likes of [https://www.consul.io/ Consul] and [https://www.hashicorp.com/blog/introducing-consul-template Consul Template], [https://www.vaultproject.io/ Vault], or config management like [https://www.chef.io/solutions/infrastructure-automation/ Chef] [https://puppet.com/ Puppet] or [https://www.ansible.com/ Ansible].<br />
<br />
An example use case would be if you had a number of servers, and you detected traffic on one host that you'd like to block across your entire fleet. You could add the IP to block into Consul, which will propagate it out and then Consul Template on each hosts updates nftables blacklist set definition with the new blacklisted IP and reloads nftables. Alternatively if you don't trust Consul due to the lack of an execution guarantee, you could put the blocked IP in an Ansible var and deploy it everywhere through your configuration management system. <br />
<br />
By default your Systemd service file likely lives in ''/lib/systemd/system/'', the values suggested on this page are not default so you may wish to change those values. If you do, it's [https://unix.stackexchange.com/questions/206315/what-is-difference-between-usr-lib-and-etc-systemd best practice] to copy the nftables.service file to ''/etc/systemd/system'' where it will override the system-provided version without the need to modify files provided by the package.<br />
<br />
There's nothing wrong with using a different layout, or even having everything in one file. This author prefers to split out rules and sets into individual files so that grouping them together by application or purpose is easier, you can use any configuration structure you wish.<br />
<br />
'''''TODO:''''' Is ''/etc/nftables.start.conf'' really necessary? In a Debian test system on Linux 4.9.0, Debian Stretch, Nftables version v0.7, this file is not necessary - table creation is implicit from the table definition, for both 'inet' and 'ip' table types. This differs from my tests on the system I've lost access to at the moment, this needs to be explored once the host is reset. Note version numbers if the behaviour changed. <br />
<br />
<br />
'''/etc/nftables.start.conf'''<br />
<br />
Creates tables<br />
<br />
Loads ''/etc/nftables.conf''<br />
<br />
Called from Systemd service file for nftables in ''ExecStart=''<br />
<br />
The table creation statements are kept intentionally separate in this example so that its compatible with both config file formats. With the nftables-output config format, table creation statements cannot be used after the table is already created or an error is thrown, aborting the config reload.<br />
<br />
Example contents of ''/etc/nft.conf.d/nftables.start.conf'':<br />
<br />
<source lang="bash"><br />
create table ip filter<br />
create table ip nat<br />
include "/etc/nftables.conf"<br />
</source><br />
<br />
<br />
'''/etc/nftables.conf'''<br />
<br />
Loads table-specific entries like ''/etc/nft.conf.d/nftables.ip.filter.conf'' and ''/etc/nft.conf.d/nftables.ip.nat.conf''<br />
<br />
Loads Sets main file ''/etc/nft.conf.d/sets.d/main.conf''<br />
<br />
Called from Systemd service file for nftables in ''ExecReload=''<br />
<br />
Example content of ''/etc/nftables.conf'':<br />
<br />
<source lang="bash"><br />
include "/etc/nft.conf.d/sets.d/main.conf"<br />
include "/etc/nft.conf.d/nftables.ip.filter.conf"<br />
include "/etc/nft.conf.d/nftables.ip.nat.conf"<br />
include "/etc/nft.conf.d/nftables.test1.conf"<br />
include "/etc/nft.conf.d/nftables.test2.conf"<br />
</source><br />
<br />
<br />
'''/etc/nft.conf.d/sets.d/main.conf'''<br />
<br />
Loads each individual Set, because nftables doesn't support wildcards in ''include'' statements (yet?)<br />
<br />
Called only from the include in ''/etc/nftables.conf''<br />
<br />
Example content of ''/etc/nft.conf.d/sets.d/main.conf'':<br />
<br />
<source lang="bash"><br />
include "/etc/nft.conf.d/sets.d/trusted_ips1.conf"<br />
include "/etc/nft.conf.d/sets.d/trusted_ips2.conf"<br />
include "/etc/nft.conf.d/sets.d/family_ips.conf"<br />
</source><br />
<br />
Example of an included set ''/etc/nft.conf.d/sets.d/trusted_ips1.conf'':<br />
<br />
<source lang="bash"><br />
table ip filter {<br />
set trusted_ips {<br />
type ipv4_addr<br />
elements = { 192.168.1.1}<br />
}<br />
}<br />
</source><br />
<br />
Example of included set ''/etc/nft.conf.d/sets.d/trusted_ips2.conf'':<br />
<br />
<source lang="bash"><br />
table ip filter {<br />
set trusted_ips {<br />
type ipv4_addr<br />
elements = { 192.168.2.2}<br />
}<br />
}<br />
</source><br />
<br />
Example of included set ''/etc/nft.conf.d/sets.d/family_ips.conf'':<br />
<br />
<source lang="bash"><br />
table ip filter {<br />
set family_ips {<br />
type ipv4_addr<br />
elements = { 192.168.3.3}<br />
}<br />
}<br />
</source><br />
<br />
Example of how the configuration is combined:<br />
<br />
<source lang="bash"><br />
% nft list table ip filter<br />
table ip filter {<br />
set trusted_ips {<br />
type ipv4_addr<br />
elements = { 192.168.2.2, 192.168.1.1}<br />
}<br />
set family_ips {<br />
type ipv4_addr<br />
elements = { 192.168.3.3}<br />
}<br />
}<br />
</source><br />
<br />
<br />
'''/etc/nft.conf.d/nftables.ip.filter.conf'''<br />
<br />
Configures the 'ip filter' table<br />
<br />
Called from ''/etc/nftables.conf''<br />
<br />
Example content:<br />
<br />
<source lang="bash"><br />
flush table ip filter<br />
table ip filter {<br />
set trusted_ips {<br />
type ipv4_addr<br />
elements = { 192.168.2.2, 192.168.1.1}<br />
}<br />
<br />
chain input {<br />
#This is required to get input traffic to process this chain<br />
type filter hook input priority 0; policy drop;<br />
<br />
#Accept all traffic from the LAN, and any traffic related to already-active connections<br />
ip saddr 192.168.1.0/24 counter packets 0 bytes 0 accept<br />
ct state established,related counter packets 6471 bytes 337740 accept<br />
<br />
#Accept SSH connections from everywhere, not just the LAN<br />
tcp dport ssh counter packets 0 bytes 0 accept<br />
<br />
#We want logs of the drops. If you don't, remove this line.<br />
log prefix "nft-input-drop " level debug counter packets 112 bytes 8404 drop<br />
}<br />
<br />
chain output {<br />
#This is required to get output traffic to process this chain<br />
type filter hook output priority 0; policy drop;<br />
<br />
#Accept all outbound traffic <br />
oif "eth1" counter packets 0 bytes 0 accept<br />
<br />
#We want logs of the drops. If you don't, remove this line.<br />
log prefix "nft-output-drop " level debug counter packets 0 bytes 0 drop<br />
}<br />
<br />
chain forward {<br />
#This is required to get forward traffic to process this chain<br />
type filter hook forward priority 0; policy drop;<br />
<br />
#We want logs of the drops. If you don't, remove this line.<br />
log prefix "nft-forward-drop " level debug counter packets 104 bytes 4910 drop<br />
}<br />
}<br />
</source><br />
<br />
<br />
'''/etc/nft.conf.d/nftables.ip.nat.conf'''<br />
<br />
Configures the 'ip nat' table<br />
<br />
Called from ''/etc/nftables.conf''<br />
<br />
Example contents of ''/etc/nft.conf.d/nftables.ip.nat.conf'':<br />
<br />
<source lang="bash"><br />
flush table nat<br />
table ip nat {<br />
chain prerouting {<br />
type filter hook prerouting priority 0<br />
}<br />
chain postrouting {<br />
type filter hook postrouting priority 100<br />
}<br />
}<br />
</source></div>Jeff.wellinghttp://wiki.nftables.org/wiki-nftables/index.php?title=Advanced_ruleset_for_dynamic_environments&diff=254Advanced ruleset for dynamic environments2018-01-26T22:26:22Z<p>Jeff.welling: Added a use case</p>
<hr />
<div>'''This page is an unvetted draft'''<br />
<br />
Today's modern computing environments require features like Service Discovery and the environments themselves can be quite dynamic and rapidly changing. One of the ways nftables can help is by breaking firewall config into small pieces which can by dynamically generated by the likes of [https://www.consul.io/ Consul] and [https://www.hashicorp.com/blog/introducing-consul-template Consul Template], [https://www.vaultproject.io/ Vault], or config management like [https://www.chef.io/solutions/infrastructure-automation/ Chef] [https://puppet.com/ Puppet] or [https://www.ansible.com/ Ansible].<br />
<br />
An example use case would be if you had a number of servers, and you detected traffic on one host that you'd like to block across your entire fleet. You could add the IP to block into Consul, which will propagate it out and then Consul Template on each hosts updates nftables blacklist set definition with the new blacklisted IP and reloads nftables.<br />
<br />
By default your Systemd service file likely lives in ''/lib/systemd/system/'', the values suggested on this page are not default so you may wish to change those values. If you do, it's [https://unix.stackexchange.com/questions/206315/what-is-difference-between-usr-lib-and-etc-systemd best practice] to copy the nftables.service file to ''/etc/systemd/system'' where it will override the system-provided version without the need to modify files provided by the package.<br />
<br />
There's nothing wrong with using a different layout, or even having everything in one file. This author prefers to split out rules and sets into individual files so that grouping them together by application or purpose is easier, you can use any configuration structure you wish.<br />
<br />
'''''TODO:''''' Is ''/etc/nftables.start.conf'' really necessary? In a Debian test system on Linux 4.9.0, Debian Stretch, Nftables version v0.7, this file is not necessary - table creation is implicit from the table definition, for both 'inet' and 'ip' table types. This differs from my tests on the system I've lost access to at the moment, this needs to be explored once the host is reset. Note version numbers if the behaviour changed. <br />
<br />
<br />
'''/etc/nftables.start.conf'''<br />
<br />
Creates tables<br />
<br />
Loads ''/etc/nftables.conf''<br />
<br />
Called from Systemd service file for nftables in ''ExecStart=''<br />
<br />
The table creation statements are kept intentionally separate in this example so that its compatible with both config file formats. With the nftables-output config format, table creation statements cannot be used after the table is already created or an error is thrown, aborting the config reload.<br />
<br />
Example contents of ''/etc/nft.conf.d/nftables.start.conf'':<br />
<br />
<source lang="bash"><br />
create table ip filter<br />
create table ip nat<br />
include "/etc/nftables.conf"<br />
</source><br />
<br />
<br />
'''/etc/nftables.conf'''<br />
<br />
Loads table-specific entries like ''/etc/nft.conf.d/nftables.ip.filter.conf'' and ''/etc/nft.conf.d/nftables.ip.nat.conf''<br />
<br />
Loads Sets main file ''/etc/nft.conf.d/sets.d/main.conf''<br />
<br />
Called from Systemd service file for nftables in ''ExecReload=''<br />
<br />
Example content of ''/etc/nftables.conf'':<br />
<br />
<source lang="bash"><br />
include "/etc/nft.conf.d/sets.d/main.conf"<br />
include "/etc/nft.conf.d/nftables.ip.filter.conf"<br />
include "/etc/nft.conf.d/nftables.ip.nat.conf"<br />
include "/etc/nft.conf.d/nftables.test1.conf"<br />
include "/etc/nft.conf.d/nftables.test2.conf"<br />
</source><br />
<br />
<br />
'''/etc/nft.conf.d/sets.d/main.conf'''<br />
<br />
Loads each individual Set, because nftables doesn't support wildcards in ''include'' statements (yet?)<br />
<br />
Called only from the include in ''/etc/nftables.conf''<br />
<br />
Example content of ''/etc/nft.conf.d/sets.d/main.conf'':<br />
<br />
<source lang="bash"><br />
include "/etc/nft.conf.d/sets.d/trusted_ips1.conf"<br />
include "/etc/nft.conf.d/sets.d/trusted_ips2.conf"<br />
include "/etc/nft.conf.d/sets.d/family_ips.conf"<br />
</source><br />
<br />
Example of an included set ''/etc/nft.conf.d/sets.d/trusted_ips1.conf'':<br />
<br />
<source lang="bash"><br />
table ip filter {<br />
set trusted_ips {<br />
type ipv4_addr<br />
elements = { 192.168.1.1}<br />
}<br />
}<br />
</source><br />
<br />
Example of included set ''/etc/nft.conf.d/sets.d/trusted_ips2.conf'':<br />
<br />
<source lang="bash"><br />
table ip filter {<br />
set trusted_ips {<br />
type ipv4_addr<br />
elements = { 192.168.2.2}<br />
}<br />
}<br />
</source><br />
<br />
Example of included set ''/etc/nft.conf.d/sets.d/family_ips.conf'':<br />
<br />
<source lang="bash"><br />
table ip filter {<br />
set family_ips {<br />
type ipv4_addr<br />
elements = { 192.168.3.3}<br />
}<br />
}<br />
</source><br />
<br />
Example of how the configuration is combined:<br />
<br />
<source lang="bash"><br />
% nft list table ip filter<br />
table ip filter {<br />
set trusted_ips {<br />
type ipv4_addr<br />
elements = { 192.168.2.2, 192.168.1.1}<br />
}<br />
set family_ips {<br />
type ipv4_addr<br />
elements = { 192.168.3.3}<br />
}<br />
}<br />
</source><br />
<br />
<br />
'''/etc/nft.conf.d/nftables.ip.filter.conf'''<br />
<br />
Configures the 'ip filter' table<br />
<br />
Called from ''/etc/nftables.conf''<br />
<br />
Example content:<br />
<br />
<source lang="bash"><br />
flush table ip filter<br />
table ip filter {<br />
set trusted_ips {<br />
type ipv4_addr<br />
elements = { 192.168.2.2, 192.168.1.1}<br />
}<br />
<br />
chain input {<br />
#This is required to get input traffic to process this chain<br />
type filter hook input priority 0; policy drop;<br />
<br />
#Accept all traffic from the LAN, and any traffic related to already-active connections<br />
ip saddr 192.168.1.0/24 counter packets 0 bytes 0 accept<br />
ct state established,related counter packets 6471 bytes 337740 accept<br />
<br />
#Accept SSH connections from everywhere, not just the LAN<br />
tcp dport ssh counter packets 0 bytes 0 accept<br />
<br />
#We want logs of the drops. If you don't, remove this line.<br />
log prefix "nft-input-drop " level debug counter packets 112 bytes 8404 drop<br />
}<br />
<br />
chain output {<br />
#This is required to get output traffic to process this chain<br />
type filter hook output priority 0; policy drop;<br />
<br />
#Accept all outbound traffic <br />
oif "eth1" counter packets 0 bytes 0 accept<br />
<br />
#We want logs of the drops. If you don't, remove this line.<br />
log prefix "nft-output-drop " level debug counter packets 0 bytes 0 drop<br />
}<br />
<br />
chain forward {<br />
#This is required to get forward traffic to process this chain<br />
type filter hook forward priority 0; policy drop;<br />
<br />
#We want logs of the drops. If you don't, remove this line.<br />
log prefix "nft-forward-drop " level debug counter packets 104 bytes 4910 drop<br />
}<br />
}<br />
</source><br />
<br />
<br />
'''/etc/nft.conf.d/nftables.ip.nat.conf'''<br />
<br />
Configures the 'ip nat' table<br />
<br />
Called from ''/etc/nftables.conf''<br />
<br />
Example contents of ''/etc/nft.conf.d/nftables.ip.nat.conf'':<br />
<br />
<source lang="bash"><br />
flush table nat<br />
table ip nat {<br />
chain prerouting {<br />
type filter hook prerouting priority 0<br />
}<br />
chain postrouting {<br />
type filter hook postrouting priority 100<br />
}<br />
}<br />
</source></div>Jeff.wellinghttp://wiki.nftables.org/wiki-nftables/index.php?title=Advanced_ruleset_for_dynamic_environments&diff=253Advanced ruleset for dynamic environments2018-01-26T22:21:33Z<p>Jeff.welling: Note behavioural change - table creation is implicit now?</p>
<hr />
<div>'''This page is an unvetted draft'''<br />
<br />
Today's modern computing environments require features like Service Discovery and the environments themselves can be quite dynamic and rapidly changing. One of the ways nftables can help is by breaking firewall config into small pieces which can by dynamically generated by the likes of [https://www.consul.io/ Consul] and [https://www.hashicorp.com/blog/introducing-consul-template Consul Template], [https://www.vaultproject.io/ Vault], or config management like [https://www.chef.io/solutions/infrastructure-automation/ Chef] [https://puppet.com/ Puppet] or [https://www.ansible.com/ Ansible].<br />
<br />
By default your Systemd service file likely lives in ''/lib/systemd/system/'', the values suggested on this page are not default so you may wish to change those values. If you do, it's [https://unix.stackexchange.com/questions/206315/what-is-difference-between-usr-lib-and-etc-systemd best practice] to copy the nftables.service file to ''/etc/systemd/system'' where it will override the system-provided version without the need to modify files provided by the package.<br />
<br />
There's nothing wrong with using a different layout, or even having everything in one file. This author prefers to split out rules and sets into individual files so that grouping them together by application or purpose is easier, you can use any configuration structure you wish.<br />
<br />
'''''TODO:''''' Is ''/etc/nftables.start.conf'' really necessary? In a Debian test system on Linux 4.9.0, Debian Stretch, Nftables version v0.7, this file is not necessary - table creation is implicit from the table definition, for both 'inet' and 'ip' table types. This differs from my tests on the system I've lost access to at the moment, this needs to be explored once the host is reset. Note version numbers if the behaviour changed. <br />
<br />
<br />
'''/etc/nftables.start.conf'''<br />
<br />
Creates tables<br />
<br />
Loads ''/etc/nftables.conf''<br />
<br />
Called from Systemd service file for nftables in ''ExecStart=''<br />
<br />
The table creation statements are kept intentionally separate in this example so that its compatible with both config file formats. With the nftables-output config format, table creation statements cannot be used after the table is already created or an error is thrown, aborting the config reload.<br />
<br />
Example contents of ''/etc/nft.conf.d/nftables.start.conf'':<br />
<br />
<source lang="bash"><br />
create table ip filter<br />
create table ip nat<br />
include "/etc/nftables.conf"<br />
</source><br />
<br />
<br />
'''/etc/nftables.conf'''<br />
<br />
Loads table-specific entries like ''/etc/nft.conf.d/nftables.ip.filter.conf'' and ''/etc/nft.conf.d/nftables.ip.nat.conf''<br />
<br />
Loads Sets main file ''/etc/nft.conf.d/sets.d/main.conf''<br />
<br />
Called from Systemd service file for nftables in ''ExecReload=''<br />
<br />
Example content of ''/etc/nftables.conf'':<br />
<br />
<source lang="bash"><br />
include "/etc/nft.conf.d/sets.d/main.conf"<br />
include "/etc/nft.conf.d/nftables.ip.filter.conf"<br />
include "/etc/nft.conf.d/nftables.ip.nat.conf"<br />
include "/etc/nft.conf.d/nftables.test1.conf"<br />
include "/etc/nft.conf.d/nftables.test2.conf"<br />
</source><br />
<br />
<br />
'''/etc/nft.conf.d/sets.d/main.conf'''<br />
<br />
Loads each individual Set, because nftables doesn't support wildcards in ''include'' statements (yet?)<br />
<br />
Called only from the include in ''/etc/nftables.conf''<br />
<br />
Example content of ''/etc/nft.conf.d/sets.d/main.conf'':<br />
<br />
<source lang="bash"><br />
include "/etc/nft.conf.d/sets.d/trusted_ips1.conf"<br />
include "/etc/nft.conf.d/sets.d/trusted_ips2.conf"<br />
include "/etc/nft.conf.d/sets.d/family_ips.conf"<br />
</source><br />
<br />
Example of an included set ''/etc/nft.conf.d/sets.d/trusted_ips1.conf'':<br />
<br />
<source lang="bash"><br />
table ip filter {<br />
set trusted_ips {<br />
type ipv4_addr<br />
elements = { 192.168.1.1}<br />
}<br />
}<br />
</source><br />
<br />
Example of included set ''/etc/nft.conf.d/sets.d/trusted_ips2.conf'':<br />
<br />
<source lang="bash"><br />
table ip filter {<br />
set trusted_ips {<br />
type ipv4_addr<br />
elements = { 192.168.2.2}<br />
}<br />
}<br />
</source><br />
<br />
Example of included set ''/etc/nft.conf.d/sets.d/family_ips.conf'':<br />
<br />
<source lang="bash"><br />
table ip filter {<br />
set family_ips {<br />
type ipv4_addr<br />
elements = { 192.168.3.3}<br />
}<br />
}<br />
</source><br />
<br />
Example of how the configuration is combined:<br />
<br />
<source lang="bash"><br />
% nft list table ip filter<br />
table ip filter {<br />
set trusted_ips {<br />
type ipv4_addr<br />
elements = { 192.168.2.2, 192.168.1.1}<br />
}<br />
set family_ips {<br />
type ipv4_addr<br />
elements = { 192.168.3.3}<br />
}<br />
}<br />
</source><br />
<br />
<br />
'''/etc/nft.conf.d/nftables.ip.filter.conf'''<br />
<br />
Configures the 'ip filter' table<br />
<br />
Called from ''/etc/nftables.conf''<br />
<br />
Example content:<br />
<br />
<source lang="bash"><br />
flush table ip filter<br />
table ip filter {<br />
set trusted_ips {<br />
type ipv4_addr<br />
elements = { 192.168.2.2, 192.168.1.1}<br />
}<br />
<br />
chain input {<br />
#This is required to get input traffic to process this chain<br />
type filter hook input priority 0; policy drop;<br />
<br />
#Accept all traffic from the LAN, and any traffic related to already-active connections<br />
ip saddr 192.168.1.0/24 counter packets 0 bytes 0 accept<br />
ct state established,related counter packets 6471 bytes 337740 accept<br />
<br />
#Accept SSH connections from everywhere, not just the LAN<br />
tcp dport ssh counter packets 0 bytes 0 accept<br />
<br />
#We want logs of the drops. If you don't, remove this line.<br />
log prefix "nft-input-drop " level debug counter packets 112 bytes 8404 drop<br />
}<br />
<br />
chain output {<br />
#This is required to get output traffic to process this chain<br />
type filter hook output priority 0; policy drop;<br />
<br />
#Accept all outbound traffic <br />
oif "eth1" counter packets 0 bytes 0 accept<br />
<br />
#We want logs of the drops. If you don't, remove this line.<br />
log prefix "nft-output-drop " level debug counter packets 0 bytes 0 drop<br />
}<br />
<br />
chain forward {<br />
#This is required to get forward traffic to process this chain<br />
type filter hook forward priority 0; policy drop;<br />
<br />
#We want logs of the drops. If you don't, remove this line.<br />
log prefix "nft-forward-drop " level debug counter packets 104 bytes 4910 drop<br />
}<br />
}<br />
</source><br />
<br />
<br />
'''/etc/nft.conf.d/nftables.ip.nat.conf'''<br />
<br />
Configures the 'ip nat' table<br />
<br />
Called from ''/etc/nftables.conf''<br />
<br />
Example contents of ''/etc/nft.conf.d/nftables.ip.nat.conf'':<br />
<br />
<source lang="bash"><br />
flush table nat<br />
table ip nat {<br />
chain prerouting {<br />
type filter hook prerouting priority 0<br />
}<br />
chain postrouting {<br />
type filter hook postrouting priority 100<br />
}<br />
}<br />
</source></div>Jeff.wellinghttp://wiki.nftables.org/wiki-nftables/index.php?title=Advanced_ruleset_for_dynamic_environments&diff=252Advanced ruleset for dynamic environments2018-01-26T20:03:21Z<p>Jeff.welling: </p>
<hr />
<div>'''This page is an unvetted draft'''<br />
<br />
Today's modern computing environments require features like Service Discovery and the environments themselves can be quite dynamic and rapidly changing. One of the ways nftables can help is by breaking firewall config into small pieces which can by dynamically generated by the likes of [https://www.consul.io/ Consul] and [https://www.hashicorp.com/blog/introducing-consul-template Consul Template], [https://www.vaultproject.io/ Vault], or config management like [https://www.chef.io/solutions/infrastructure-automation/ Chef] [https://puppet.com/ Puppet] or [https://www.ansible.com/ Ansible].<br />
<br />
By default your Systemd service file likely lives in ''/lib/systemd/system/'', the values suggested on this page are not default so you may wish to change those values. If you do, it's [https://unix.stackexchange.com/questions/206315/what-is-difference-between-usr-lib-and-etc-systemd best practice] to copy the nftables.service file to ''/etc/systemd/system'' where it will override the system-provided version without the need to modify files provided by the package.<br />
<br />
There's nothing wrong with using a different layout, or even having everything in one file. This author prefers to split out rules and sets into individual files so that grouping them together by application or purpose is easier, you can use any configuration structure you wish.<br />
<br />
<br />
<br />
'''/etc/nftables.start.conf'''<br />
<br />
Creates tables<br />
<br />
Loads ''/etc/nftables.conf''<br />
<br />
Called from Systemd service file for nftables in ''ExecStart=''<br />
<br />
The table creation statements are kept intentionally separate in this example so that its compatible with both config file formats. With the nftables-output config format, table creation statements cannot be used after the table is already created or an error is thrown, aborting the config reload.<br />
<br />
Example contents of ''/etc/nft.conf.d/nftables.start.conf'':<br />
<br />
<source lang="bash"><br />
create table ip filter<br />
create table ip nat<br />
include "/etc/nftables.conf"<br />
</source><br />
<br />
<br />
'''/etc/nftables.conf'''<br />
<br />
Loads table-specific entries like ''/etc/nft.conf.d/nftables.ip.filter.conf'' and ''/etc/nft.conf.d/nftables.ip.nat.conf''<br />
<br />
Loads Sets main file ''/etc/nft.conf.d/sets.d/main.conf''<br />
<br />
Called from Systemd service file for nftables in ''ExecReload=''<br />
<br />
Example content of ''/etc/nftables.conf'':<br />
<br />
<source lang="bash"><br />
include "/etc/nft.conf.d/sets.d/main.conf"<br />
include "/etc/nft.conf.d/nftables.ip.filter.conf"<br />
include "/etc/nft.conf.d/nftables.ip.nat.conf"<br />
include "/etc/nft.conf.d/nftables.test1.conf"<br />
include "/etc/nft.conf.d/nftables.test2.conf"<br />
</source><br />
<br />
<br />
'''/etc/nft.conf.d/sets.d/main.conf'''<br />
<br />
Loads each individual Set, because nftables doesn't support wildcards in ''include'' statements (yet?)<br />
<br />
Called only from the include in ''/etc/nftables.conf''<br />
<br />
Example content of ''/etc/nft.conf.d/sets.d/main.conf'':<br />
<br />
<source lang="bash"><br />
include "/etc/nft.conf.d/sets.d/trusted_ips1.conf"<br />
include "/etc/nft.conf.d/sets.d/trusted_ips2.conf"<br />
include "/etc/nft.conf.d/sets.d/family_ips.conf"<br />
</source><br />
<br />
Example of an included set ''/etc/nft.conf.d/sets.d/trusted_ips1.conf'':<br />
<br />
<source lang="bash"><br />
table ip filter {<br />
set trusted_ips {<br />
type ipv4_addr<br />
elements = { 192.168.1.1}<br />
}<br />
}<br />
</source><br />
<br />
Example of included set ''/etc/nft.conf.d/sets.d/trusted_ips2.conf'':<br />
<br />
<source lang="bash"><br />
table ip filter {<br />
set trusted_ips {<br />
type ipv4_addr<br />
elements = { 192.168.2.2}<br />
}<br />
}<br />
</source><br />
<br />
Example of included set ''/etc/nft.conf.d/sets.d/family_ips.conf'':<br />
<br />
<source lang="bash"><br />
table ip filter {<br />
set family_ips {<br />
type ipv4_addr<br />
elements = { 192.168.3.3}<br />
}<br />
}<br />
</source><br />
<br />
Example of how the configuration is combined:<br />
<br />
<source lang="bash"><br />
% nft list table ip filter<br />
table ip filter {<br />
set trusted_ips {<br />
type ipv4_addr<br />
elements = { 192.168.2.2, 192.168.1.1}<br />
}<br />
set family_ips {<br />
type ipv4_addr<br />
elements = { 192.168.3.3}<br />
}<br />
}<br />
</source><br />
<br />
<br />
'''/etc/nft.conf.d/nftables.ip.filter.conf'''<br />
<br />
Configures the 'ip filter' table<br />
<br />
Called from ''/etc/nftables.conf''<br />
<br />
Example content:<br />
<br />
<source lang="bash"><br />
flush table ip filter<br />
table ip filter {<br />
set trusted_ips {<br />
type ipv4_addr<br />
elements = { 192.168.2.2, 192.168.1.1}<br />
}<br />
<br />
chain input {<br />
#This is required to get input traffic to process this chain<br />
type filter hook input priority 0; policy drop;<br />
<br />
#Accept all traffic from the LAN, and any traffic related to already-active connections<br />
ip saddr 192.168.1.0/24 counter packets 0 bytes 0 accept<br />
ct state established,related counter packets 6471 bytes 337740 accept<br />
<br />
#Accept SSH connections from everywhere, not just the LAN<br />
tcp dport ssh counter packets 0 bytes 0 accept<br />
<br />
#We want logs of the drops. If you don't, remove this line.<br />
log prefix "nft-input-drop " level debug counter packets 112 bytes 8404 drop<br />
}<br />
<br />
chain output {<br />
#This is required to get output traffic to process this chain<br />
type filter hook output priority 0; policy drop;<br />
<br />
#Accept all outbound traffic <br />
oif "eth1" counter packets 0 bytes 0 accept<br />
<br />
#We want logs of the drops. If you don't, remove this line.<br />
log prefix "nft-output-drop " level debug counter packets 0 bytes 0 drop<br />
}<br />
<br />
chain forward {<br />
#This is required to get forward traffic to process this chain<br />
type filter hook forward priority 0; policy drop;<br />
<br />
#We want logs of the drops. If you don't, remove this line.<br />
log prefix "nft-forward-drop " level debug counter packets 104 bytes 4910 drop<br />
}<br />
}<br />
</source><br />
<br />
<br />
'''/etc/nft.conf.d/nftables.ip.nat.conf'''<br />
<br />
Configures the 'ip nat' table<br />
<br />
Called from ''/etc/nftables.conf''<br />
<br />
Example contents of ''/etc/nft.conf.d/nftables.ip.nat.conf'':<br />
<br />
<source lang="bash"><br />
flush table nat<br />
table ip nat {<br />
chain prerouting {<br />
type filter hook prerouting priority 0<br />
}<br />
chain postrouting {<br />
type filter hook postrouting priority 100<br />
}<br />
}<br />
</source></div>Jeff.wellinghttp://wiki.nftables.org/wiki-nftables/index.php?title=Advanced_ruleset_for_dynamic_environments&diff=251Advanced ruleset for dynamic environments2018-01-26T19:57:46Z<p>Jeff.welling: </p>
<hr />
<div>'''This page is an unvetted draft'''<br />
<br />
Today's modern computing environments require features like Service Discovery and the environments themselves can be quite dynamic and rapidly changing. One of the ways nftables can help is by breaking firewall config into small pieces which can by dynamically generated by the likes of [https://www.consul.io/ Consul] and [https://www.hashicorp.com/blog/introducing-consul-template Consul Template], [https://www.vaultproject.io/ Vault], or config management like [https://www.chef.io/solutions/infrastructure-automation/ Chef] [https://puppet.com/ Puppet] or [https://www.ansible.com/ Ansible].<br />
<br />
By default your Systemd service file likely lives in ''/lib/systemd/system/'', the values suggested on this page are not default so you may wish to change those values. If you do, it's [https://unix.stackexchange.com/questions/206315/what-is-difference-between-usr-lib-and-etc-systemd best practice] to copy the nftables.service file to ''/etc/systemd/system'' where it will override the system-provided version without the need to modify files provided by the package.<br />
<br />
<br />
<br />
'''/etc/nftables.start.conf'''<br />
<br />
Creates tables<br />
<br />
Loads ''/etc/nftables.conf''<br />
<br />
Called from Systemd service file for nftables in ''ExecStart=''<br />
<br />
The table creation statements are kept intentionally separate in this example so that its compatible with both config file formats. With the nftables-output config format, table creation statements cannot be used after the table is already created or an error is thrown, aborting the config reload.<br />
<br />
Example contents of ''/etc/nft.conf.d/nftables.start.conf'':<br />
<br />
<source lang="bash"><br />
create table ip filter<br />
create table ip nat<br />
include "/etc/nftables.conf"<br />
</source><br />
<br />
<br />
'''/etc/nftables.conf'''<br />
<br />
Loads table-specific entries like ''/etc/nft.conf.d/nftables.ip.filter.conf'' and ''/etc/nft.conf.d/nftables.ip.nat.conf''<br />
<br />
Loads Sets main file ''/etc/nft.conf.d/sets.d/main.conf''<br />
<br />
Called from Systemd service file for nftables in ''ExecReload=''<br />
<br />
Example content of ''/etc/nftables.conf'':<br />
<br />
<source lang="bash"><br />
include "/etc/nft.conf.d/sets.d/main.conf"<br />
include "/etc/nft.conf.d/nftables.ip.filter.conf"<br />
include "/etc/nft.conf.d/nftables.ip.nat.conf"<br />
include "/etc/nft.conf.d/nftables.test1.conf"<br />
include "/etc/nft.conf.d/nftables.test2.conf"<br />
</source><br />
<br />
<br />
'''/etc/nft.conf.d/sets.d/main.conf'''<br />
<br />
Loads each individual Set, because nftables doesn't support wildcards in ''include'' statements (yet?)<br />
<br />
Called only from the include in ''/etc/nftables.conf''<br />
<br />
Example content of ''/etc/nft.conf.d/sets.d/main.conf'':<br />
<br />
<source lang="bash"><br />
include "/etc/nft.conf.d/sets.d/trusted_ips1.conf"<br />
include "/etc/nft.conf.d/sets.d/trusted_ips2.conf"<br />
include "/etc/nft.conf.d/sets.d/family_ips.conf"<br />
</source><br />
<br />
Example of an included set ''/etc/nft.conf.d/sets.d/trusted_ips1.conf'':<br />
<br />
<source lang="bash"><br />
table ip filter {<br />
set trusted_ips {<br />
type ipv4_addr<br />
elements = { 192.168.1.1}<br />
}<br />
}<br />
</source><br />
<br />
Example of included set ''/etc/nft.conf.d/sets.d/trusted_ips2.conf'':<br />
<br />
<source lang="bash"><br />
table ip filter {<br />
set trusted_ips {<br />
type ipv4_addr<br />
elements = { 192.168.2.2}<br />
}<br />
}<br />
</source><br />
<br />
Example of included set ''/etc/nft.conf.d/sets.d/family_ips.conf'':<br />
<br />
<source lang="bash"><br />
table ip filter {<br />
set family_ips {<br />
type ipv4_addr<br />
elements = { 192.168.3.3}<br />
}<br />
}<br />
</source><br />
<br />
Example of how the configuration is combined:<br />
<br />
<source lang="bash"><br />
% nft list table ip filter<br />
table ip filter {<br />
set trusted_ips {<br />
type ipv4_addr<br />
elements = { 192.168.2.2, 192.168.1.1}<br />
}<br />
set family_ips {<br />
type ipv4_addr<br />
elements = { 192.168.3.3}<br />
}<br />
}<br />
</source><br />
<br />
<br />
'''/etc/nft.conf.d/nftables.ip.filter.conf'''<br />
<br />
Configures the 'ip filter' table<br />
<br />
Called from ''/etc/nftables.conf''<br />
<br />
Example content:<br />
<br />
<source lang="bash"><br />
flush table ip filter<br />
table ip filter {<br />
set trusted_ips {<br />
type ipv4_addr<br />
elements = { 192.168.2.2, 192.168.1.1}<br />
}<br />
<br />
chain input {<br />
#This is required to get input traffic to process this chain<br />
type filter hook input priority 0; policy drop;<br />
<br />
#Accept all traffic from the LAN, and any traffic related to already-active connections<br />
ip saddr 192.168.1.0/24 counter packets 0 bytes 0 accept<br />
ct state established,related counter packets 6471 bytes 337740 accept<br />
<br />
#Accept SSH connections from everywhere, not just the LAN<br />
tcp dport ssh counter packets 0 bytes 0 accept<br />
<br />
#We want logs of the drops. If you don't, remove this line.<br />
log prefix "nft-input-drop " level debug counter packets 112 bytes 8404 drop<br />
}<br />
<br />
chain output {<br />
#This is required to get output traffic to process this chain<br />
type filter hook output priority 0; policy drop;<br />
<br />
#Accept all outbound traffic <br />
oif "eth1" counter packets 0 bytes 0 accept<br />
<br />
#We want logs of the drops. If you don't, remove this line.<br />
log prefix "nft-output-drop " level debug counter packets 0 bytes 0 drop<br />
}<br />
<br />
chain forward {<br />
#This is required to get forward traffic to process this chain<br />
type filter hook forward priority 0; policy drop;<br />
<br />
#We want logs of the drops. If you don't, remove this line.<br />
log prefix "nft-forward-drop " level debug counter packets 104 bytes 4910 drop<br />
}<br />
}<br />
</source><br />
<br />
<br />
'''/etc/nft.conf.d/nftables.ip.nat.conf'''<br />
<br />
Configures the 'ip nat' table<br />
<br />
Called from ''/etc/nftables.conf''<br />
<br />
Example contents of ''/etc/nft.conf.d/nftables.ip.nat.conf'':<br />
<br />
<source lang="bash"><br />
flush table nat<br />
table ip nat {<br />
chain prerouting {<br />
type filter hook prerouting priority 0<br />
}<br />
chain postrouting {<br />
type filter hook postrouting priority 100<br />
}<br />
}<br />
</source></div>Jeff.wellinghttp://wiki.nftables.org/wiki-nftables/index.php?title=Atomic_rule_replacement&diff=250Atomic rule replacement2018-01-26T08:09:06Z<p>Jeff.welling: Improved example of nftables output format configs</p>
<hr />
<div>== Warning about Shell scripting + nftables ==<br />
<br />
With iptables it was common to use a bash script comprised of multiple iptables commands to configure a firewall. This is sub-optimal because it is not atomic, that is to say that during the few fractions of a second that your bash script takes to run your firewall is in a partially configured state. Nftables introduces atomic rule replacement with the ''-f'' option. This is different from bash scripts because nftables will read in all of the included config files, create the config object in memory alongside the existing config, and then in one atomic operation it swaps the old config for the new one meaning there is no moment when the firewall is partially configured. <br />
<br />
== Atomic Rule Replacement ==<br />
<br />
You can use the ''-f'' option to atomically update your rule-set:<br />
<br />
<source lang="bash"><br />
% nft -f file<br />
</source><br />
<br />
Where ''file'' contains your rule-set.<br />
<br />
You can save your rule-set by storing the existing listing in a file, ie.<br />
<br />
<source lang="bash"><br />
% nft list table filter > filter-table<br />
</source><br />
<br />
Then you can restore it by using the ''-f'' option:<br />
<br />
<source lang="bash"><br />
% nft -f filter-table<br />
</source><br />
<br />
'''Notes:''' <br />
<br />
'''''Table Creation''''' - you may have to create the table with ''nft create table ip filter'' before you can load the file exported with ''nft list table filter > filter-table'' otherwise you will hit errors because the table does not exist.<br />
<br />
'''''Comments''''' - You can also add comments to the ''filter-table'' file. Comments are bash style, starting with # and go to the end of the line.<br />
<br />
'''''Duplicate Rules''''' - If you prepend the ''flush table filter'' line at the very beginning of the ''filter-table'' file, you achieve atomic rule-set replacement equivalent to what ''iptables-restore'' provides. The kernel handles the rule commands in the file in one single transaction, so basically the flushing and the load of the new rules happens in one single shot. If you choose not to flush your tables then you will see duplicate rules for each time you reloaded the config.<br />
<br />
'''''Flushing Sets''''' - ''flush table filter'' will not flush any sets defined in that table. To flush sets as well, use ''flush ruleset'' (not available in Linux 3.16 or below) or delete the sets explicitly. Early versions (Linux <=3.16) do not allow you to import a set if it already exists, but this is allowed in later versions.<br />
<br />
'''''Nftables Config File Formats''''' - ''nft -f <filename>'' accepts 2 formats, the first is the format seen in the output of ''nft list table''. The second is [[Scripting]] and is the format you typically see on this website.<br />
<br />
Example of nftables output format:<br />
<br />
<source lang="bash"><br />
create table ip nat<br />
#flush table nat<br />
table ip nat {<br />
chain prerouting {<br />
type filter hook prerouting priority 0; policy accept;<br />
}<br />
<br />
chain postrouting {<br />
type filter hook postrouting priority 100; policy accept;<br />
}<br />
}<br />
</source><br />
<br />
Example of scripted config format:<br />
<br />
<source lang="bash"><br />
#!/usr/sbin/nft -f<br />
<br />
define ntp_servers = { 84.77.40.132, 176.31.53.99, 81.19.96.148, 138.100.62.8 }<br />
<br />
add table filter<br />
add chain filter input { type filter hook input priority 0; }<br />
add rule filter input ip saddr $ntp_servers counter<br />
</source><br />
<br />
'''Combining multiple files'''<br />
<br />
''What happens when you include 2 files which each have a statement for the filter table?''<br />
<br />
If you have two files, both ''include''d, both with statements for the filter table, but one adds a rule allowing traffic from 192.168.1.1 and the other allows traffic from 192.168.1.2 then both rules will be included in the chain, even if one or both files contains a flush statement.<br />
<br />
''What about flush statements in either, or neither file?''<br />
<br />
If there are any flush commands in any included file then those will be run at the moment the config swap is executed, not at the moment the file is loaded. If you do not include a flush statement in any included file, you will get duplicate rules. If you do include a flush statement, you will not get duplicate rules and the config from *both* files will be included. <br />
<br />
'''Converting between formats'''<br />
<br />
The easiest way to convert from scripted config format to output-based is to run the commands and then show the nftables config with ''nft list table ip filter'' and then copy/paste that into your config file.<br />
The easiest way to convert from output-based to scripted based is to lookup the equivalent on this wiki.</div>Jeff.wellinghttp://wiki.nftables.org/wiki-nftables/index.php?title=Atomic_rule_replacement&diff=249Atomic rule replacement2018-01-26T08:05:12Z<p>Jeff.welling: Better example of scripting format</p>
<hr />
<div>== Warning about Shell scripting + nftables ==<br />
<br />
With iptables it was common to use a bash script comprised of multiple iptables commands to configure a firewall. This is sub-optimal because it is not atomic, that is to say that during the few fractions of a second that your bash script takes to run your firewall is in a partially configured state. Nftables introduces atomic rule replacement with the ''-f'' option. This is different from bash scripts because nftables will read in all of the included config files, create the config object in memory alongside the existing config, and then in one atomic operation it swaps the old config for the new one meaning there is no moment when the firewall is partially configured. <br />
<br />
== Atomic Rule Replacement ==<br />
<br />
You can use the ''-f'' option to atomically update your rule-set:<br />
<br />
<source lang="bash"><br />
% nft -f file<br />
</source><br />
<br />
Where ''file'' contains your rule-set.<br />
<br />
You can save your rule-set by storing the existing listing in a file, ie.<br />
<br />
<source lang="bash"><br />
% nft list table filter > filter-table<br />
</source><br />
<br />
Then you can restore it by using the ''-f'' option:<br />
<br />
<source lang="bash"><br />
% nft -f filter-table<br />
</source><br />
<br />
'''Notes:''' <br />
<br />
'''''Table Creation''''' - you may have to create the table with ''nft create table ip filter'' before you can load the file exported with ''nft list table filter > filter-table'' otherwise you will hit errors because the table does not exist.<br />
<br />
'''''Comments''''' - You can also add comments to the ''filter-table'' file. Comments are bash style, starting with # and go to the end of the line.<br />
<br />
'''''Duplicate Rules''''' - If you prepend the ''flush table filter'' line at the very beginning of the ''filter-table'' file, you achieve atomic rule-set replacement equivalent to what ''iptables-restore'' provides. The kernel handles the rule commands in the file in one single transaction, so basically the flushing and the load of the new rules happens in one single shot. If you choose not to flush your tables then you will see duplicate rules for each time you reloaded the config.<br />
<br />
'''''Flushing Sets''''' - ''flush table filter'' will not flush any sets defined in that table. To flush sets as well, use ''flush ruleset'' (not available in Linux 3.16 or below) or delete the sets explicitly. Early versions (Linux <=3.16) do not allow you to import a set if it already exists, but this is allowed in later versions.<br />
<br />
'''''Nftables Config File Formats''''' - ''nft -f <filename>'' accepts 2 formats, the first is the format seen in the output of ''nft list table''. The second is [[Scripting]] and is the format you typically see on this website.<br />
<br />
Example of nftables output format:<br />
<br />
<source lang="bash"><br />
% nft list table ip nat<br />
table ip nat {<br />
chain prerouting {<br />
type filter hook prerouting priority 0; policy accept;<br />
}<br />
<br />
chain postrouting {<br />
type filter hook postrouting priority 100; policy accept;<br />
}<br />
}<br />
</source><br />
<br />
Example of scripted config format:<br />
<br />
<source lang="bash"><br />
#!/usr/sbin/nft -f<br />
<br />
define ntp_servers = { 84.77.40.132, 176.31.53.99, 81.19.96.148, 138.100.62.8 }<br />
<br />
add table filter<br />
add chain filter input { type filter hook input priority 0; }<br />
add rule filter input ip saddr $ntp_servers counter<br />
</source><br />
<br />
'''Combining multiple files'''<br />
<br />
''What happens when you include 2 files which each have a statement for the filter table?''<br />
<br />
If you have two files, both ''include''d, both with statements for the filter table, but one adds a rule allowing traffic from 192.168.1.1 and the other allows traffic from 192.168.1.2 then both rules will be included in the chain, even if one or both files contains a flush statement.<br />
<br />
''What about flush statements in either, or neither file?''<br />
<br />
If there are any flush commands in any included file then those will be run at the moment the config swap is executed, not at the moment the file is loaded. If you do not include a flush statement in any included file, you will get duplicate rules. If you do include a flush statement, you will not get duplicate rules and the config from *both* files will be included. <br />
<br />
'''Converting between formats'''<br />
<br />
The easiest way to convert from scripted config format to output-based is to run the commands and then show the nftables config with ''nft list table ip filter'' and then copy/paste that into your config file.<br />
The easiest way to convert from output-based to scripted based is to lookup the equivalent on this wiki.</div>Jeff.wellinghttp://wiki.nftables.org/wiki-nftables/index.php?title=Advanced_ruleset_for_dynamic_environments&diff=248Advanced ruleset for dynamic environments2018-01-26T00:17:28Z<p>Jeff.welling: Started working on a more advanced config that supports service discovery</p>
<hr />
<div>'''This page is an unvetted draft'''<br />
<br />
Today's modern computing environments require features like Service Discovery and the environments themselves can be quite dynamic and rapidly changing. One of the ways nftables can help is by breaking firewall config into small pieces which can by dynamically generated by the likes of [https://www.consul.io/ Consul] and [https://www.hashicorp.com/blog/introducing-consul-template Consul Template], [https://www.vaultproject.io/ Vault], or config management like [https://www.chef.io/solutions/infrastructure-automation/ Chef] [https://puppet.com/ Puppet] or [https://www.ansible.com/ Ansible].<br />
<br />
<br />
<br />
'''/etc/nftables.start.conf'''<br />
Creates tables<br />
Loads /etc/nftables.conf<br />
<br />
'''/etc/nftables.conf'''<br />
Loads table-specific entries like /etc/nft.conf.d/nftables.ip.filter.conf and /etc/nft.conf.d/nftables.ip.nat.conf<br />
Loads Sets main file /etc/nft.conf.d/main.conf<br />
<br />
'''/etc/nft.conf.d/main.conf'''<br />
Loads each individual Set, because nftables doesn't support wildcards in ''include'' statements (/etc/nft.conf.d/sets.d/trusted_ips.conf)<br />
<br />
'''/etc/nft.conf.d/nftables.ip.filter.conf'''<br />
Configures the 'ip filter' table<br />
<br />
'''/etc/nft.conf.d/nftables.ip.nat.conf'''<br />
Configures the 'ip nat' table</div>Jeff.wellinghttp://wiki.nftables.org/wiki-nftables/index.php?title=Atomic_rule_replacement&diff=247Atomic rule replacement2018-01-26T00:00:36Z<p>Jeff.welling: Add notes for how flush behaves when including multiple files</p>
<hr />
<div>== Warning about Shell scripting + nftables ==<br />
<br />
With iptables it was common to use a bash script comprised of multiple iptables commands to configure a firewall. This is sub-optimal because it is not atomic, that is to say that during the few fractions of a second that your bash script takes to run your firewall is in a partially configured state. Nftables introduces atomic rule replacement with the ''-f'' option. This is different from bash scripts because nftables will read in all of the included config files, create the config object in memory alongside the existing config, and then in one atomic operation it swaps the old config for the new one meaning there is no moment when the firewall is partially configured. <br />
<br />
== Atomic Rule Replacement ==<br />
<br />
You can use the ''-f'' option to atomically update your rule-set:<br />
<br />
<source lang="bash"><br />
% nft -f file<br />
</source><br />
<br />
Where ''file'' contains your rule-set.<br />
<br />
You can save your rule-set by storing the existing listing in a file, ie.<br />
<br />
<source lang="bash"><br />
% nft list table filter > filter-table<br />
</source><br />
<br />
Then you can restore it by using the ''-f'' option:<br />
<br />
<source lang="bash"><br />
% nft -f filter-table<br />
</source><br />
<br />
'''Notes:''' <br />
<br />
'''''Table Creation''''' - you may have to create the table with ''nft create table ip filter'' before you can load the file exported with ''nft list table filter > filter-table'' otherwise you will hit errors because the table does not exist.<br />
<br />
'''''Comments''''' - You can also add comments to the ''filter-table'' file. Comments are bash style, starting with # and go to the end of the line.<br />
<br />
'''''Duplicate Rules''''' - If you prepend the ''flush table filter'' line at the very beginning of the ''filter-table'' file, you achieve atomic rule-set replacement equivalent to what ''iptables-restore'' provides. The kernel handles the rule commands in the file in one single transaction, so basically the flushing and the load of the new rules happens in one single shot. If you choose not to flush your tables then you will see duplicate rules for each time you reloaded the config.<br />
<br />
'''''Flushing Sets''''' - ''flush table filter'' will not flush any sets defined in that table. To flush sets as well, use ''flush ruleset'' (not available in Linux 3.16 or below) or delete the sets explicitly. Early versions (Linux <=3.16) do not allow you to import a set if it already exists, but this is allowed in later versions.<br />
<br />
'''''Nftables Config File Formats''''' - ''nft -f <filename>'' accepts 2 formats, the first is the format seen in the output of ''nft list table''. The second is [[Scripting]] and is the format you typically see on this website.<br />
<br />
Example of nftables output format:<br />
<br />
<source lang="bash"><br />
% nft list table ip nat<br />
table ip nat {<br />
chain prerouting {<br />
type filter hook prerouting priority 0; policy accept;<br />
}<br />
<br />
chain postrouting {<br />
type filter hook postrouting priority 100; policy accept;<br />
}<br />
}<br />
</source><br />
<br />
Example of scripted config format:<br />
<br />
<source lang="bash"><br />
% nft add table nat<br />
% nft add chain nat prerouting { type nat hook prerouting priority 0 \; }<br />
% nft add chain nat postrouting { type nat hook postrouting priority 100 \; }<br />
</source><br />
<br />
'''Combining multiple files'''<br />
<br />
''What happens when you include 2 files which each have a statement for the filter table?''<br />
<br />
If you have two files, both ''include''d, both with statements for the filter table, but one adds a rule allowing traffic from 192.168.1.1 and the other allows traffic from 192.168.1.2 then both rules will be included in the chain, even if one or both files contains a flush statement.<br />
<br />
''What about flush statements in either, or neither file?''<br />
<br />
If there are any flush commands in any included file then those will be run at the moment the config swap is executed, not at the moment the file is loaded. If you do not include a flush statement in any included file, you will get duplicate rules. If you do include a flush statement, you will not get duplicate rules and the config from *both* files will be included. <br />
<br />
'''Converting between formats'''<br />
<br />
The easiest way to convert from scripted config format to output-based is to run the commands and then show the nftables config with ''nft list table ip filter'' and then copy/paste that into your config file.<br />
The easiest way to convert from output-based to scripted based is to lookup the equivalent on this wiki.</div>Jeff.wellinghttp://wiki.nftables.org/wiki-nftables/index.php?title=Atomic_rule_replacement&diff=246Atomic rule replacement2018-01-25T23:40:34Z<p>Jeff.welling: Minor formatting fix</p>
<hr />
<div>== Warning about Shell scripting + nftables ==<br />
<br />
With iptables it was common to use a bash script comprised of multiple iptables commands to configure a firewall. This is sub-optimal because it is not atomic, that is to say that during the few fractions of a second that your bash script takes to run your firewall is in a partially configured state. Nftables introduces atomic rule replacement with the ''-f'' option. This is different from bash scripts because nftables will read in all of the included config files, create the config object in memory alongside the existing config, and then in one atomic operation it swaps the old config for the new one meaning there is no moment when the firewall is partially configured. <br />
<br />
== Atomic Rule Replacement ==<br />
<br />
You can use the ''-f'' option to atomically update your rule-set:<br />
<br />
<source lang="bash"><br />
% nft -f file<br />
</source><br />
<br />
Where ''file'' contains your rule-set.<br />
<br />
You can save your rule-set by storing the existing listing in a file, ie.<br />
<br />
<source lang="bash"><br />
% nft list table filter > filter-table<br />
</source><br />
<br />
Then you can restore it by using the ''-f'' option:<br />
<br />
<source lang="bash"><br />
% nft -f filter-table<br />
</source><br />
<br />
'''Notes:''' <br />
<br />
'''''Table Creation''''' - you may have to create the table with ''nft create table ip filter'' before you can load the file exported with ''nft list table filter > filter-table'' otherwise you will hit errors because the table does not exist.<br />
<br />
'''''Comments''''' - You can also add comments to the ''filter-table'' file. Comments are bash style, starting with # and go to the end of the line.<br />
<br />
'''''Duplicate Rules''''' - If you prepend the ''flush table filter'' line at the very beginning of the ''filter-table'' file, you achieve atomic rule-set replacement equivalent to what ''iptables-restore'' provides. The kernel handles the rule commands in the file in one single transaction, so basically the flushing and the load of the new rules happens in one single shot. If you choose not to flush your tables then you will see duplicate rules for each time you reloaded the config.<br />
<br />
'''''Flushing Sets''''' - ''flush table filter'' will not flush any sets defined in that table. To flush sets as well, use ''flush ruleset'' (not available in Linux 3.16 or below) or delete the sets explicitly. Early versions (Linux <=3.16) do not allow you to import a set if it already exists, but this is allowed in later versions.<br />
<br />
'''''Nftables Config File Formats''''' - ''nft -f <filename>'' accepts 2 formats, the first is the format seen in the output of ''nft list table''. The second is [[Scripting]] and is the format you typically see on this website.<br />
<br />
Example of nftables output format:<br />
<br />
<source lang="bash"><br />
% nft list table ip nat<br />
table ip nat {<br />
chain prerouting {<br />
type filter hook prerouting priority 0; policy accept;<br />
}<br />
<br />
chain postrouting {<br />
type filter hook postrouting priority 100; policy accept;<br />
}<br />
}<br />
</source><br />
<br />
Example of scripted config format:<br />
<br />
<source lang="bash"><br />
% nft add table nat<br />
% nft add chain nat prerouting { type nat hook prerouting priority 0 \; }<br />
% nft add chain nat postrouting { type nat hook postrouting priority 100 \; }<br />
</source><br />
<br />
'''Converting between formats'''<br />
<br />
The easiest way to convert from scripted config format to output-based is to run the commands and then show the nftables config with ''nft list table ip filter'' and then copy/paste that into your config file.<br />
The easiest way to convert from output-based to scripted based is to lookup the equivalent on this wiki.</div>Jeff.wellinghttp://wiki.nftables.org/wiki-nftables/index.php?title=Atomic_rule_replacement&diff=245Atomic rule replacement2018-01-25T23:39:32Z<p>Jeff.welling: Noted the 2 possible formats for 'nft -f', reworked the Notes section, expanded on shell scripting vs atomic replacement</p>
<hr />
<div>== Warning about Shell scripting + nftables ==<br />
<br />
With iptables it was common to use a bash script comprised of multiple iptables commands to configure a firewall. This is sub-optimal because it is not atomic, that is to say that during the few fractions of a second that your bash script takes to run your firewall is in a partially configured state. Nftables introduces atomic rule replacement with the ''-f'' option. This is different from bash scripts because nftables will read in all of the included config files, create the config object in memory alongside the existing config, and then in one atomic operation it swaps the old config for the new one meaning there is no moment when the firewall is partially configured. <br />
<br />
== Atomic Rule Replacement ==<br />
<br />
You can use the ''-f'' option to atomically update your rule-set:<br />
<br />
<source lang="bash"><br />
% nft -f file<br />
</source><br />
<br />
Where ''file'' contains your rule-set.<br />
<br />
You can save your rule-set by storing the existing listing in a file, ie.<br />
<br />
<source lang="bash"><br />
% nft list table filter > filter-table<br />
</source><br />
<br />
Then you can restore it by using the ''-f'' option:<br />
<br />
<source lang="bash"><br />
% nft -f filter-table<br />
</source><br />
<br />
'''Notes:''' <br />
<br />
'''''Table Creation''''' - you may have to create the table with ''nft create table ip filter'' before you can load the file exported with ''nft list table filter > filter-table'' otherwise you will hit errors because the table does not exist.<br />
<br />
'''''Comments''''' - You can also add comments to the ''filter-table'' file. Comments are bash style, starting with # and go to the end of the line.<br />
<br />
'''''Duplicate Rules''''' - If you prepend the ''flush table filter'' line at the very beginning of the ''filter-table'' file, you achieve atomic rule-set replacement equivalent to what ''iptables-restore'' provides. The kernel handles the rule commands in the file in one single transaction, so basically the flushing and the load of the new rules happens in one single shot. If you choose not to flush your tables then you will see duplicate rules for each time you reloaded the config.<br />
<br />
'''''Flushing Sets''''' - ''flush table filter'' will not flush any sets defined in that table. To flush sets as well, use ''flush ruleset'' (not available in Linux 3.16 or below) or delete the sets explicitly. Early versions (Linux <=3.16) do not allow you to import a set if it already exists, but this is allowed in later versions.<br />
<br />
'''''Nftables Config File Formats''''' - ''nft -f <filename>'' accepts 2 formats, the first is the format seen in the output of ''nft list table''. The second is [[Scripting]] and is the format you typically see on this website.<br />
<br />
Example of nftables output format:<br />
<br />
<source lang="bash"><br />
% nft list table ip nat<br />
table ip nat {<br />
chain prerouting {<br />
type filter hook prerouting priority 0; policy accept;<br />
}<br />
<br />
chain postrouting {<br />
type filter hook postrouting priority 100; policy accept;<br />
}<br />
}<br />
</source><br />
<br />
Example of scripted config format:<br />
<br />
<source lang="bash"><br />
% nft add table nat<br />
% nft add chain nat prerouting { type nat hook prerouting priority 0 \; }<br />
% nft add chain nat postrouting { type nat hook postrouting priority 100 \; }<br />
</source><br />
<br />
'''Converting between formats'''<br />
<br />
The easiest way to convert from scripted config format to output-based is to run the commands and then show the nftables config with ''nft list table <table name>'' and then copy/paste that into your config file.<br />
The easiest way to convert from output-based to scripted based is to lookup the equivalent on this wiki.</div>Jeff.wellinghttp://wiki.nftables.org/wiki-nftables/index.php?title=Configuring_tables&diff=226Configuring tables2017-12-12T07:57:03Z<p>Jeff.welling: Note 'nft list tables'</p>
<hr />
<div>= Adding tables =<br />
<br />
<source lang="bash"><br />
% nft add table ip filter<br />
</source><br />
<br />
= Show/List tables =<br />
<br />
<source lang="bash"><br />
% nft list tables<br />
</source><br />
<br />
= Deleting tables =<br />
<br />
<source lang="bash"><br />
% nft delete table ip foo<br />
</source><br />
<br />
'''Troubleshooting''': Since Linux kernel 3.18, you can delete tables and its content with this command. However, before that version, you need to delete its content first, otherwise you hit an error that look like this:<br />
<br />
<source lang="bash"><br />
% nft delete table filter<br />
<cmdline>:1:1-19: Error: Could not delete table: Device or resource busy<br />
delete table filter<br />
^^^^^^^^^^^^^^^^^^^<br />
</source><br />
<br />
= Flushing tables =<br />
<br />
You can delete all the rules that belong to this table with the following command:<br />
<br />
<source lang="bash"><br />
% nft flush table ip filter<br />
</source><br />
<br />
This removes the rules ''for every chain'' that you register in that table.</div>Jeff.wellinghttp://wiki.nftables.org/wiki-nftables/index.php?title=Main_Page&diff=140Main Page2017-05-07T19:48:26Z<p>Jeff.welling: Added to Videos: Pablo's Goodbye iptables Hello nftables talk</p>
<hr />
<div>Welcome to the ''nftables'' HOWTO documentation page. Here you will find documentation on how to build, install, configure and use nftables.<br />
<br />
This documentation was initially started by Eric Leblond, known as the [https://home.regit.org/netfilter-en/nftables-quick-howto/ nftables quick HOWTO], and it has been extended and enhanced by Pablo Neira Ayuso.<br />
<br />
If you have any suggestion to improve it, please send your comments to Netfilter users mailing list <netfilter@vger.kernel.org>.<br />
<br />
Note that this documentation is still under development, so '''consider this work in progress'''.<br />
<br />
= Introduction =<br />
<br />
* [[What is nftables?]]<br />
* [[Why nftables?]]<br />
* [[Main differences with iptables]]<br />
* [[Netfilter hooks]] and integration with existing Netfilter components.<br />
<br />
= Getting started =<br />
<br />
* [[Building and installing nftables from sources]]<br />
* Using [[nftables from distributions]]<br />
* [[Troubleshooting|Troubleshooting and FAQ]]<br />
* [[Quick reference-nftables in 10 minutes|Quick reference, nftables in 10 minutes]]<br />
* [https://2nft.alemayhu.com/ Translate your iptables rules from a web app]<br />
<br />
= Basic operation =<br />
<br />
* [[Configuring tables]]<br />
* [[Configuring chains]]<br />
* [[Simple rule management]]<br />
* [[Atomic rule replacement]]<br />
* [[Error reporting from the command line]]<br />
* [[Building rules through expressions]]<br />
* [[Operations at ruleset level]]<br />
* [[Monitoring ruleset updates]]<br />
* [[Scripting]]<br />
* [[Ruleset debug/tracing]]<br />
* [[Moving from iptables to nftables]]<br />
<br />
= Supported selectors for packet matching =<br />
<br />
* [[Matching packet header fields]]<br />
* [[Matching packet metainformation]]<br />
* [[Matching connection tracking stateful metainformation]]<br />
* [[Rate limiting matchings]]<br />
* [[Routing information]]<br />
<br />
= Possible actions on packets =<br />
<br />
* [[Accepting and dropping packets]]<br />
* [[Jumping to chain]]<br />
* [[Rejecting traffic]]<br />
* [[Logging traffic]]<br />
* [[Performing Network Address Translation (NAT)]]<br />
* [[Setting packet metainformation]]<br />
* [[Queueing to userspace]]<br />
* [[Duplicating packets]]<br />
* [[Mangle packet header fields]]<br />
* [[Counters]]<br />
* [[Load balancing]]<br />
* [[Setting packet connection tracking metainformation]]<br />
<br />
Note that, unlike ''iptables'', you can perform several actions in one single rule.<br />
<br />
= Advanced data structures for performance packet classification =<br />
<br />
You will have to redesign your rule-set to benefit from these new nice features:<br />
<br />
* [[Sets]]<br />
* [[Dictionaries]]<br />
* [[Intervals]]<br />
* [[Maps]]<br />
* [[Concatenations]]<br />
* [[Flow tables]]<br />
* [[Updating sets from the packet path]]<br />
* [[Element timeouts]]<br />
* [[Math operations]]<br />
* [[Stateful objects]]<br />
<br />
If you are already using [[ipset]] in your ''iptables'' rule-set, that transition may be a bit more simple to you.<br />
<br />
= Examples =<br />
<br />
* [[Simple ruleset for a workstation]]<br />
* [[Bridge filtering]]<br />
* [[Multiple NATs using nftables maps]]<br />
* [[Classic perimetral firewall example]]<br />
<br />
= Development progress =<br />
<br />
* [[List of updates since Linux kernel 3.13]]<br />
* [[Supported features compared to xtables|Supported features compared to {ip,ip6,eb,arp}tables]]<br />
* [[List of available translations via iptables-translate tool]]<br />
<br />
= Videos =<br />
<br />
* Watch [https://www.youtube.com/watch?v=FXTRRwXi3b4 Getting a grasp of nftables], thanks to [https://www.nluug.nl/index-en.html NLUUG association] for recording this.<br />
* [https://www.youtube.com/watch?v=Sy0JDX451ns Florian Westphal - Why nftables?]<br />
* Watch [https://www.youtube.com/watch?v=qXVOA2MKA1s Netdev 2.1 - Netfilter workshop]<br />
* Watch [https://www.youtube.com/watch?v=0wQfSfDVN94 NLUUG - Goodbye iptables, Hello nftables]<br />
<br />
= Thanks =<br />
<br />
To the NLnet foundation for initial sponsorship of this HOWTO:<br />
<br />
[https://nlnet.nl https://nlnet.nl/image/logo.gif]</div>Jeff.wellinghttp://wiki.nftables.org/wiki-nftables/index.php?title=Atomic_rule_replacement&diff=121Atomic rule replacement2017-03-01T03:18:36Z<p>Jeff.welling: Match existing formatting</p>
<hr />
<div>You can use the ''-f'' option to atomically update your rule-set:<br />
<br />
<source lang="bash"><br />
% nft -f file<br />
</source><br />
<br />
Where ''file'' contains your rule-set.<br />
<br />
You can save your rule-set by storing the existing listing in a file, ie.<br />
<br />
<source lang="bash"><br />
% nft list table filter > filter-table<br />
</source><br />
<br />
Then you can restore it by using the ''-f'' option:<br />
<br />
<source lang="bash"><br />
% nft -f filter-table<br />
</source><br />
<br />
You can also add comments to the ''filter-table'' file. Comments are bash style, starting with # and go to the end of the line.<br />
<br />
If you prepend the ''flush table filter'' line at the very beginning of the ''filter-table'' file, you achieve atomic rule-set replacement equivalent to what ''iptables-restore'' provides. The kernel handles the rule commands in the file in one single transaction, so basically the flushing and the load of the new rules happens in one single shot.<br />
<br />
Note: ''flush table filter'' will not flush any sets defined in that table. To flush sets as well, use ''flush ruleset'' (not available in Linux 3.16 or below) or delete the sets explicitly. Early versions (Linux <=3.16) do not allow you to import a set if it already exists, but this is allowed in later versions.<br />
<br />
<br />
== Shell Scripting ==<br />
<br />
Some people prefer to maintain a shell script file with the rule-set. '''Beware of that approach, you cannot achieve atomic rule-set updates with a shell script file'''. Therefore, the best way to go is to use the native [[Scripting|nftables scripting capabilities]] and to restore your rule-set via ''nft -f''.</div>Jeff.wellinghttp://wiki.nftables.org/wiki-nftables/index.php?title=Atomic_rule_replacement&diff=120Atomic rule replacement2017-03-01T03:17:45Z<p>Jeff.welling: Noted ability to add comments to filter-file, and caveats of flush table filter</p>
<hr />
<div>You can use the ''-f'' option to atomically update your rule-set:<br />
<br />
<source lang="bash"><br />
% nft -f file<br />
</source><br />
<br />
Where ''file'' contains your rule-set.<br />
<br />
You can save your rule-set by storing the existing listing in a file, ie.<br />
<br />
<source lang="bash"><br />
% nft list table filter > filter-table<br />
</source><br />
<br />
Then you can restore it by using the ''-f'' option:<br />
<br />
<source lang="bash"><br />
% nft -f filter-table<br />
</source><br />
<br />
You can also add comments to the filter-table file. Comments are bash style, starting with # and go to the end of the line.<br />
<br />
If you prepend the ''flush table filter'' line at the very beginning of the ''filter-table'' file, you achieve atomic rule-set replacement equivalent to what ''iptables-restore'' provides. The kernel handles the rule commands in the file in one single transaction, so basically the flushing and the load of the new rules happens in one single shot.<br />
<br />
Note: ''flush table filter'' will not flush any sets defined in that table. To flush sets as well, use ''flush ruleset'' (not available in Linux 3.16 or below) or delete the sets explicitly. Early versions (Linux <=3.16) do not allow you to import a set if it already exists, but this is allowed in later versions.<br />
<br />
<br />
== Shell Scripting ==<br />
<br />
Some people prefer to maintain a shell script file with the rule-set. '''Beware of that approach, you cannot achieve atomic rule-set updates with a shell script file'''. Therefore, the best way to go is to use the native [[Scripting|nftables scripting capabilities]] and to restore your rule-set via ''nft -f''.</div>Jeff.wellinghttp://wiki.nftables.org/wiki-nftables/index.php?title=Configuring_tables&diff=119Configuring tables2017-03-01T02:22:53Z<p>Jeff.welling: Added 'Adding tables' section</p>
<hr />
<div>= Adding tables =<br />
<br />
<source lang="bash"><br />
% nft add table ip filter<br />
</source><br />
<br />
You can also delete tables with the following command:<br />
<br />
= Deleting tables =<br />
<br />
<source lang="bash"><br />
% nft delete table ip foo<br />
</source><br />
<br />
'''Troubleshooting''': Since Linux kernel 3.18, you can delete tables and its content with this command. However, before that version, you need to delete its content first, otherwise you hit an error that look like this:<br />
<br />
<source lang="bash"><br />
% nft delete table filter<br />
<cmdline>:1:1-19: Error: Could not delete table: Device or resource busy<br />
delete table filter<br />
^^^^^^^^^^^^^^^^^^^<br />
</source><br />
<br />
= Flushing tables =<br />
<br />
You can delete all the rules that belong to this table with the following command:<br />
<br />
<source lang="bash"><br />
% nft flush table ip filter<br />
</source><br />
<br />
This removes the rules ''for every chain'' that you register in that table.</div>Jeff.welling