Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WireGuardNT, a high-performance WireGuard implementation for the Windows kernel

lists.zx2c4.com

Post reply on HN
Print view View original

161–170 of 187 posts

Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel

#161

Post by api »

benou wrote: post #160
tptacek wrote: post #98

Earlier quoted context omitted.

No, I think this is essentially wrong. It's hyped because it: (a) Doesn't have selectable or negotiable algorithms and constructions. (b) Exclusively uses modern constructions everybody trusts. (c) Has a minuscule implementation footprint, designed in part to avoid dynamic allocation altogether, that is straightforward to audit. (d) As a result of all of this, it is very fast. (e) As a result of all of this, software…

I am not challenging that Wireguard is a great technology, but I disagree it is faster than IPsec: it is fast compared to slow IPsec implementation such as the one you have in Linux. However, AES is hw-accelerated in most systems those days and as a result, using IPsec with AES-256-GCM is usually much faster than Wireguard [1]. Note that if Wireguard was using AES instead of Chach20-Poly1305 I am sure it would be on…

This is a big reason why ZeroTier is moving to AES for its symmetric crypto. It's not only a lot faster but much more power efficient. The blazing speeds with ARX ciphers are only achievable using vector or other parallel constructions that light up the whole ALU, using many times more power than AES hardware.

Using AES with GMAC I can clock from 2-4GiB/sec/core on typical laptops and over 1GiB/sec on phones. The Apple M1 does almost 5GiB/sec/core. Gen10 and newer Intel CPUs with VAES have produced benchmarks in excess of 10GiB/sec/core, which means a single core could theoretically saturate 100gig fiber if it were just doing crypto.

Of course nothing stops CPU makers from adding ARX accelerator instructions, but I have yet to see any proposed. If constructions like ChaCha and BLAKE2/BLAKE3 get popular enough I could see this happening.

Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel

#162

Post by deskamess »

atonse wrote: post #14
nixcraft wrote: post #2

I would like to see 2FA (app or security key) support built into WireGuard. Otherwise, it is perfect as compared to the OpenVPN mess.

Tailscale solves all these problems, including SSO. Can you tell I’m a very happy customer?

Do you have any Windows systems in your network? I am looking to restrict RDP sessions to a closed Wireguard network.

Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel

#163

Post by vxNsr »

vladvasiliu wrote: post #111
vxNsr wrote: post #107

Earlier quoted context omitted.

> and given a valid `wg0.conf` And there it is. Idk about OP but this is what tripped me up. There are many guides online, but the native documentation assumes you have a pretty deep understanding of the network stack, authentication, and VPNs. The online guides all kinda make assumptions about your network set up and if it’s different in anyway your attempt will fail and you won’t know why; as the error codes are ki…

But the `wg0.conf` thingy has to be set up on Windows too, right? So It's not clear why it would be easier on Windows than on Linux. As far as I'm concerned, the most difficult thing I've encountered with Wireguard wasn't related to WG itself but to the fact that I'd set it up on three different systems, each with its own configuration style for bringing up the network. Ubuntu server - netplan Arch server - systemd-n…

The client on Windows might be easier to use, again, I’m not the OP. I had trouble with it in general both on Windows and Linux.

Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel

#164

Post by e12e »

PhantomGremlin wrote: post #119
aborsy wrote: post #62

In some networks, I only have outgoing tcp ports 80 and 443. Does anyone have experience with udp2raw or udptunnel?

This is just insane. Everything except WWW is blocked, so everything must pretend to be WWW???!!! So can anyone explain the purpose of the "source port" and "destination port" fields in the TCP header? :-)

It is insane. But probably some ICMP is allowed too - otherwise TCP tends to break in subtle ways... it is possible to whitelist some/necessary ICMP traffic though.

Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel

#165

Post by psanford »

herio wrote: post #125
tptacek wrote: post #106

Earlier quoted context omitted.

You are the first person who has ever told me that IPSEC was absurdly easy to configure. Share a configuration that illustrates the point?

What is commonly called IPsec is actually two separate protocols, IPSec itself and ISAKMP/IKE for key management. IPSec is somewhat similar to how wireguard work actually, it relies on IPs and static encryption keys. Not too hard to configured, see for example the manual keying documentation of slackware: https://book.huihoo.com/slackware-linux-basics/html/ipsec.ht... ISAKMP/IKE is then used on top to manage the IPse…

IPSEC without IKE is not "similar to how wireguard works actually." Wireguard does actual key exchange and has security properties such as Forward Secrecy that you don't get using a hardcoded IPSEC symmetric key.

Also, even the IPSEC config without IKE is way more complicated than a Wireguard config, with seriously sharp edges. Just look at that config you linked to. No one should ever need to know what AH and ESP are, but if you don't you very easily can configure IPSEC in an insecure manner.

Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel

#166

Post by tptacek »

lmm wrote: post #156
cpach wrote: post #150

Earlier quoted context omitted.

The end-user doesn’t need to do their own key exchange/management. Case in point: https://tailscale.com/ Why should WireGuard bake all that stuff into the core protocol and at the same time make it overly complicated? Donenfeld knows zero about your organization and he doesn’t pretend to do so either. Are you an entusiast home user, a startup of six persons in a garage or are you IBM with over 300000 employees? All o…

> Why should WireGuard bake all that stuff into the core protocol Because all that stuff is security-critical. All that stuff needs to be incorporated into any audit of the system. Indeed it's probably where the vulnerabilities are going to be. > Are you an entusiast home user, a startup of six persons in a garage or are you IBM with over 300000 employees? All of those can use WireGuard but will have wildly different…

This argument doesn't make any sense. The more you couple to the underlying protocol, the harder it is to audit. Having a well-defined and predictable boundary between concerns in the system makes each component, and the system as a whole, easier to assess.

Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel

#167

Post by tptacek »

benou wrote: post #160
tptacek wrote: post #98

Earlier quoted context omitted.

No, I think this is essentially wrong. It's hyped because it: (a) Doesn't have selectable or negotiable algorithms and constructions. (b) Exclusively uses modern constructions everybody trusts. (c) Has a minuscule implementation footprint, designed in part to avoid dynamic allocation altogether, that is straightforward to audit. (d) As a result of all of this, it is very fast. (e) As a result of all of this, software…

I am not challenging that Wireguard is a great technology, but I disagree it is faster than IPsec: it is fast compared to slow IPsec implementation such as the one you have in Linux. However, AES is hw-accelerated in most systems those days and as a result, using IPsec with AES-256-GCM is usually much faster than Wireguard [1]. Note that if Wireguard was using AES instead of Chach20-Poly1305 I am sure it would be on…

Post numbers on a good IPsec implementation? We have numbers for WireGuard. Of course, it's easy to do that because there's just a couple primary implementations, not 100 terrible ones like in IPsec. So, pick the best one.

We don't have to derive the answer to this question from first principles. It's an empirical question.

Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel

#168

Post by tptacek »

herio wrote: post #125
tptacek wrote: post #106

Earlier quoted context omitted.

You are the first person who has ever told me that IPSEC was absurdly easy to configure. Share a configuration that illustrates the point?

What is commonly called IPsec is actually two separate protocols, IPSec itself and ISAKMP/IKE for key management. IPSec is somewhat similar to how wireguard work actually, it relies on IPs and static encryption keys. Not too hard to configured, see for example the manual keying documentation of slackware: https://book.huihoo.com/slackware-linux-basics/html/ipsec.ht... ISAKMP/IKE is then used on top to manage the IPse…

Is that your absurdly simple configuration? Can I assume the contents of that web page are where you rest your case on WireGuard's `wg.conf` vs. IPsec?

Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel

#169

Post by zamadatix »

jiggawatts wrote: post #84

For reference, I've never seen the built-in Windows VPN protocols exceed ~70 Mbps in any scenario. Maybe it's possible with a crossover cable between two Mellanox 100 Gbps NICs, using water-cooled and overclocked CPUs, but not over ordinary networks with ordinary servers. I have gigabit wired Internet to a site with gigabit Internet. Typical performance of SSTP or IKEv2 is 15-30 Mbps. That's 1.5% to 3% max utilisatio…

I regularly saturate a gig internet connection to my Colo a few states over using the built in windows IPsec client just using a standard laptop.

Not that it's a particularly amazing VPN stack but 15-30mbps says you just ran into a corner case issue regardless which VPN stack it is.

Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel

#170

Post by starfallg »

benou wrote: post #160
tptacek wrote: post #98

Earlier quoted context omitted.

No, I think this is essentially wrong. It's hyped because it: (a) Doesn't have selectable or negotiable algorithms and constructions. (b) Exclusively uses modern constructions everybody trusts. (c) Has a minuscule implementation footprint, designed in part to avoid dynamic allocation altogether, that is straightforward to audit. (d) As a result of all of this, it is very fast. (e) As a result of all of this, software…

I am not challenging that Wireguard is a great technology, but I disagree it is faster than IPsec: it is fast compared to slow IPsec implementation such as the one you have in Linux. However, AES is hw-accelerated in most systems those days and as a result, using IPsec with AES-256-GCM is usually much faster than Wireguard [1]. Note that if Wireguard was using AES instead of Chach20-Poly1305 I am sure it would be on…

>I am confident we'll see hw acceleration for Chacha20-Poly1305 in the future too.

The speed gains wouldn't be as significant. AES uses S-Box computations that do well when hardware accelerated, whereas ChaCha/Salsa20 are designed to use more typical CPU instructions for bitwise operations.

Post reply on HN