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@xxxxxxxxx> 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@xxxxxx> wrote: > > > > Hello, > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On Friday, January 3, 2020 7:09 PM, Alberto Leiva <ydahhrk@xxxxxxxxx> 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
