[PATCH] wg-quick: linux: add support for nft and prefer it

[Jason A. Donenfeld]

On Tue, Dec 10, 2019 at 9:30 PM Jordan Glover
<Golden_Miller83 at protonmail.ch> wrote:
>
> On Tuesday, December 10, 2019 7:15 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> > On Tue, Dec 10, 2019 at 7:58 PM Jordan Glover
> > Golden_Miller83 at protonmail.ch wrote:
> >
> > > On Tuesday, December 10, 2019 5:36 PM, Jason A. Donenfeld Jason at zx2c4.com wrote:
> > >
> > > > On the other hand, if what you say is actually true in our case, and
> > > > nftables is utter crap, then perhaps we should scrap this nft(8) patch
> > > > all together and just keep pure iptables(8). DKG - you seemed to want
> > > > nft(8) support, though. How would you feel about that sort of
> > > > conclusion?
> > > > Jason
> > >
> > > The only scenario where you really want to use nft is where iptables command
> > > doesn't exist. I don't know how realistic scenario it is but I assume it can
> > > happen in the wild. Otherwise calling iptables will take care of both iptables
> > > and nftables automatically if those are supported on system. That's why I
> > > proposed to invert current patch logic.
> >
> > I reason about things a bit differently. For me, the decision is
> > between these two categories:
> >
> > A) iptables-nft points to iptables and is available for people who
> > want a nft-only system. So, code against the iptables API, and mandate
> > that users either have iptables or iptables-nft installed, which isn't
> > unreasonable, considering the easy availability of each.
> >
> > B) nft is the future and should be used whenever available. Support
> > iptables as a fallback though for old systems, and remove it as soon
> > as we can.
> >
> > Attitudes that fall somewhere between (A) and (B) are much less
> > interesting to me.
>
> Isn't future goal to drop those firewall hacks altogether? The future of
> nft may be irrelevant then and effort should go for iptables which works
> on more systems

Yes, but that means likely kernel patches, which means a very very
long deployment timeline.