Re: Trying to provision flowtable returns error

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux