From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Florian Westphal <fw@strlen.de>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: nfqueue & bridge netfilter considered broken
Date: Tue, 6 Sep 2016 12:10:04 +0200 [thread overview]
Message-ID: <20160906101004.GA1874@salvia> (raw)
In-Reply-To: <20160902102244.GB506@breakpoint.cc>
On Fri, Sep 02, 2016 at 12:22:44PM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> 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.
Assuming nf_nat_setup_info() was not yet called, ie. NAT from
postrouting case, then these packets with a deep copy and the flag set
may get different ports given the port clash resolution, then the
clash resolution would need to unmangle packets to get them back to a
consistent configuration.
This is something that can only happen from nfqueue if any of the
multiqueues approach is used to distribute packets between several
CPUs, right?
next prev parent reply other threads:[~2016-09-06 10:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-02 9:08 nfqueue & bridge netfilter considered broken Florian Westphal
2016-09-02 9:58 ` Pablo Neira Ayuso
2016-09-02 10:00 ` Pablo Neira Ayuso
2016-09-02 10:22 ` Florian Westphal
2016-09-06 10:10 ` Pablo Neira Ayuso [this message]
2016-09-06 11:24 ` Florian Westphal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160906101004.GA1874@salvia \
--to=pablo@netfilter.org \
--cc=fw@strlen.de \
--cc=netfilter-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).