wg-quick: linux: add support for nft and prefer it
PATCH 1/1 wg-quick: linux: add support for nft and prefer it
If nft(8) is installed, use it. These rules should be identical to the iptables-restore(8) ones, with the advantage that cleanup is easy because we use custom table names.
---
Hey folks,
I'd appreciate a review from some of the nftables experts on this list who requested this.
Thanks,
Jason
src/tools/wg-quick/linux.bash | 59 +++++++++++++++++++++++------------ 1 file changed, 39 insertions(+), 20 deletions(-)
src/tools/wg-quick/linux.bash +39 -20
@@ -95,7 +95,7 @@ add_if() { del_if() { local table [[ $HAVE_SET_DNS -eq 0 ]] || unset_dns - [[ $HAVE_SET_IPTABLES -eq 0 ]] || remove_iptables + [[ $HAVE_SET_FIREWALL -eq 0 ]] || remove_firewall if [[ -z $TABLE || $TABLE == auto ]] && get_fwmark table && [[ $(wg show "$INTERFACE" allowed-ips) =~ /0(\ |$'\n'|$) ]]; then while [[ $(ip -4 rule show 2>/dev/null) == *"lookup $table"* ]]; do cmd ip -4 rule delete table $table
@@ -181,22 +181,30 @@ get_fwmark() { return 0 } -remove_iptables() { - local line iptables found restore - for iptables in iptables ip6tables; do - restore="" found=0 - while read -r line; do - [[ $line == "*"* || $line == COMMIT || $line == "-A "*"-m comment --comment \"wg-quick(8) rule for $INTERFACE\""* ]] || continue - [[ $line == "-A"* ]] && found=1 - printf -v restore '%s%s\n' "$restore" "${line/#-A/-D}" - done < <($iptables-save 2>/dev/null) - [[ $found -ne 1 ]] || echo -n "$restore" | cmd $iptables-restore -n - done +remove_firewall() { + if type -p nft >/dev/null; then + local table nftcmd + while read -r table; do + [[ $table == *" wg-quick-$INTERFACE" ]] && printf -v nftcmd '%sdelete %s\n' "$nftcmd" "$table" + done < <(nft list tables 2>/dev/null) + [[ -z $nftcmd ]] || echo -n "$nftcmd" | cmd nft -f - + else + local line iptables found restore + for iptables in iptables ip6tables; do + restore="" found=0 + while read -r line; do + [[ $line == "*"* || $line == COMMIT || $line == "-A "*"-m comment --comment \"wg-quick(8) rule for $INTERFACE\""* ]] || continue + [[ $line == "-A"* ]] && found=1 + printf -v restore '%s%s\n' "$restore" "${line/#-A/-D}" + done < <($iptables-save 2>/dev/null) + [[ $found -ne 1 ]] || echo -n "$restore" | cmd $iptables-restore -n + done + fi } -HAVE_SET_IPTABLES=0 +HAVE_SET_FIREWALL=0 add_default() { - local table proto i iptables + local table i if ! get_fwmark table; then table=51820 while [[ -n $(ip -4 route show table $table 2>/dev/null) || -n $(ip -6 route show table $table 2>/dev/null) ]]; do
@@ -204,21 +212,32 @@ add_default() { done cmd wg set "$INTERFACE" fwmark $table fi - proto=-4 iptables=iptables - [[ $1 == *:* ]] && proto=-6 iptables=ip6tables + local proto=-4 iptables=iptables pf=ip + [[ $1 == *:* ]] && proto=-6 iptables=ip6tables pf=ip6 cmd ip $proto route add "$1" dev "$INTERFACE" table $table cmd ip $proto rule add not fwmark $table table $table cmd ip $proto rule add table main suppress_prefixlength 0 - local marker="-m comment --comment \"wg-quick(8) rule for $INTERFACE\"" restore=$'*raw\n' + local marker="-m comment --comment \"wg-quick(8) rule for $INTERFACE\"" restore=$'*raw\n' nftable="wg-quick-$INTERFACE" nftcmd + printf -v nftcmd '%sadd table %s %s\n' "$nftcmd" "$pf" "$nftable" + printf -v nftcmd '%sadd chain %s %s preraw { type filter hook prerouting priority raw; }\n' "$nftcmd" "$pf" "$nftable" + printf -v nftcmd '%sadd chain %s %s premangle { type filter hook prerouting priority mangle; }\n' "$nftcmd" "$pf" "$nftable" + printf -v nftcmd '%sadd chain %s %s postmangle { type filter hook postrouting priority mangle; }\n' "$nftcmd" "$pf" "$nftable" for i in "${ADDRESSES[@]}"; do [[ ( $proto == -4 && $i != *:* ) || ( $proto == -6 && $i == *:* ) ]] || continue printf -v restore '%s-I PREROUTING ! -i %s -d %s -m addrtype ! --src-type LOCAL -j DROP %s\n' "$restore" "$INTERFACE" "${i%/*}" "$marker" + printf -v nftcmd '%sadd rule %s %s preraw iifname != %s %s daddr %s fib saddr type != local drop\n' "$nftcmd" "$pf" "$nftable" "$INTERFACE" "$pf" "${i%/*}" done printf -v restore '%sCOMMIT\n*mangle\n-I POSTROUTING -m mark --mark %d -p udp -j CONNMARK --save-mark %s\n-I PREROUTING -p udp -j CONNMARK --restore-mark %s\nCOMMIT\n' "$restore" $table "$marker" "$marker" + printf -v nftcmd '%sadd rule %s %s postmangle meta l4proto udp mark %d ct mark set mark \n' "$nftcmd" "$pf" "$nftable" $table + printf -v nftcmd '%sadd rule %s %s premangle meta l4proto udp meta mark set ct mark \n' "$nftcmd" "$pf" "$nftable" [[ $proto == -4 ]] && cmd sysctl -q net.ipv4.conf.all.src_valid_mark=1 - echo -n "$restore" | cmd $iptables-restore -n - HAVE_SET_IPTABLES=1 + if type -p nft >/dev/null; then + echo -n "$nftcmd" | cmd nft -f - + else + echo -n "$restore" | cmd $iptables-restore -n + fi + HAVE_SET_FIREWALL=1 return 0 }
@@ -323,7 +342,7 @@ cmd_down() { [[ $SAVE_CONFIG -eq 0 ]] || save_config del_if unset_dns || true - remove_iptables || true + remove_firewall || true execute_hooks "${POST_DOWN[@]}" }
Signature · 6 lines
2.24.0 _______________________________________________ WireGuard mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/wireguard
Quoted 4 lines · Jason A. Donenfeld
If nft(8) is installed, use it. These rules should be identical to the iptables-restore(8) ones, with the advantage that cleanup is easy because we use custom table names.
I wonder if nft should be used only if iptables isn't installed instead. Nowadays iptables has nft backend which I believe is default and will translate iptables rules to nft automatically. On my system iptables rules from wg-quck are already shown in "nft list ruleset".
I'm not sure if this work in reverse - are nft rules automatically translated to iptables and shown in iptables-save? If not then using iptables of available seems more versatile for the job.
Jordan
_______________________________________________
WireGuard mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard
Quoted 8 lines · Jordan Glover
Quoted 4 lines · Jason A. Donenfeld
If nft(8) is installed, use it. These rules should be identical to the iptables-restore(8) ones, with the advantage that cleanup is easy because we use custom table names.
Quoted 8 lines
I wonder if nft should be used only if iptables isn't installed instead. Nowadays iptables has nft backend which I believe is default and will translate iptables rules to nft automatically. On my system iptables rules from wg-quck are already shown in "nft list ruleset".
I'm not sure if this work in reverse - are nft rules automatically translated to iptables and shown in iptables-save? If not then using iptables of available seems more versatile for the job.
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.
_______________________________________________
WireGuard mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard
Quoted 17 lines · Jason A. Donenfeld
Quoted 6 lines · On Tue, Dec 10, 2019 at 5:52 PM Jordan Glover [email protected]…
Quoted 3 lines · On Tuesday, December 10, 2019 3:48 PM, Jason A. Donenfeld [email protected] wrote:
If nft(8) is installed, use it. These rules should be identical to the iptables-restore(8) ones, with the advantage that cleanup is easy because we use custom table names.
Quoted 7 lines
I wonder if nft should be used only if iptables isn't installed instead. Nowadays iptables has nft backend which I believe is default and will translate iptables rules to nft automatically. On my system iptables rules from wg-quck are already shown in "nft list ruleset".
I'm not sure if this work in reverse - are nft rules automatically translated to iptables and shown in iptables-save? If not then using iptables of available seems more versatile for the job.
Quoted 7 lines
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.
As I said before, my concern is more about people being fully aware of state of their firewall rather than if it technically works.
Jordan
_______________________________________________
WireGuard mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard
Quoted 28 lines · Jordan Glover
Quoted 17 lines · Jason A. Donenfeld
Quoted 6 lines · On Tue, Dec 10, 2019 at 5:52 PM Jordan Glover [email protected]…
Quoted 3 lines · On Tuesday, December 10, 2019 3:48 PM, Jason A. Donenfeld [email protected] wrote:
If nft(8) is installed, use it. These rules should be identical to the iptables-restore(8) ones, with the advantage that cleanup is easy because we use custom table names.
Quoted 7 lines
I wonder if nft should be used only if iptables isn't installed instead. Nowadays iptables has nft backend which I believe is default and will translate iptables rules to nft automatically. On my system iptables rules from wg-quck are already shown in "nft list ruleset".
I'm not sure if this work in reverse - are nft rules automatically translated to iptables and shown in iptables-save? If not then using iptables of available seems more versatile for the job.Quoted 7 lines
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.
Quoted 2 lines
As I said before, my concern is more about people being fully aware of state of their firewall rather than if it technically works.
Ahh, I see what you're wondering. Well, wg-quick shows [#] nft -f - in it's output, so an administrator should be aware that running nft list ruleset or similar is how to gain some visibility, I suppose.
Perhaps when we eventually can drop RHEL7 support, we'll even drop iptables support all together.
_______________________________________________
WireGuard mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard
Quoted 7 lines · On Tue, 10 Dec 2019 17:54:49 +0100 "Jason A. Donenfeld" <[email protected]> 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/
Signature · 6 lines
With respect, Roman _______________________________________________ WireGuard mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/wireguard
Quoted 14 lines · Roman Mamedov
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.
Quoted 2 lines
[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/
_______________________________________________
WireGuard mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard
Quoted 2 lines · Roman Mamedov
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.
Signature · 6 lines
-- Matthias Urlichs _______________________________________________ WireGuard mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/wireguard
Hi Roman,
Quoted 22 lines · Roman Mamedov
Quoted 7 lines · On Tue, 10 Dec 2019 17:54:49 +0100 "Jason A. Donenfeld" <[email protected]> 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.
Quoted 2 lines
[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
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard
Quoted 5 lines · On Tue, 10 Dec 2019 18:36:06 +0100 "Jason A. Donenfeld" <[email protected]> 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.
Quoted 5 lines
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.
Signature · 6 lines
With respect, Roman _______________________________________________ WireGuard mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/wireguard
Quoted 8 lines · Jason A. Donenfeld
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
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard
Quoted 10 lines · Jordan Glover
Quoted 7 lines · Jason A. Donenfeld
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?
Quoted 7 lines
Quoted 1 line
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
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard
Quoted 26 lines · Jason A. Donenfeld
Quoted 9 lines · On Tue, Dec 10, 2019 at 7:58 PM Jordan Glover [email protected]…
Quoted 6 lines · On Tuesday, December 10, 2019 5:36 PM, Jason A. Donenfeld [email protected] 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?
JasonQuoted 5 lines
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.
Quoted 6 lines
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
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard
Quoted 33 lines · Jordan Glover
Quoted 30 lines · Jason A. Donenfeld
Quoted 9 lines · On Tue, Dec 10, 2019 at 7:58 PM Jordan Glover [email protected]…
Quoted 6 lines · On Tuesday, December 10, 2019 5:36 PM, Jason A. Donenfeld [email protected] 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?
JasonQuoted 5 lines
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.
Quoted 6 lines
Quoted 2 lines
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
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard
Quoted 20 lines · Roman Mamedov
Quoted 7 lines · On Tue, 10 Dec 2019 17:54:49 +0100 "Jason A. Donenfeld" <[email protected]> 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.
Quoted 3 lines
[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 [email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard
Quoted 4 lines · Vasili Pupkin
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
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard
Quoted 9 lines · Jason A. Donenfeld
Quoted 4 lines · Vasili Pupkin
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
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard
I think in the end we'll ship the nftables code. Fedora is defaulting their stuff to nftables now [1][2]. That means systemd-networkd might need or want (speculation) to update their firewall-util.c [3] to support it. And knowing their attitudes on this sort of thing, that means they'll probably (speculation) sunset iptables support and start mandating nftables-enabled kernels. That in turn means non-nftables kernels will probably become fewer and fewer. Some readers on this list might vomit at that kind of reasoning, but I think it nonetheless might reflect a practical reality of the ecosystem that wg-quick(8) lives in. So at the moment, we'll support both iptables(8) and nft(8), preferring the latter if it exists.
[1] https://fedoraproject.org/wiki/Changes/firewalld_default_to_nftables
[2] https://fedoraproject.org/wiki/Changes/iptables-nft-default
[3] https://github.com/systemd/systemd/blob/master/src/shared/firewall-util.c
_______________________________________________
WireGuard mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard
Quoted 2 lines · Jason A. Donenfeld
restore '%s-I PREROUTING ! -i %s -d %s -m addrtype ! --src-type LOCAL -j DROP nftcmd '%sadd rule %s %s preraw iifname != %s %s daddr %s fib saddr type != local drop
I am trying to understand the rulesets. When you check the type of the source address of the incoming packet its type just can't be local to our machine, it is the address of the sender. The source address of the packet can only be local if the packet was sent from the same machine. Isn't this part of the rule redundant?
_______________________________________________
WireGuard mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard
Quoted 7 lines · Vasili Pupkin
Quoted 2 lines · Jason A. Donenfeld
restore '%s-I PREROUTING ! -i %s -d %s -m addrtype ! --src-type LOCAL -j DROP nftcmd '%sadd rule %s %s preraw iifname != %s %s daddr %s fib saddr type != local drop
Quoted 5 lines
I am trying to understand the rulesets. When you check the type of the source address of the incoming packet its type just can't be local to our machine, it is the address of the sender. The source address of the packet can only be local if the packet was sent from the same machine. Isn't this part of the rule redundant?
Those lines are supposed to do the same thing, by the way. If I screwed up and they differ subtly, please let me know.
The ! --src-type LOCAL thing makes it so that you can still ping yourself locally. "Allow loopback." This also has the side effect of letting in dangerous packets that are masquerading as 127/8, but only if you've explicitly opted in to net.ipv4.conf.lo.route_localnet=1 and maybe one other safety nob, which nobody in their right mind does for obvious reasons.
_______________________________________________
WireGuard mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard