Hi, > Is "flush ruleset" at the very beginning of your firewall.nft file? Yes it is, since when I run 'nft -f /etc/nftables/firewall.nft' I don't want to end up with duplicate rules. Even if I didn't explicitly put the 'flush statement' at the top of my /etc/nftables/firewall.nft file, the systemd nftables.service file in Fedora/RHEL/CentOS also flushes the ruleset before re-applying the rules when running 'systemctl reload nftables', which I have always perceived as a proper way to pull in firewall rule changes: [root@localhost system]# grep Reload /usr/lib/systemd/system/nftables.service ExecReload=/sbin/nft 'flush ruleset; include "/etc/sysconfig/nftables.conf";' My whole way of thinking about atomic rule replacement is based on https://wiki.nftables.org/wiki-nftables/index.php/Atomic_rule_replacement, where it states that: "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." Granted, I am have been using "flush ruleset" at the beginning of the file, instead of the stated "flush table filter". However, since I may have multiple tables in the file (filter, nat, etc.) with indeterminate names, I went and assumed that "flush ruleset" was an all-encompassing alternative to individual "flush table <tablename>" statements. That being said, I ran a test by replacing "flush ruleset" at the top of my firewall.nft file with "flush table inet x" and I was surprised to discover that, while "flush table inet x" *does* remove all configured rules, thereby preventing duplicate rules, it does _not_ remove the devices from the flow table. So: [root@localhost system]# cat /etc/nftables/firewall.nft flush table inet x table inet x { flowtable f { hook ingress priority 0; } chain y { type filter hook forward priority 0; policy accept; ip protocol tcp flow offload @f counter packets 0 bytes 0 tcp dport 80 } } [root@localhost system]# nft -f /etc/nftables/firewall.nft [root@localhost system]# nft list ruleset table inet x { flowtable f { hook ingress priority filter } chain y { type filter hook forward priority filter; policy accept; ip protocol tcp flow add @f counter packets 0 bytes 0 tcp dport 80 } } [root@localhost system]# nft add flowtable inet x f { hook ingress priority filter \; devices = { br0 } \; } [root@localhost system]# nft list ruleset table inet x { flowtable f { hook ingress priority filter devices = { br0 } } chain y { type filter hook forward priority filter; policy accept; ip protocol tcp flow add @f counter packets 0 bytes 0 tcp dport 80 } } [root@localhost system]# nft -f /etc/nftables/firewall.nft [root@localhost system]# nft list ruleset table inet x { flowtable f { hook ingress priority filter devices = { br0 } } chain y { type filter hook forward priority filter; policy accept; ip protocol tcp flow add @f counter packets 0 bytes 0 tcp dport 80 } } Whereas: [root@localhost system]# cat /etc/nftables/firewall.nft flush ruleset table inet x { flowtable f { hook ingress priority 0; } chain y { type filter hook forward priority 0; policy accept; ip protocol tcp flow offload @f counter packets 0 bytes 0 tcp dport 80 } } [root@localhost system]# nft -f /etc/nftables/firewall.nft [root@localhost system]# nft list ruleset table inet x { flowtable f { hook ingress priority filter } chain y { type filter hook forward priority filter; policy accept; ip protocol tcp flow add @f counter packets 0 bytes 0 tcp dport 80 } } [root@localhost system]# nft add flowtable inet x f { hook ingress priority filter \; devices = { br0 } \; } [root@localhost system]# nft list ruleset table inet x { flowtable f { hook ingress priority filter devices = { br0 } } chain y { type filter hook forward priority filter; policy accept; ip protocol tcp flow add @f counter packets 0 bytes 0 tcp dport 80 } } [root@localhost system]# nft -f /etc/nftables/firewall.nft [root@localhost system]# nft list ruleset table inet x { flowtable f { hook ingress priority filter } chain y { type filter hook forward priority filter; policy accept; ip protocol tcp flow add @f counter packets 0 bytes 0 tcp dport 80 } } This difference in behavior then begets a new question: Does prepending the "more destructive" 'flush ruleset' statement at the very beginning of the 'firewall.nft' file still honor the "atomicity" guarantee of running 'nft -f' again this file, or is this guarantee only honored when prepending 'flush table' statements? In other words, is there a minute period after running 'flush ruleset' in my file where the node is unprotected? Thanks for your time, -Martin