Nft vs iptables-nft problems

[Snorch]

On the one hand we have examples of some rules which can be created with iptables-nft utility and can't be dumped/restored with nft utility, for instance:

ip6tables-nft -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 130 -j ACCEPT  # Multicast Listener Query [RFC2710]
ip6tables-nft -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 131 -j ACCEPT  # Multicast Listener Report [RFC2710]
ip6tables-nft -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 132 -j ACCEPT  # Multicast Listener Done [RFC2710]

or we have physdev or match-set compatibility rules in iptables-nft which are not supported in nft utility.

On the other hand nft utility can create tables with arbitrary names:

nft add table newtable

which can't be dumped or restored with iptables-nft.

I found an article where it is said that "Mixing iptables-nft and nft on the other hand is not unproblematic, either. A good rule of thumb to avoid issues is to not touch the tables iptables-nft creates with nft." https://www.redhat.com/en/blog/using-iptables-nft-hybrid-linux-firewall

Conclusion here is that nft and iptables-nft are completely incompatible between each other in terms of dumping nftables rules in CRIU, some simple rules created by one may work with another, but surely not all of them as the examples above point out.

When it comes to CRIU we don't know if nftables were created by nft or iptables-nft or even by both of them in the dumpee netns. So it's hard for CRIU to follow "not to mix" rule.

I've prepared a fix for this problem in Virtuozzo CRIU (where we have all kinds of rules in Virtuozzo containers both created with nft and iptables-nft) fork which looks for me more as a workaround:

So for now in Virtuozzo criu where we have all kinds of rules in containers both created with nft and iptables-nft I've prepared a fix which uses both nft and iptables-nft:
OpenVZ/vzcriu@d986e6d
OpenVZ/vzcriu@8baea43
And it works somehow.

Note: that I do not use libnft to call nft tool in it as I need to call iptables-nft directly anyways, so to be symmetric I call them both directly without library.

Question are: do we want this in mainstream? is there a better way?

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rst0git]

Question are: do we want this in mainstream? is there a better way?

It looks like we would need functionality similar to --nftables-mode in mainstream CRIU to fix the problem described in #2313.

@Snorch Would it be okay if I add these changes in #2323?

[Snorch]

Would it be okay if I add these changes in #2323?

@rst0git If it helps, sure, please do!

I just don't have so much time to port everything from OpenVZ repos (600+ patches) to mainstream, but if there is something useful in it - please don't hesitate to port it =)