* Re: [PATCH] wg-quick: linux: add support for nft and prefer it
2019-12-10 17:12 ` Roman Mamedov
@ 2019-12-10 17:28 ` Davide Depau
2019-12-10 17:33 ` Matthias Urlichs
` (2 subsequent siblings)
3 siblings, 0 replies; 20+ messages in thread
From: Davide Depau @ 2019-12-10 17:28 UTC (permalink / raw)
To: Roman Mamedov; +Cc: jwollrath, wireguard
[-- Attachment #1.1: Type: text/plain, Size: 1528 bytes --]
On Tue, Dec 10, 2019 at 6:13 PM Roman Mamedov <rm@romanrm.net> wrote:
> 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/
I'm seeing the pages you linked are dated 2018 and 2017. I'm seeing this
article [1] dated June 2018 talks about an "important improvement of
performance", and though I don't see any evidence backing the statement I'd
expect more improvements given than more than one year has passed.
Do you know whether the worse performance you're talking about is still the
case on recent Linux releases?
I'd say +1 for nftables but just for the syntax which I do like better.
I'll leave the discussion on performance to experts.
[1]
https://www.zevenet.com/knowledge-base/nftlb/nftlb-benchmarks-and-performance-keys/
[-- Attachment #1.2: Type: text/html, Size: 2270 bytes --]
[-- Attachment #2: Type: text/plain, Size: 148 bytes --]
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] wg-quick: linux: add support for nft and prefer it
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 21:56 ` Vasili Pupkin
3 siblings, 0 replies; 20+ messages in thread
From: Matthias Urlichs @ 2019-12-10 17:33 UTC (permalink / raw)
To: wireguard
On 10.12.19 18:12, Roman Mamedov wrote:
> It's the systemd and
> pulseaudio story all over again
By that metric I can only assume that nft is a huge improvement over
iptables.
We have to deal with iptables vs. nfstables, just like we have to deal
with various vendor kernels. Complaining on-list about either is not
helpful.
In any case, rants about software that is not wireguard are off-topic
here AFAICT. Please stop.
--
-- Matthias Urlichs
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] wg-quick: linux: add support for nft and prefer it
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 21:56 ` Vasili Pupkin
3 siblings, 2 replies; 20+ messages in thread
From: Jason A. Donenfeld @ 2019-12-10 17:36 UTC (permalink / raw)
To: Roman Mamedov, Daniel Kahn Gillmor; +Cc: jwollrath, wireguard
Hi Roman,
On Tue, Dec 10, 2019 at 6:12 PM Roman Mamedov <rm@romanrm.net> 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/
That bachelors thesis says in the abstract, "Latency was measured
through the round-trip time of ICMP packets while throughput was
measured by generating UDP traffic using iPerf3. The results showed
that, when using linear look-ups, nftables performs worse than
iptables when using small frame sizes and when using large rulesets.
If the frame size was fairly large and rule-set fairly small, nftables
was often performed slightly better both in terms of latency and in
terms of throughput. When using indexed data structures, performance
of both firewalls was very similar regardless of frame size or
rule-set size. Minor, but statistically significant, differences were
found both in favour of and against nftables, depending on the exact
parameters used." So maybe it doesn't actually matter?
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
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] wg-quick: linux: add support for nft and prefer it
2019-12-10 17:36 ` Jason A. Donenfeld
@ 2019-12-10 18:00 ` Roman Mamedov
2019-12-10 18:58 ` Jordan Glover
1 sibling, 0 replies; 20+ messages in thread
From: Roman Mamedov @ 2019-12-10 18:00 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: jwollrath, wireguard
On Tue, 10 Dec 2019 18:36:06 +0100
"Jason A. Donenfeld" <Jason@zx2c4.com> wrote:
> That bachelors thesis says in the abstract, "Latency was measured
> through the round-trip time of ICMP packets while throughput was
> measured by generating UDP traffic using iPerf3. The results showed
> that, when using linear look-ups, nftables performs worse than
> iptables when using small frame sizes and when using large rulesets.
Smallest possible frame sizes are what matters the most when testing any
router or firewall setup, because only then you will hit the packet-per-second
limits of the actual firewalling/routing engine. Good performance at large
frame sizes is not an impressive achievent, there you will just hit
on-the-wire bandwidth limits sooner than the CPU toll of processing rulesets
or routing lookups for each of those frames will begin to matter.
> 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?
Even with my view of it I do not argue for removing nftables support from
your tools, realistically it's probably not going anywhere, or at least not
soon enough, just thought I should point out that "nftables is faster" should
not be so naturally assumed to be the case, and if I dare to say that
everyone should decide for themselves what tools they prefer, and to carefully
weigh all benefits and downsides of the proposed alternatives -- not just come
along obediently with some external party that "knows what is best for you" and
declares something deprecated out of their own arbitrary reasons.
--
With respect,
Roman
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] wg-quick: linux: add support for nft and prefer it
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
1 sibling, 1 reply; 20+ messages in thread
From: Jordan Glover @ 2019-12-10 18:58 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: jwollrath, wireguard
On Tuesday, December 10, 2019 5:36 PM, Jason A. Donenfeld <Jason@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.
Jordan
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] wg-quick: linux: add support for nft and prefer it
2019-12-10 18:58 ` Jordan Glover
@ 2019-12-10 19:15 ` Jason A. Donenfeld
2019-12-10 20:30 ` Jordan Glover
0 siblings, 1 reply; 20+ messages in thread
From: Jason A. Donenfeld @ 2019-12-10 19:15 UTC (permalink / raw)
To: Jordan Glover; +Cc: jwollrath, wireguard
On Tue, Dec 10, 2019 at 7:58 PM Jordan Glover
<Golden_Miller83@protonmail.ch> wrote:
>
> On Tuesday, December 10, 2019 5:36 PM, Jason A. Donenfeld <Jason@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.
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] wg-quick: linux: add support for nft and prefer it
2019-12-10 19:15 ` Jason A. Donenfeld
@ 2019-12-10 20:30 ` Jordan Glover
2019-12-10 20:34 ` Jason A. Donenfeld
0 siblings, 1 reply; 20+ messages in thread
From: Jordan Glover @ 2019-12-10 20:30 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: jwollrath, wireguard
On Tuesday, December 10, 2019 7:15 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> On Tue, Dec 10, 2019 at 7:58 PM Jordan Glover
> Golden_Miller83@protonmail.ch wrote:
>
> > On Tuesday, December 10, 2019 5:36 PM, Jason A. Donenfeld Jason@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
Jordan
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] wg-quick: linux: add support for nft and prefer it
2019-12-10 20:30 ` Jordan Glover
@ 2019-12-10 20:34 ` Jason A. Donenfeld
0 siblings, 0 replies; 20+ messages in thread
From: Jason A. Donenfeld @ 2019-12-10 20:34 UTC (permalink / raw)
To: Jordan Glover; +Cc: jwollrath, wireguard
On Tue, Dec 10, 2019 at 9:30 PM Jordan Glover
<Golden_Miller83@protonmail.ch> wrote:
>
> On Tuesday, December 10, 2019 7:15 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> > On Tue, Dec 10, 2019 at 7:58 PM Jordan Glover
> > Golden_Miller83@protonmail.ch wrote:
> >
> > > On Tuesday, December 10, 2019 5:36 PM, Jason A. Donenfeld Jason@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.
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] wg-quick: linux: add support for nft and prefer it
2019-12-10 17:12 ` Roman Mamedov
` (2 preceding siblings ...)
2019-12-10 17:36 ` Jason A. Donenfeld
@ 2019-12-10 21:56 ` Vasili Pupkin
2019-12-10 22:09 ` Jason A. Donenfeld
3 siblings, 1 reply; 20+ messages in thread
From: Vasili Pupkin @ 2019-12-10 21:56 UTC (permalink / raw)
To: Roman Mamedov, Jason A. Donenfeld; +Cc: jwollrath, wireguard
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] wg-quick: linux: add support for nft and prefer it
2019-12-10 21:56 ` Vasili Pupkin
@ 2019-12-10 22:09 ` Jason A. Donenfeld
2019-12-10 22:27 ` Vasili Pupkin
0 siblings, 1 reply; 20+ messages in thread
From: Jason A. Donenfeld @ 2019-12-10 22:09 UTC (permalink / raw)
To: Vasili Pupkin; +Cc: jwollrath, wireguard
On Tue, Dec 10, 2019 at 11:03 PM Vasili Pupkin <diggest@gmail.com> wrote:
> 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.
"bpfilter" is a WIP, but that's not today how iptables or nftables
work, at all. I'm not sure your statement about userspace is entirely
correct either.
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] wg-quick: linux: add support for nft and prefer it
2019-12-10 22:09 ` Jason A. Donenfeld
@ 2019-12-10 22:27 ` Vasili Pupkin
2019-12-12 11:21 ` Jason A. Donenfeld
0 siblings, 1 reply; 20+ messages in thread
From: Vasili Pupkin @ 2019-12-10 22:27 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: jwollrath, wireguard
On 11.12.2019 1:09, Jason A. Donenfeld wrote:
> On Tue, Dec 10, 2019 at 11:03 PM Vasili Pupkin <diggest@gmail.com> wrote:
>> 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.
> "bpfilter" is a WIP, but that's not today how iptables or nftables
> work, at all. I'm not sure your statement about userspace is entirely
> correct either.
>
May be it is a road map plan and there will be no difference in
performance when it will be implemented then. I just recall an
announcement somewhere so it is just a speculation from my side, sorry
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply [flat|nested] 20+ messages in thread