Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > On Fri, Sep 02, 2016 at 11:58:53AM +0200, Pablo Neira Ayuso wrote: > > On Fri, Sep 02, 2016 at 11:08:48AM +0200, Florian Westphal wrote: > > > I - discard extra nfct entry when cloning. Works, but obviously not > > > compatible in any way (the clones are INVALID). > > > > This approach is simple and it would only break when packets are > > flooded to all ports, actually this is not working anyway because of > > clashes at confirm, right? > > Hm, what about attaching the notrack conntrack for this case? This is what Patrick said last time this came up (source: http://marc.info/?l=netfilter-devel&m=131471329004889&w=2 ): "I don't think the clones should have invalid state, even untracked is very questionable since all packets should have NAT applied to them in the same way, connmarks might be used etc. We probably need to restore the above mentioned assumption somehow. One way would be to serialize reinjection of packets belonging to unconfirmed conntracks in nf_reinject or the queueing modules. Conntrack related stuff doesn't really belong there, but it seems like the easiest and safest fix to me." As for bridge conntrack, this is indeed a good question. Seems we will need to register a dedicated conntrack bridge hook that takes care of uncloning in FORWARD hook, i.e. add a hook in FORWARD that makes a deep copy of all unconfirmed conntracks if skb is cloned, and (once skb reaches nf_confirm) do a non-destructive clash resolution (accept instead of drop of the clashing entries should be enough). We have to sacrifice another status bit for this, or perhaps add a bridge conntrack extension to store such a clash hint though. Any other idea? -- 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
