WireGuardNT, a high-performance WireGuard implementation for the Windows kernel
lists.zx2c4.com
lists.zx2c4.com
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 utilisation of the available bandwidth, which is just... sad.
It's not the specific site either, other vendor VPNs can easily achieve > 300 Mbps over the same path.
It's a year and a half into the pandemic, there are record numbers of people working from home, and Microsoft is the world's second biggest company right now.
Meanwhile, volunteers put together a protocol in their spare time that is not only more secure but can also easily do 7.5 Gbps!
That needs to be repeated: At least ONE HUNDRED TIMES faster than the "best" Microsoft can offer to their hundreds of millions of enterprise customers that are working from home.
Someone from Microsoft's networking team needs to read this, and then watch Casey Muratori's rant about Microsoft's poor track record with performance: https://www.youtube.com/watch?v=99dKzubvpKE
Many years ago, I once brought a crossover cable from home to the office to do some data transfer from a workstation to a company-issued laptop. The IT department issuing the laptop, being lovers of all things Microsoft, claimed crossover cable was "obsolete" due to auto-sensing used by Windows.
I am just another dumb end user, I do not work in IT, but I still get faster data transfer between two computers with crossover cable than by going through a third computer, or God forbid, over Wifi.
Sounds like crossover cable is not "obsolete" after all. Who would have thought.
Microsoft's customers, e.g., IT departments, are arguably complicit in the sad "state-of-the-art" you describe. The best software I have ever used was written by volunteers. Money can't buy everything. As Microsoft has shown, it can certainly buy customers.
So for GbE it's all but guaranteed, for Fast Ethernet it depends on how much money the device vendor was willing to spend on the interface, basically. Later laptops should be pretty reliable.
Or course none of this has anything to do with Windows, it all happens at a hardware level which can sometimes make investigating problems a bit painful.
Wonder why the parent comment I was replying to mentioned crossover cable in particular. If it's obsolete why mention it.
Whereas the parent comment probably only used the language "crossover" because they were trying to be explicit about the fact that they are talking about a direct PC-to-PC ethernet connection. Not because crossover wiring is actually necessary to make that configuration work.
Furthermore, support for auto-sensing has nothing to do with the OS, or Microsoft.
Second, you are guessing what the commenter meant by crossover cable. I think he meant crossover cable. There is nothing to suggest otherwise.
Third, I never said auto-sensing had anything to do with the OS or Microsoft. I said the IT department loved Microsoft. You got confused and made a connection between the two.
This thing with Microsoft Windows is that it encourages the user to upgrade their hardware. Whereas I prefer NetBSD as a personal OS, and it does no such thing. Not every computer I own has auto-sensing nor a particularly fast NIC.
The questions I raised are 1. whether crossover cable still works (with both older and newer hardware) and 2. whether it is faster than alternatives.
Is it slower. IME, no.
Plus you are (again) ignoring the situations where it's an older computer that does not have auto-sensing.
True or false: Crossover cable is more versatile for direct data transfers and is not any slower than using auto-sensing.
AFAICT, there is nothing wrong with crossover cable. If there was, methinks the parent commenter wouldn't be mentioning it on HN.
I do not see grey because I use a text-only browser. It's all the same color (except italics), just how I like it. :)
I'm not even kidding that much, the DirectAccess team appears to have been disbanded and all of the open issues were unofficially put in the "will not fix" bucket. I suspect the Always On VPN team is one guy, but probably not working on it full-time.
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.
> While performance is quite good right now (~7.5Gbps TX on my small test box), not a lot of effort has yet been spent on optimizing it
> Jonathan Tooker reported to me that, on his system with an Intel AC9560 WiFi card, he gets ~600Mbps without WireGuard, ~600Mbps with wireguard-go/Wintun over Ethernet, ~95Mbps with wireguard-go/Wintun over WiFi, and ~600Mbps with WireGuardNT over WiFi.
Congratulations to Simon and Jason! Very happy WireGuard user here.
Has anyone done any comparisons how latency is affected between various VPN implementations?
The only exception is initial handshake which adds 1rtt for the first packet being sent.
I don't know much about WireGuard, but generally speaking large fixed latency during one step can lead to huge variance in end to end latency due to queuing.
I think they are truly exceptional programmers. It's hard to think of people who have come anywhere close to such an achievement.
I think IPSec or OpenVPN are probably the opposite of what WG is offering here... Microsoft's SSTP offering is actually not causing me any major frustration at the moment. I almost like using it. But, seeing these other comments telling tales of 600 megabit VPN wifi experiences... I'll check it out for sure.
I worked at a company that did this and it was a massive headache, every time I wanted to set up a new VM things would fail until I remembered I had to install their CA. I was an intern at the time, and they gave me some work that required an app that I couldn't configure to use their CA for the life of me. After a lot of failed troubleshooting I and ended up just running a SSH server on my home PC and creating a SOCKS proxy through that.
-Allow with no mitm (trusted sites)
-Block with no way around it(all residental IPs, pornsites)
-Allow but mitm the connection. The browser would present the classic ERR_UNKNOWN_ISSUER warning that most people would ignore. I couldn't figure out what criteria decided that a certain site needs the mitm treatment.
Hungary.
My theory is that it was installed to curb filesharing and then it snowballed into generic blocking of various things on the university network.
>intellectual freedom to explore and tinker you'd want to flourish at a university.
Ah that sounds sweet. Reminds me of the anecdotes I read from the pioneer age of computing that people tell here sometimes. Well, the place I studied at was nothing like that. >_>
They asked what ports we wanted (sigh), we said all, I suspect the ports were opened but MITM wasn’t disabled. Oddly it either passed through u mileages or it broke connections completely without inserting a fake cert.
Even more oddly GitHub was blocked but stackoverflow was allowed.
As we turned up in the vans on the Saturday morning and the recee team hadn’t clocked this (to be fair most https sites worked fine) we couldn’t get it changed - or the process for changing it was far too much given the other stuff we had to set up and the ease of the workarround.
There are at least several other providers out there. Ideally you can find one where their nearby servers use the same IX as your ISP and/or peer with your ISP.
On the other I'm sad that once it's accepted into kernel, it won't be possible to add interesting changes (e.g. obfuscation, forward erasure correction, etc).
I'm torn apart :P
Does anyone have experience with udp2raw or udptunnel?
Yes, this is supremely ugly, but unfortunately entrenched and expected by now. I've been to customers with intrusive filtering/scanning setups like that who then recommended their favourite commercial VPN vendor to get around that filtering...
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? :-)
Yes, it is insane.
It's called ossification. Same reason why TLS 1.3 has to pretend it's TLS 1.2, and QUIC must be over UDP.
Unfortunately the recent popularity means that almost all DPI software recognize the wireguard handshake.
Why should that matter? How does the DPI software get your keys? Isn't WireGuard data flow completely opaque to anyone or anything between endpoints?
If the DPI software blocks WireGuard packets, that's an entirely different discussion. It gets into the area of "technical solutions" to fight "administrative policy".
Yes, that's exactly the point. Sometimes that's the best course of action available to you. If the userspace implementation were to be deprecated that could pose difficulties.
Unless you mean WireGuard over Shadowsocks UDP transport, but that is even less common.
(Disclaimer: I wrote the official Go port of Shadowsocks https://github.com/shadowsocks/go-shadowsocks2)
Sometimes a bad solution is better than no solution at all.
Tunneling WG over SS would be inefficient for obvious reasons. Maybe there should be a more lightweight solution.
Another would be "Do one thing and do it well", which is Unix philosophy.
What we do need is a proper replacement for roughly the things OpenVPN plus PAM can do. A VPN plus some user and key management.
I'm not arguing that Wireguard has an obligation to tackle that problem themselves. I'm arguing against your assertion that VPN access should be completely decoupled from ensuring endpoint security.
All they're good for is checking that unpatched (but not yet exploited/evil) endpoints can't connect to the network, which is of marginal benefit compared to allowing them to connect but requiring they patch before accessing risky resources (like the internet or email).
Anyway. Like I said, I think Wireguard is amazing - I used PiVPN (which can be installed on any .deb distro) to set up a simple gateway for my laptop and phone to be always connected for DNS and local-network access. I'm very grateful for its architecture and simplicity in that regard.
I do agree with your overall sentiment, though. The next step is to make a higher level protocol on top.
You are going to want to try to avoid that problem, while making your tool still useful. Wireguard hits the sweet spot particularly well.
"Oh, I'm afraid the EasySecureAuth wireguard server doesn't support the AndroidWireClient client when using a Yubikey version 1. Either use version 2 or switch to iOS."
To achieve true MFA, it would need either a password, TOTP, or SMS in addition to the stored keys.
You could be hacking something together with a Nitrokey or maybe Yubikey, those can do Ed25519 signatures. But generally, you would need to fiddle a lot with the implementation, because currently signatures are done in the kernel module, and you'd need to get that into the USB-device for signing and back again. Not impossible, but not implemented yet.
Another way would (theoretically) be to implement different signature algorithms for the wireguard key exchange, ideally some that common smartcards do support. But wireguards author left out cryptographic agility on purpose, so any work in that direction will be incompatible with the original implementation, or at least a very ugly kludge.
Unfortunately they're all NDAware, so they may as well not exist. ...But of course I've written about my extensive issues with the smartcard industry before.
There are programmable smartcards on which you can implement your own algorithm. ZeitControl sells cards you can program in a BASIC dialect: https://www.zeitcontrol.de/de/produkte/basiccard/basiccard-p...
If the wireguard core included any kind of timed partial delegation of authority through key signatures (similar to what SSH allows now with cert-authority/CertificateFile), that'd be enough to build SMS/HOTP/TOTP 2FA, security keys, and much more on top of it.
Can you tell I’m a very happy customer?
But while they were on Windows, Tailscale worked perfectly on their machines too.
What? WireGuard is a VPN protocol (and implementation), while OpenSSL is an implementation of TLS. They're not competing with each other, and you can't compare them.
IPSec is Internet Layer, while TLS/SSL (OpenSSL) are Application Layer
Technically not, since IPSec can also be tunneled over UDP which then turns it into an application layer protocol.
But no, it's the typical groupthink of 'old is bad' so instead of reading two pages of documentation and having native support across all major platforms people would rather re-invent the wheel.
It distinguishes itself from other VPNs by not having knobs to twiddle. Should a security issue arise, it will be necessary to replace it with a wireguard2 or such. This also means that it's very hard to get it wrong in config; either it works or it doesn't, and if it doesn't, you haven't got it working yet.
It's very fast and very nice to work with.
Of course, if you want to connect two static networks, wg-quick is all you need. But for the typical “remote worker VPN”, it's pretty much a (great) building block.
That's what I'd like, since authentication is usually a pain to set up and with Wireguard, there's none to be done. This also means it's totally stateless and is great for mobile devices where a connection might be broken and crsated again frequently.
I'm sure if you asked them about switching auth methods they would help with that.
EDIT: since I’m still in the edit window, here’s what Tailscale came back with (great response time!).
>We can fairly easily switch between auth providers where the usernames are an email address, like Microsoft or Google or Okta.
>For GitHub the username is different, GitHub uses your Profile name. Any email addresses associated with your GitHub profile are not available.
>Unfortunately there isn't a straightforward way to migrate an existing Tailnet with its devices from Google to GitHub. We generally recommend making a new Tailnet with GitHub and re-authenticate devices using GitHub one at a time. For remote devices, this is more challenging.
>If you want to try it, a suggestion: 1. you can create a Reusable authkey at https://login.tailscale.com/admin/settings/authkeys for the new GitHub Tailnet 2. Over ssh to a node currently on the Google Tailnet, you can: `tailscale up --force-reauth --authkey=tskey-0123456789abcdef` 3. You'll lose the SSH session. The device will make a new Node key and be issued a new IP address on the new GitHub Tailnet. 4. You can look up its new IP address on https://login.tailscale.com/admin/machines of the GitHub Tailnet, and should be able to ssh to the new address.
https://www.wireguard.com/talks/lpc2018-wireguard-slides.pdf
Also Ars had a great article on it as well if you want a readable but more in depth version https://arstechnica.com/gadgets/2018/08/wireguard-vpn-review...
For instance, WireGuard reconsiders what the role of a VPN "protocol" actually is, and in WireGuard the protocol itself delivers a point-to-point secure tunnel and nothing else, so that the system is composable with multiple different upper-level designs (for instance, how you mesh up with multiple endpoints, or how you authenticate).
Another reasonable way to look at WireGuard is that it's the Signal Protocol-era VPN protocol (WireGuard is derived from Trevor Perrin's Noise protocol framework).
Notably: WireGuard doesn't attempt to negotiate cryptographic parameters. Instead, they've selected a good set of base primitives (Curve25519, Blake2, ChaPoly) and that's that; if those primitives ever change, they'll version the whole protocol.
If you haven't played with it, WireGuard is approximately as hard to set up as an SSH connection. It is really a breath of fresh air.
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 of those can use WireGuard but will have wildly different needs when it comes to authentication and deployment. There’s no sane one-size-fits-all solution for all kinds of organizations and use-cases.
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 needs when it comes to authentication and deployment. There’s no sane one-size-fits-all solution for all kinds of organizations and use-cases.
There needs to be a system that can scale there, especially if the intent is to replace OpenVPN which slotted neatly into standard PKI. If this system pushes more users onto a handful of centralised providers, which seems like what's implicitly being encouraged, then that's not going to end up being good for security.
Then why are modular cryptosystems (where e.g. the symmetric cipher algorithm is pluggable) a bad idea?
To take the popular example: OpenSSL has a plethora of extensions. If there’s a thing you want to do, odds are the spec has been extended to cover that use case.
One result of that is that many code paths exist that aren’t part of everyday usage for most users, and so those code paths get less love (and more bugs): this makes things like Heartbleed radically more likely.
Another result is that parties using the system to communicate need to agree which modules/extensions they’re going to use. This kind of negotiation has been a punching bag for vuln after vuln, because it turns out some options are going to end up having weaknesses, and thus attackers can make their lives easier if they focus on tricking parties into downgrading to weaker modules.
By contrast, having Wireguard exclusively handle point-to-point tunnel behavior, without any negotiation of modules or extensions or similar, both simplifies the code paths and avoids runtime negotiation. Wireguard provides a boundary beyond that: it does not handle things like IPAM or a central authentication story, leaving those for another system to own. That system is then free to likewise provide a simple interface for whatever it’s doing, and gleaning all the same benefits.
Right, but that system actually needs to be implemented, and the two need to be integrated together, and that part is where I suspect the vulnerabilities are likely to be, because the interface between two systems developed separately is always the most likely point for bugs and misunderstandings to creep in.
People talk about WireGuard having fewer vulnerabilities than OpenVPN and that may be true as far as it goes, but it's missing the fact that you can't simply replace OpenVPN with WireGuard - you would have to replace it with WireGuard plus some certificate management system plus some integration between them. And if everyone builds the last part themselves, it will almost certainly have security vulnerabilities.
The reason why it's hyped is because it's a non-encumbered, gratis, libre, fast replacement for OpenVPN.
Yes, it doesn't handle algorithm negotiation. So if there's something wrong with the algorithms it's chosen, then we'll need a Wireguard 2. That's a design choice that trades off one thing (protocol independence and resilience) for another (simplicity and ease of implementation).
(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 security and cryptography engineers generally trust it more than any alternative protocol.
(f) As a result of all of this, it is absurdly simple to configure and get running.
Yes, IPSEC does a bunch of stuff WireGuard doesn't do. Yes, that's the tradeoff WireGuard made. Making that tradeoff is (a) the point of WireGuard and (b) the reason people like it so much.
No, it's very fast because the ChaCha/Salsa20 stream cipher uses common CPU instructions and runs fast in purely software, whereas AES requires things like S-Box computations which is slow in software but fast when implemented as accelerated instructions in hardware. There are IPSEC software stacks using AES acceleration that runs just as fast, not to mention IPSEC hardware offload.
OpenVPN is slow due to architectural constraints, but IPSEC doesn't suffer from that at all. IPSEC tunnels with PSK is also absurdly easy to configure, either on Linux, or a router, what it doesn't offer is native NAT traversal.
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 IPsec keys and parameters. This is where a lot of the complexity comes in, tons of parameters, modes, etc. etc.
So if all you want is to secure communication between two IPs and can securely exchange key material out of bands, manually keyed IPsec is not very complicated.
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.
NSA likes that.
https://blog.cryptographyengineering.com/2015/10/22/a-riddle...
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 par, plus I am confident we'll see hw acceleration for Chacha20-Poly1305 in the future too.
So I'd say right now if you need absolute max performance, a good IPsec implementation is much faster than Wireguard.
[1] for example, just running 'openssl speed -evp chacha20-poly1305' vs 'openssl speed -evp aes-256-gcm' on my laptop gives a ~2x speed advantage to AES.
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.
We don't have to derive the answer to this question from first principles. It's an empirical question.
Note that thanks to AES-NI vectorization (an example of hw acceleration I was referring to) it reaches more than 16Gps/core on the same test on Icelake.
Those numbers can grow up to 50% for big packets (1500-bytes and higher).
With a high performance stack, IPsec (and Wireguard for that matter) workloads are limited by crypto performance, not packet processing performance, and the perf difference between IPsec with AES-256-GCM and Wireguard is basically the perf difference of AES-256-GCM vs Chacha20-Poly1305 of your platform.
And the main reason is the cipher: one is hw-assisted (AES-NI on x86), the other is not.
Again, I do think Wireguard is nice because it is a clean sheet design with good choices and it "just works". However when I hear "Wireguard is faster than IPsec" it is not true in my experience, and can be easily explain by the cipher choice.
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.
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 kinda generic and somewhat meaningless to someone without in-depth networking experience.
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-networkd (directly)
Arch "desktop" - NetworkManager
There can be many environments and situations, and sometimes a component would block packets to be forwarded from one network or user to another.
You need to know a bit about networking to debug it.
According to Linus: "...compared to the horrors that are OpenVPN and IPSec, it’s a work of art."
I think it's best left to the Wireguard team and not Redmond.
>While performance is quite good right now [...] not a lot of effort has yet been spent on optimizing it, and there's still a lot more performance to eek out of it, I suspect, especially as we learn more about NT's scheduler and threading model particulars. [emphasis added]
Are you suggesting that these performance improvements will be contained in 'wireguard2'? Surely there will be improvements to the codebase, even if they don't involve fixing defects that undermine fundamental security assumptions.
* In ordinary conditions. Test-sign mode does exist.
¤ ... for example, these Red Hat versions: https://www.catalog.update.microsoft.com/Search.aspx?q=Red%2...
(It might be also slightly newer; v204 is 100.85.104.20400).