Netdev Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Lukas Wunner <lukas@wunner.de>
To: Laura Garcia <nevola@gmail.com>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Jozsef Kadlecsik <kadlec@netfilter.org>,
	Florian Westphal <fw@strlen.de>,
	Netfilter Development Mailing list 
	<netfilter-devel@vger.kernel.org>,
	coreteam@netfilter.org, netdev@vger.kernel.org,
	Martin Mares <mj@ucw.cz>, Dmitry Safonov <0x7f454c46@gmail.com>,
	Thomas Graf <tgraf@suug.ch>, Alexei Starovoitov <ast@kernel.org>,
	David Miller <davem@davemloft.net>
Subject: Re: [PATCH nf-next 3/3] netfilter: Introduce egress hook
Date: Thu, 23 Apr 2020 18:05:42 +0200	[thread overview]
Message-ID: <20200423160542.d3f6yef4av2gqvur@wunner.de> (raw)
In-Reply-To: <CAF90-WgoteQXB9WQmeT1eOHA3GpPbwPCEvNzwKkN20WqpdHW-A@mail.gmail.com>

On Thu, Apr 23, 2020 at 04:44:44PM +0200, Laura Garcia wrote:
> On Sun, Mar 15, 2020 at 2:29 PM Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > On Sat, Mar 14, 2020 at 01:12:02AM +0100, Daniel Borkmann wrote:
> > > On 3/13/20 3:55 PM, Pablo Neira Ayuso wrote:
> > > > We have plans to support for NAT64 and NAT46, this is the right spot
> > > > to do this mangling. There is already support for the tunneling
> > >
> > > But why is existing local-out or post-routing hook _not_ sufficient for
> > > NAT64 given it being IP based?
> >
> > Those hooks are not coming at the end of the IP processing. There is
> > very relevant IP code after those hooks that cannot be bypassed such
> > as fragmentation, tunneling and neighbour output. Such transformation
> > needs to happen after the IP processing, exactly from where Lukas is
> > proposing.
> >
> > [...]
> > > > infrastructure in netfilter from ingress, this spot from egress will
> > > > allow us to perform the tunneling from here. There is also no way to
> > > > drop traffic generated by dhclient, this also allow for filtering such
> > > > locally generated traffic. And many more.
> 
> Any chance to continue with this approach? I'm afraid outbound
> af_packets also could not be filtered without this hook.

Thanks Laura, good to hear there's interest in the functionality.

Daniel submitted a revert of this series but didn't cc me:

https://lore.kernel.org/netdev/bbdee6355234e730ef686f9321bd072bcf4bb232.1584523237.git.daniel@iogearbox.net/

In the ensuing discussion it turned out that the performance argument
may be addressed by a rearrangement of sch_handle_egress() and
nf_egress() invocations.  I could look into amending the series
accordingly and resubmitting, though I'm currently swamped with
other work.

The question is whether that's going to be sufficient because Daniel
mentioned having an in-tree user as a prerequisite for accepting this
feature, to which Pablo responded with NAT64/NAT46.  I don't have
intentions of implementing those, but maybe someone else has.

Thanks,

Lukas

  reply	other threads:[~2020-04-23 16:05 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-11 11:59 [PATCH nf-next 0/3] Netfilter " Lukas Wunner
2020-03-11 11:59 ` [PATCH nf-next 1/3] netfilter: Rename ingress hook include file Lukas Wunner
2020-03-11 11:59 ` [PATCH nf-next 2/3] netfilter: Generalize ingress hook Lukas Wunner
2020-03-11 11:59 ` [PATCH nf-next 3/3] netfilter: Introduce egress hook Lukas Wunner
2020-03-11 14:05   ` Daniel Borkmann
2020-03-11 15:54     ` Lukas Wunner
2020-03-12 22:40       ` Daniel Borkmann
2020-03-13 14:55     ` Pablo Neira Ayuso
2020-03-14  0:12       ` Daniel Borkmann
2020-03-15 13:28         ` Pablo Neira Ayuso
2020-04-23 14:44           ` Laura Garcia
2020-04-23 16:05             ` Lukas Wunner [this message]
2020-04-27 23:44               ` Pablo Neira Ayuso
2020-04-28 20:11               ` Daniel Borkmann
2020-08-20 10:37                 ` Lukas Wunner
2020-08-20 16:35                   ` Lukas Wunner
2020-03-18  0:21 ` [PATCH nf-next 0/3] Netfilter " Pablo Neira Ayuso

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=20200423160542.d3f6yef4av2gqvur@wunner.de \
    --to=lukas@wunner.de \
    --cc=0x7f454c46@gmail.com \
    --cc=ast@kernel.org \
    --cc=coreteam@netfilter.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=fw@strlen.de \
    --cc=kadlec@netfilter.org \
    --cc=mj@ucw.cz \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=nevola@gmail.com \
    --cc=pablo@netfilter.org \
    --cc=tgraf@suug.ch \
    --subject='Re: [PATCH nf-next 3/3] netfilter: Introduce egress hook' \
    /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

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