Re: Adding NAT64 to Netfilter

[Alberto Leiva <ydahhrk@gmail.com>]

Hi

I have a working prototype of a Jool wrapper for the nftables
framework. Details can be found here: [0]. Of course, it's not the
full integration you're hoping for (the rules simply send packets to a
Jool instance, in accordance to the current model), but it should keep
users happy while the transition happens.

However, I noticed that nft is not extensible (like iptables), so I
need to provide a custom nft build ([1][2]) instead of a plugin. I
don't think it's viable to expect my more casual users to build nft if
they need cooperation between Jool and nftables, thus I believe I need
to propose a merge of this early code into the nftables project.

Is this acceptable?

[0] https://github.com/NICMx/Jool/issues/285#issuecomment-575400539
[1] https://github.com/ydahhrk/nftables
[2] https://github.com/ydahhrk/libnftnl

On Tue, Jan 7, 2020 at 5:09 PM Alberto Leiva <ydahhrk@gmail.com> wrote:
>
> Hi!
>
> > In regards to the iptables approach, do you have any benchmark
> > compared to the NAT in the same stack?
>
> I think we do, but they are old to the point of pointlessness. But we
> can allocate some testing efforts in February, if you would confirm
> the desirability of this information.
>
> > In regards to the nftables approach, do you mean to integrate the RFC
> > implementations natively into the nftables infrastructure?
>
> I would say "yes," but I'm not sure we mean the same thing.
>
> Jool is currently a box of translating code that interfaces with the
> kernel by way of wrappers.
>
> ie. The Netfilter wrapper receives packets by registering itself to
> nf_register_hooks(), and the iptables wrapper receives packets by
> registering itself to xt_register_targets().
>
> What I mean by integrating Jool into nftables is to create a wrapper
> that would receive packets by means of something like
> nft_register_expr(). (I'm not entirely sure this is what I'm supposed
> to do because I haven't started analyzing this task yet. But that
> would be my starting point.)
>
> Does this answer your question?
>
> > Checking your code, it seems that you use several user space tools
> > (jool, joold) and a conntrack-like table to store the connection data.
> > As you know, in the nftables project it has been done a great effort
> > to avoid several tools for packet mangling so something natively like
> > the following would be probably required.
>
> I'm not averse to the idea of adapting code to fulfill the standards
> of the Netfilter project. Jool's core itself has naturally changed
> substantially over the years to account for emerging RFCs and feature
> requests. It wouldn't be my first major overhaul.
>
> But I admit I don't presently understand how things like the EAM table
> ([0] [1]) are meant to fit in this model.
>
> (Then again, I don't know much about nftables just yet.)
>
> [0] https://jool.mx/en/eamt.html
> [1] https://jool.mx/en/usr-flags-eamt.html
>
> > That's really great news! We (ProtonVPN) will be following the project, and will be glad to help if possible.
>
> Thank you! :)
>
> On Tue, Jan 7, 2020 at 8:14 AM Laurent Fasnacht <lf@o-t.ch> wrote:
> >
> > Hello,
> >
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On Friday, January 3, 2020 7:09 PM, Alberto Leiva <ydahhrk@gmail.com> wrote:
> >
> > > Hello
> > >
> >
> > > I've been working on Jool, an open source IP/ICMP translator for a
> > > while ([0]). It currently implements SIIT, NAT64 and (if everything
> > > goes according to plan) will later this year also support MAP-T. It
> > > currently works both as a Netfilter module (hooking itself to
> > > PREROUTING) or as an xtables target, and I'm soon going to start
> > > integrating it into nftables.
> >
> > That's really great news! We (ProtonVPN) will be following the project, and will be glad to help if possible.
> >
> > Cheers,
> >
> > Laurent
> > ProtonVPN R&D