Re: using nft & iptables nat in parallel

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Wed, Jun 14, 2017 at 01:53:38PM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> 
> > 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?
> 
> Once we do it we can't remove it again, because you can have multiple
> nat base chains after this change, and removing hook and merging it back
> into the l3 nat code means first chain attaches a null binding again.

With multiple nat chains, in case of overlap, we would just take the
last coming in the pipeline. Just like several chains several times
the same packet from a filter chain, right?

> > 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.
> 
> I don't think it can be done, the zone id has to be set before conntrack
> lookup, I see no way to avoid this?
>
> So even if we find a way to transport zone id from one hook to the
> next (sans skb->nfct template) we still need one extra hook to
> configure/set the zone id to use.

Can we do this from rule? So we run sort of nf_conntrack_in() from a
expression that enables tracking? I remember you mentioned about ICMP
and related traffic, we just have to document how to configure this so
people don't shoot on the feet, ie. track both tcp and icmp if you
want to do this right with this selective tracking expressed in
positive logic (contrary to the notrack, negative, logic).

I guess you would need something like this for bridge conntrack
support, right?