Re: using nft & iptables nat in parallel

[Florian Westphal <fw@strlen.de>]

Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> 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?

First match would win because nf_nat_initialized() is true, just like:

-j MASQUERADE
-p tcp --dport 42 -j SNAT ... # no-op

> > > 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).

Hmm, we can discuss this again during nfws, but I abandoned this
idea (it provides too much rope for ppl to hang themselvers with :-) )

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

The (inclomplete, sigh) patches have a hybrid solution which is
worst-of-both-worlds hooking-wise, i.e. you do explicit tracking
request but there is still an implicit hook to catch related and
reply traffic.