On Wed, Jun 14, 2017 at 01:19:34PM +0200, Florian Westphal wrote: > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > On Wed, Jun 14, 2017 at 11:58:03AM +0200, Florian Westphal wrote: > > > Arturo Borrero Gonzalez <arturo@xxxxxxxxxx> wrote: > > > > I'm curious, What is the use case of using both nftables and iptables > > > > at the same time? > > > > Some missing functionality in nft? > > > > Perhaps some ipt->nft partial migration procedure? > > > > > > Yes, partial migration. > > > > > > Right now there are an awful lot of tools out there (docker, libvirt, > > > kubernetes, ..) that call iptables(-restore) directly (or inject them via > > > firewalld). > > > > > > And unfortunately I don't see how we can magically move all of this > > > to nftables. > > > > > > So allowing to do a step-by-step migration seems the only viable > > > option. > > > > We have iptables-compat-restore, this uses the nf_tables netlink > > frontend and packet classification code, plus x_tables extensions to > > run iptables code. It should allow us to schedule the x_tables core > > for removal at some point. > > Yes, perhaps. > > > In Montpellier, we mentioned that distro could add a iptables-restore > > symlink to iptables-compat-restore so it becomes visible that we're > > relying on the compat infrastructure. > > > > This iptables-compat-restore interacts with nft via translate layer, > > so if you just 'nft list ruleset' after using iptables-compat-restore, > > you will get a translation (if available). > > That still means drastic change, swapping out xt_core for nftables > rather than using "old" iptables is still a big difference... Not drastic. The idea is that compat provides same semantics. Did you give it a try to evaluate the state of this? I would be glad to see feedback on this. We can probably get some GSoC people helping us polish this... > I also think that ability to use both iptables or nftables nat > is a good thing, since it lowers barrier to 'just try it' without > having to unload iptable_nat and friends. Don't get me wrong, I'm not opposing to your idea of get both working if you want to work on this if you think this is useful. The extra hook has a performance impact though, is it something that would just go away one x_tables is gone? What is your plan on this? On a different front (just an idea), I would really like to provide an alternative to setting conntrack templates, so we can get rid of having a chain (hence another hook) just to set the zone. It's just more cycles on a hook to do something very simple. > Also forgot to mention: this will allow to use nat base chains > in multiple tables (even though it is probably not a good idea to do > that due to possible problems because of unexpected/different evaluation > order). nftables NAT configuration needs a closer look indeed, we should probably autoregister the hook that are needed without having to require the user to register explicitly an empty chain as the documentation suggest now. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
