iptables-legacy + iptables-nft = iptables-broken ?

[Rafael David Tinoco]

> This means that the POLICY has acted in all those table/chains 
> combination, NOT the rules I have in place. So, if I change the default 
> policy using iptables-legacy to -j DROP... then my iptables-nft rules 
> don't work at all. This means that one should really use 
> iptables-legacy (and not nft) to setup default policies. Is that 
> correct ? And.. if such, why to have nft enabled by default if it 
> cannot work solo when xtables are enabled.
> 
> Concern:
> 
> One could have a default Ubuntu server installation, with a bunch of 
> iptables (legacy) rules brought by Bionic, for example, and think is 
> secure but.. "-j DROP" for the DEFAULT iptables-nft could be doing 
> nothing regarding flow controlling.
> 
> Is that so ? Did I miss anything ? Should we do something if I did not ?
> 

My point here: 

iptables-nft (our default tool) creates nft tables by default:

[rafaeldtinoco at fujitsu conntracker]$ sudo iptables -t nat -L
# Warning: iptables-legacy tables present, use iptables-legacy to see them
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

[rafaeldtinoco at fujitsu conntracker]$ sudo nft list table ip nat
table ip nat {
        chain PREROUTING {
                type nat hook prerouting priority dstnat; policy accept;
        }

        chain INPUT {
                type nat hook input priority 100; policy accept;
        }

        chain POSTROUTING {
                type nat hook postrouting priority srcnat; policy accept;
        }

        chain OUTPUT {
                type nat hook output priority -100; policy accept;
        }
}

and also enables kernel modules by default:

nft_chain_nat          16384  4
nf_nat                 49152  1 nft_chain_nat
nf_tables             196608  1 nft_chain_nat
nf_conntrack          147456  2 xt_conntrack,nf_nat

and then iptables-legacy command, packaged *together* with iptables-nft... will also load its modules:

[rafaeldtinoco at fujitsu conntracker]$ sudo iptables-legacy -t nat -L

iptable_nat            16384  0
nft_chain_nat          16384  4
nf_nat                 49152  2 nft_chain_nat,iptable_nat
nf_tables             196608  1 nft_chain_nat
nf_conntrack          147456  2 xt_conntrack,nf_nat
ip_tables              32768  2 iptable_nat,iptable_mangle

and we started the compatibility issue where nft firewall code won't be enough when processing xtables (like changing default policy). We have both worlds enabled at the same time - iptable_nat (for iptables-legacy) and nf_nat (for nf_tables) -  and we incur in this issue I described (both tools using xtables for packet matching at the end ... when they should NOT coexist, likely because of reasons I described in previous e-mail).

Shouldn't we be telling our users to disable entirely iptables-legacy if using nft (and vice-versa) ? And splitting iptables-nft and iptables-legacy from the same package so the kernel modules are not loaded automatically ? And checking if there is a way to blacklist iptables modules here and there ?

Is this analysis correct ?