Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > On Wed, Jun 14, 2017 at 01:53:38PM +0200, Florian Westphal wrote: > > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> 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. -- 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
