[Bug 1748] nft masquerade commands make table nat unreadable by iptables-nft

[bugzilla-daemon at netfilter.org]

https://bugzilla.netfilter.org/show_bug.cgi?id=1748

--- Comment #3 from Phil Sutter <phil at nwl.cc> ---
Hi Thomas,

(In reply to Thomas Schlien from comment #2)
> thanks for the fast answer. I understand now that one should not mix up the
> two, but I can give you one example on our system where I didn't even knew
> that a rule was added via nft.
> 
> We have a server where some VMs are running in libvirt/QEMU/KVM and some in
> docker. One of the docker services is mailcow which itself starts 18 docker
> container. One of them is netfilter container which handles all the firewall
> rules settings. Unfortunately mailcow checks if nftables is installed on the
> host and if so the nft tool is used to handle the necessary rule injection
> in the firewall. This way I didn't even noticed that the table was
> "poisoned".

Yes, it's kind of a mess. Containers manipulating init netns firewall ruleset
is really bad design choice: Even when sticking to the same tool, mixing
different versions may lead to problems, too. This is also not a new problem,
it existed with legacy iptables as well. Though in the past it was much less
common to use multiple userspace root fs for privileged operations at the same
time.

> Isn't the idea to replace iptables by nftables one day? I think at least a
> lot of people do believe this as the mailcow example shows. Also the
> description of nftables on netfilter.org homepage leads to this assumption.
> But if this is the case there will be a transition phase where both tools
> will be used in parallel. So how should this be handled?

Yes, nftables is the designated successor of iptables. Mailcow is merely trying
to get things right as it has a hard time guessing whether iptables-nft or nft
may be used on the host. Though these types of games are expected when doing
such things.

Why should both tools be used in parallel? A transitioning mechanism may be to
pipe one's iptables ruleset dump through iptables-restore-translate and load
the output via nft after a reboot.

iptables-nft is a transitioning mechanism in that it allows one to disable some
legacy kernel modules, for instance. Also it is superior to legacy iptables in
that it doesn't have to depend on filesystem-based locking to avoid concurrent
kernel ruleset access.

There may be a version of iptables-nft in the future which does not use any
xtables extensions anymore and thus creates a ruleset which nft is able to
parse and recreate entirely. Right now transitioning in that direction is
problematic because it breaks older user space and thus causes more problems to
your use case.

Also there will never be a version of iptables-nft which supports everything
nft is able to emit, so full compatibility is impossible anyway.

> Btw. other rules that I inject, e.g., via `/usr/sbin/nft insert rule filter
> LIBVIRT_FWI oifname kvmnat meta l4proto 6 ip daddr ${GUEST_IP} tcp dport
> ${GUEST_PORT_SSH} accept comment \"Accept SSH traffic\"` are handled fine by
> iptables-nft.

Yes, in this case iptables-nft is able to parse the rule. If you dump'n'restore
it (i.e., call iptables-nft-save | iptables-nft-restore), you'll notice it
added a counter to the rule. Also it will convert the native nftables comment
into an xtables one (xt_comment.ko). So the next time you list the same rule
using nft, the comment will be gone.

BTW: 'meta l4proto 6' there is redundant, the 'tcp dport' match will
automatically add this as a dependency.

Cheers, Phil

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20240418/f6e56500/attachment.html>