I am curious (though happy) about their focus on performance. For most security projects, the specification seems to be 'sufficient' performance and beyond that they invest their limited resources elsewhere. The WireGuard team seems to make it a top priority.
Maybe this upgrade was needed to be 'sufficient'? Maybe they see performance as key to adoption? Or maybe they have other reasons. I could see how WireGuard's significant reduction in complexity, compared to other VPN software, could feed performance.
It's hard to imagine the Internet without WireGuard, without a VPN I have confidence in. Thank you Jason and team!
Security is the top priority. But being useful is also important; if nobody can use it, nobody benefits from that security. Acceptable performance is very important for being useful, especially when tunneling layer 3 packets, where latency has rippling effects. The prior non-kernel WireGuard for Windows simply was not sufficiently useful for real world workloads people wanted to run, because of the lower performance, both on servers and on laptop wifi alike.
A big part of the WireGuard project since the beginning has been trying to figure out how to do high security tunneling that also performs acceptably. It's easy to do one without the other, but doing them both together has meant thinking about a lot of fundamentals, from the protocol state machines on up. It's hard to do tunneling in the kernel at high speed while still maintaining a strong security posture. That's a principal challenge the project endeavors to solve.
More generally, it's worth noting that cryptographers also care about performance quite a bit in things like symmetric crypto. We know well how to make a good cipher now, but making one that also performs at increasingly high speeds remains an open area of research, with whole conferences, such as FSE, devoted to it.
The world is mired in IPSEC and OpenVPN, two of the Internet's great buzzing stagnant water pools. Part of the reason for that is that proponents (anyone who has gotten IPSEC working is inclined to be a proponent, since it's an investment of effort and brain space one might reasonably hope would pay off) can appeal to standards, known-quantity-ism, and multi-vendor ecosystems.
Legacy VPN protocols fare terribly against WireGuard on what should be the most important concern, of design and implementation security. But the reasons why are, though obvious to people with domain expertise, subtle enough that you can't mic-drop them in a conversation and expect to overcome the standard "but it's standard" objection in favor of IPSEC.
Performance has been a potent tool of persuasion for WireGuard. I've convinced people based on WireGuard speed that I don't think I could have persuaded based on security.
If the goal is getting people off fetid 1990s-grade cryptography and C code, WireGuard's performance is an indirect force towards that goal. It was smart to focus on it, because people obviously care a lot about it. It's great to see a security project where simplicity and performance line up with improved security.
> anyone who has gotten IPSEC working is inclined to be a proponent, since it's an investment of effort and brain space one might reasonably hope would pay off
Oh dear me, getting IPSEC to work did not win it any admiration from me. Of course, what I was doing with it would have been better served by TLS with server and client certificates, but the other end were telcos so sure, I can setup IPSEC and cry myself to sleep.
If I could I would instantly replace every L2L IPsec tunnel configured everywhere I have access, but unfortunately until Cisco, Juniper, Fortigate etc. implement Wireguard, IPsec remains the only option.
I am already using it for production purposes where both endpoints are Linux, though.
Hi Jason, are there any plans for process based routing within the WindowsNT driver? For example, if a Windows user wanted to route only Chrome through a Wireguard tunnel but leave all other applications network traffic untouched.
Routing is actually a layer before packets make it to the WireGuardNT miniport driver. Usually the routing table controls this, but WFP callout drivers can also steer traffic to specific adapters based on things like process image path or security descriptor. So for this functionality, WireGuardNT can be used with various WFP drivers or routing table configurations. It's not something that'd belong in WireGuardNT itself.
With regards to the WireGuard for Windows client, though, whether we'll put the time in to develop such a WFP driver and integrate it there I guess is still up in the air, like many feature wishlist items are.
Okay that makes sense, thanks for the info. I'm new to Windows networking and thought WireguardNT was somehow using a WFP callout to encrypt plus reroute packets and then drop the original.
Keep up the great work you're doing!
Seems to me like if you need to do your task inside the kernel to get acceptable performance, there's something wrong with that kernel.
It's also arguably more difficult to do a given task in the kernel than in userland, code for the kernel is much more security-sensitive and even subtle bugs can be detrimental to overall system performance (or even exploitable).
Best thing would be to fix the OS instead of piling up kludges.
Basically all high performance VPN implementations are kernel-mode. Just because something is difficult does not make it automatically wrong. Note that the main userland VPN which gets cited (OpenVPN) has terrible battery and latency performance.
How would one circumvent the need to copy traffic between different userspace processes before it leaves the host in the case of a userspace tunnel implementation? With a kernel implementation, the userspace process sends some data to a socket, and then the kernel can directly pass the data to the tunnel implementation with as little copying as the design for the kernel allows, and as little context switching as the design allows.
> How would do one circumvent the need to copy traffic between different userspace processes
By mapping the same buffer into both processes, or moving it from one process to the other, depending on security needs. Mapping the buffer into multiple memory spaces is how a kernel VPN driver would accomplish the same thing.
> as little context switching as the design allows
A raw context switch only costs 20 nanoseconds for a round trip. And it's only a few more to save the normal registers. The rest is up to kernel design. So it sure sounds like it's the kernel's fault if putting tasks like that outside the kernel is too expensive. Especially since one context switch can process as many packets as you want.
Wintun -- https://www.wintun.net -- actually uses this technique via shared memory ring buffers. And Winsock RIO has something similar for packets. We were using both of these already prior to WireGuardNT. They're fast but not conclusively so.
"How would one circumvent the need to copy traffic"
Fixing that is the point of, for example, io_uring in Linux. I don't know if Windows has an equivalent. Perhaps not, thus a kernel driver. But there is nothing mysterious about solving that problem.
Hear, hear! I've always said microkernels are the best. If you have thousands of drivers in your kernel, each one is just another attack surface, something that can take the machine down on something as simple as RS232 traffic. Instead drivers should be isolated in their own process. It has lots of advantages:
* Dynamic loading of drivers is no longer an issue, the kernel already knows how to dynamically load processes anyway and a driver is just another proces. No need for special 'kernel maintainers' for drivers, or for drivers to be open source (in case of the Linux kernel).
* Much better system stability, since drivers can do no harm. Kernel architecture can be simpler too.
* Much simpler drivers. Instead of strict cooperation rules the kernel can just pre-empt them when needed.
Unfortunately it appears there is no credible effort in developing a mainstream microkernel OS at this time. Nonetheless, the few I've worked with in the past were amazing and I'd love to see this idea come back.
Context switching overhead is bad for microkernel performance. All the reasons why the userspace wireguard implementation was slower apply to each and every part of a microkernel system. And all of this got worse with spectre and meltdown, secure context switches are now even more expensive. Modern CPUs generally always increase the context switching cost, they optimize for single-process benchmarks.
So microkernels are dead, performance buries them deeper and deeper.
> It's hard to imagine the Internet without WireGuard, without a VPN I have confidence in. Thank you Jason and team!
Most of the time I forget i'm even using wiregaurd until I hit a site that blocks non-consumer IPs, which I think says a lot for just how performant it is - More than simply not slowing down the connection much, it's actually improved reliability considerably for me since I started using it a couple of years ago, in some cases throughput is also improved due to better routing.
It's also made a huge difference to the stability of my SSH connections, making my day to day work a lot more pleasant. Before, SSH connections would arbitrarily drop due to carrier grade NATing ignoring TCP keep alive rules... it's almost impossible to find a consumer ISP these days that doesn't drop idle SSH connections like rocks. With wiregaurd I can keep them alive even while I change connections! my tmux use has dropped to when I actually need to multiplex.
I think performance is just a top priority as security, I remember how in their first whitepaper they already talked about how they batch up packets and stuff like that. Also the whole approach of kernelspace instead of userspace is just for performance.
Actually, I think in the beginning there was even a "marketing chart" with throughput numbers in addition to the chart with lines-of-code numbers?
Edit: performance being a top priority also makes sense strategically: if you want people to use secure software en-masse, then the experience needs to be stellar in UX and performance as well.
It may be mistaken but to be clear, I don't mean it critically. Most FOSS projects have very limited resources - most FAANG projects have limited resources (and skip the security to invest in addictive user experiences and data collection). If security is the aim, it's wise to spend the resources there.
An example? Signal. I love it but performance isn't more than sufficient IME. I'm glad Moxie and crew are spending their time inventing new security technology for the world.
After fighting with OpenVPN for years, I finally switched to Wireguard a while back.
Wireguard on Linux is simply amazing, been using it for the last year plus to link all of my devices in a single tunneled LAN, it's been a blast (I can access any of my devices from any of my devices, wherever I or they may be physically located).
I do keep one windoze box because I occasionally need to run things that refuse to run on anything but that, and I recently installed wireguard on it ... was expecting headaches ... what do you know, it worked right out of the box, and I can actually securely ssh into the Redmond-spawned contraption from any of my other devices, including my android phone.
"show business" is not necessarily derogatory in USA's use. "That's show business" is definitely often used to say "it sucks but that's how things are", but "show business" as a whole is also used to say "this is how the top tier does things, pay attention".
Maybe another way to describe it is: Hollywood ("show business" as a whole, but it leaks into popular media in many ways, thus popular [anything]) has a huge presence in both positive and negative ways.
As usual in idioms, context is extremely important / often more important than the words themselves. "Show business" is a reference to a highly visible and influential segment of [a population], though often devoid of analysis beyond that point.
Source for this? Searching for "Hardest working in show business" without quotes turns up something relating to an entertainer, and searching it with quotes also returns a bunch of entertainment-related matches.
I'm a native speaker that grew up and lives in the U.S. People use it all the time. I don't have any scientific research papers available to show you, but I promise you - this is a common expression.
Misunderstandings about water-transport timetables in 3...2...
* i'll add that whare i am 'the hardest working folks in show business', is often a compliment: we have our backstage (offices etc), and front of house (dealing with customers) where we have our smiley faces plastered on.
It's good to see WireGuard getting some love on Windows. Unfortunately it's not for me at the moment and doesn't tick the boxes I need:
- Last I checked, dynamic server IPs were not supported
- It's system wide by default. With all VPNs, it is relatively difficult to say: use this connection for these applications, or these addresses. Popular VPN apps have per-app-settings, but I find them buggy and not trustworthy. And if you are an expert you can set your own routing of course. But it would be great if you could just right click on a titlebar and say "use VPN for this app", and it was integrated with the OS
- There is no obfuscation for hostile environments. I would like a VPN which has pluggable transports, and can, say, look like ssh or http or a game, and route over 20 random servers. I know of shadowsocks etc., but I could never get it to run.
- There is no integration with Windows login AFAIK. If you want to log into a Windows AD domain, you need to be in the VPN, but you can't establish connection when you are not logged in. This is really annoying. There is a capability in Windows for this, but I never found a VPN where it works properly.
So technically WireGuard is great, security and speed wise, but for me the potential VPN killer application would be defined by superior UX, not by tech.
These things aren't WireGuard's job any more than they were IPSEC's job. What's supposed to happen for people who care a lot about these things is for systems to get built on top of WireGuard to provide them. That's happened for the commercial market, where things like roaming and NAT traversal are key features, and so we have Tailscale. It sounds like you're identifying an open source privacy project built on WireGuard that want to exist. Why not try to put one together?
This is when what makes WireGuard very performing also makes it very difficult to extend. Being in the kernel means extending it in userspace hurts its performance.
Well then how can you claim “most of you might need can be built atop a very performant base layer” without understanding what the grandparent comment (https://news.ycombinator.com/item?id=28579704) says about WireGuard lacking obfuscation?
WireGuard encrypted UDP packets have obvious signature due to the packet type field in the header being in cleartext. DPI can easily filter/drop WG traffic just by checking the first few bytes of each UDP packet and doing simple statistics.
To obfuscate in this context means to morph WireGuard encrypted UDP packets to look like something else (e.g. VoIP traffic).
Current kernel-based official WireGuard implementations leave no possibility of doing so while staying in-kernel.
I was answering to the first part of his comment, about bringing the whole kitchen sink in a tunneling protocol instead of having composable tools allowing for things the designers never imagined.
But OK, this doesn't cover the second need, I'm guessing what you need is down one layer, and should be done in kernel if you really think it important, but how does wg prevent you from doing that?
Build your tunnel obfuscator one layer down (I did some stateful, user-land driven, packet patching not long ago, with ebpf, it is not easy but the tooling is getting better. It seems the new way to do things nowadays anyway... And it runs in-kernel. Then lay wg above it. But having the wg codebase do what in fact the kernel should propose (pluggable transports, etc.) seems... asking the wrong team.
The Linux kernel network stack is already plenty composable without ebpf...
These things, like user accounts, more auth methods, flexible endpoints, IP pools, ..., should be integrated in a product in a secure manner. What wireguard does is the irresponsible lazy approach of leaving everything up to the VPN providers and webinterface-monkeys. Who will surely mess up a lot of the upper layers that provide all the necessary "comfort" features. After which the wireguard crowd will wash their hands with the Jobsian "you are holding it wrong".
Yep! I have a domain on cloudflare (wg.<mydomain>.tld) that my OpenWRT router automatically updates when my IP changes.
I just point my peers at wg.<mydomain>.tld and i'm set! This effectively costs just the registration fee annually (about $7 on cloudflare currently) but could also be done with a free service like no-ip or similar.
I would like a VPN which has pluggable transports, and can, say, look like ssh or http or a game, and route over 20 random servers. I know of shadowsocks etc., but I could never get it to run.
To be pedantic, shadowsocks is a proxy not a VPN but it does what you describe very well, and anecdotally it is better at circumventing the great firewall than wireguard(with its predictable signature it's quickly blocked). Granted I'm not in China anymore and you probably aren't there either, so both wireguard and shadowsocks work really well, but you might want to consider using a proxy over a VPN. If you've had trouble installing SS before, I recommend the streisand ansible script. Connect it to a VPS and it'll install wireguard, shadowsocks with V2ray plugin pointing to github for obfuscation, TOR, OpenVPN and more all at once.
If you're an iOS user and have multiple shadowsocks server, the shadowrocket app makes it very easy to make rulesets that look like so(don't worry there's a UI for it):
You can get specific like "BBC traffic goes through my london proxy, leave netflix un-proxied, twitter traffic goes through germany, etc."
I also do the opposite of VPNing, where I use home PC as a server too so that when I'm traveling I don't get flagged with anti-fraud stuff when I want to check my bank apps and I can watch American Netflix without every worrying about it being blocked.
edit: looks like streisand got archived at the same time as Ubuntu 16.04 got EOL'd. I didnt know because some of my instances have run for years. You can read the discussions on github for some alternative projects.
On your last point, I have a similar problem. I'd like to use WireGuard in a large fleet but the authentication/encryption is just too barebones. You have to generate a keypair for each host and then add that public key to a file on the server. In other words, you can't do it with X509 certificates.
I appreciate WireGuard is designed for simplicity but I don't see how it can scale with this limitation.
This is a tempting idea, and maybe it's actually happening, but I do wonder if it's a bit like the hope that git would eventually sprout 'better porcelain' that would obsolete all the clunky bash, perl, etc. scripts that it started out as.
In the end most everyone who uses git puts up with the slowly improving 'mainline' porcelain and all the replacements never go anywhere.
In particular, I imagine it was important for initial adoption to create the android/ios apps but it really feels like now we're stuck with the kind of clunky (super easy for the user, but super hard to get right for the admin of the network imo) flow they created.
That should toast OpenVPN in term of performance. I never managed to get more than 5MB/s on OpenVPN on windows, I understand precisely because it wasn't implemented in kernel. I ended up running a pfsense gateway in a VM.
It also doesn’t help that the OpenVPN TAP driver on Windows is utterly abysmal. Wintun (also born out of the Wireguard project) performs significantly better.
I have the same experience. I control both the OpenVPN server and client. Windows client have abysmal speed. Linux box which is located in the same apartments, can easily saturate the 100 Mb/s link.
In the end I switched to IPsec which solved Windows performance issues. These times wireguard seems like a perfect solution, because IPsec configuration with various clients takes too much time.
I switched to IPsec too, which works great between windows machines, until I tried to make IPSec work between a windows and linux machine!
But now all the procols are encrypted (SMB3, RDP, etc). Combine that with an IP while list auto applied to each machine's firewall and I don't think you really need a VPN anymore between your own machines. I only use VPNs for torrents now.
there were/are some performance pitfalls with openvpn:
* socket-buffer size too small (fixed now)
* default fragmentation handling is sub-optimal (needs mssfix)
* sheduling priority of the openvpn process too low
Windows 10 allows users to have much more control over their hardware--to the point of even letting users choose which hardware and architecture they prefer.
Windows is willing to run on a much broader range of hardware (though Windows 11 is drastically narrowing that range). But once it's running, Windows really doesn't want to let you have control over your hardware: it lies about the state of the hardware in numerous ways, hides even more information, and especially where power management is concerned it has a clear historical trend of removing control.
My employer use wireguard (perimeter81) - during video conferences (using ms teams) the VPN client goes bananas, occupying some 40-50% of a cpu core - I assume to en/decode the video streams - so I hope this will improve that experience.
I meant that teams is probably using a lot of bandwidth for its (poor choice of) video encoding and the Vpn client is going mental encrypting/decrypting all of that traffic.
Teams swallows an entire core if I have a video conf with more than 3 or 4 others with video active. The Vpn client then uses up half of another. Often I can't do anything with my laptop whilst on one of those calls - including using teams itself because the UI just grinds to a halt.
Weirdly it isn't GPU bound at all, my GPU is basically idling the entire time.
Great effort, but what is WireGuard's plan on getting a Microsoft signature for their kernel-mode driver? Bypassing the code signing is acceptable for beta testing, but not for production systems.
There's AES-NI, on most modern x64 processors, which helps with some Vpn ciphers. But I think Wireguard uses Chacha20 after the key exchanges for most of the traffic, and AES-NI doesn't help with that.
ChaCha20 for symmetric encryption, authenticated with Poly1305, using RFC7539's AEAD construction
Curve25519 for ECDH
BLAKE2s for hashing and keyed hashing, described in RFC7693
SipHash24 for hashtable keys
HKDF for key derivation, as described in RFC5869
My understanding is that modern crypto is fast enough without hardware acceleration, so it's not strictly needed. There are hardware accelerations for AES, SHA algorithms which are slow without acceleration.
I am curious (though happy) about their focus on performance. For most security projects, the specification seems to be 'sufficient' performance and beyond that they invest their limited resources elsewhere. The WireGuard team seems to make it a top priority.
Maybe this upgrade was needed to be 'sufficient'? Maybe they see performance as key to adoption? Or maybe they have other reasons. I could see how WireGuard's significant reduction in complexity, compared to other VPN software, could feed performance.
It's hard to imagine the Internet without WireGuard, without a VPN I have confidence in. Thank you Jason and team!