Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Vasili Pupkin <diggest@gmail.com>
To: Roman Mamedov <rm@romanrm.net>, "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: "jwollrath@web.de" <jwollrath@web.de>,
	"wireguard@lists.zx2c4.com" <wireguard@lists.zx2c4.com>
Subject: Re: [PATCH] wg-quick: linux: add support for nft and prefer it
Date: Wed, 11 Dec 2019 00:56:22 +0300	[thread overview]
Message-ID: <a8f51c8e-d0e8-aaa6-024f-70b65007559f@gmail.com> (raw)
In-Reply-To: <20191210221215.56c2f30d@natsu>

On 10.12.2019 20:12, Roman Mamedov wrote:
> On Tue, 10 Dec 2019 17:54:49 +0100
> "Jason A. Donenfeld" <Jason@zx2c4.com> wrote:
>
>> iptables rules and nftables rules can co-exist just fine, without any
>> translation needed. Indeed if your iptables is symlinked to
>> iptables-nft, then you'll insert nftables rules when you try to insert
>> iptables rules, but it really doesn't matter much either way (AFAIK).
>> I figured I'd prefer nftables over iptables if available because I
>> presume, without any metrics, that nftables is probably faster and
>> slicker or something.
> nftables is slower than iptables across pretty much every metric[1][2]. It
> only wins where a pathological case is used for the iptables counterpart (e.g.
> tons of single IPs as individual rules and without ipset). It is a disaster
> that it is purported to be the iptables replacement, just for the syntax and
> non-essential whistles such as updating rules in place or something. And
> personally I don't prefer the new syntax either. It's the systemd and
> pulseaudio story all over again, where something more convoluted, less reliable
> and of lower quality is passed for a replacement of stuff that actually worked,
> but was deemed "unsexy" and arbitrarly declared as deprecated.
>
> [1] http://www.diva-portal.org/smash/get/diva2:1212650/FULLTEXT01.pdf
> [2] https://developers.redhat.com/blog/2017/04/11/benchmarking-nftables/
>
As far as I know both of them are maintained in the same repository and 
both use the same userspace library to interact with the kernel and down 
there all the rules are translated into BPF code which in turn is 
compiled into machine code by kernel BPF JIT compiler. So identical 
rules should show exactly the same performance. nft syntax is odd and 
its curvy braces aren't easy to pass in command line, it is more 
difficult to delete rules from nft table, but it also allows to arrange 
rules into separate chains easier and also provide a native way to 
define sets which are then processed very efficiently as seen in [2]. 
Anyway netfilter infrastructure developers have chosen nft as 
replacement to iptables and it will slowly phase it out, but this will 
be a very slow process and it is already going for 10 years now, 
everything is written in iptables.

I don't see a big problem. Just choose any of the console command 
present on the system and print warning if neither of them is found. 
wg-quick shows its log in console and these rules will not cause any 
problems in most setups anyway. If this is such an issue then it can be 
opted by a command line argument (i.e. use iptables, nft or none) but it 
is already an overshoot. Personally I don't even think that the issue 
should be fixed in wireguard. The weak host model affects any other 
network setups and all the other vpn's just as wireguard and even if 
wg-quick patch it somehow for wireguard interface the end system will 
still be open to attacks on other interfaces. The strong host model 
should be chosen as default by kernel developers or configured system 
wide by an administrator.

Also.. what about other systems, windows, android etc?
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

  parent reply	other threads:[~2019-12-10 21:56 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-10 15:48 Jason A. Donenfeld
2019-12-10 16:52 ` Jordan Glover
2019-12-10 16:54   ` Jason A. Donenfeld
2019-12-10 17:05     ` Jordan Glover
2019-12-10 17:11       ` Jason A. Donenfeld
2019-12-10 17:12     ` Roman Mamedov
2019-12-10 17:28       ` Davide Depau
2019-12-10 17:33       ` Matthias Urlichs
2019-12-10 17:36       ` Jason A. Donenfeld
2019-12-10 18:00         ` Roman Mamedov
2019-12-10 18:58         ` Jordan Glover
2019-12-10 19:15           ` Jason A. Donenfeld
2019-12-10 20:30             ` Jordan Glover
2019-12-10 20:34               ` Jason A. Donenfeld
2019-12-10 21:56       ` Vasili Pupkin [this message]
2019-12-10 22:09         ` Jason A. Donenfeld
2019-12-10 22:27           ` Vasili Pupkin
2019-12-12 11:21             ` Jason A. Donenfeld
2019-12-10 17:31 ` Vasili Pupkin
2019-12-10 17:38   ` Jason A. Donenfeld

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=a8f51c8e-d0e8-aaa6-024f-70b65007559f@gmail.com \
    --to=diggest@gmail.com \
    --cc=Jason@zx2c4.com \
    --cc=jwollrath@web.de \
    --cc=rm@romanrm.net \
    --cc=wireguard@lists.zx2c4.com \
    /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).