WireGuard on Windows early preview
WireGuard 0.0.14 pre-alpha, running on an x1.small machine at packet.net. It's uploading across a WireGuard tunnel at 1.2Gbps to a Linux machine, also at packet. [credit: Jim Salter ]
WireGuard is a new peer-to-peer VPN technology that has the potential for greater speed, smaller attack surface, and easier configuration than commonly used and better-established VPN platforms such as OpenVPN and IPSec. It has been available on Linux, FreeBSD, macOS, Android, and even iOS for quite some time now, with Windows being the one platform frustratingly missing. There are good reasons for that-lead developer Jason Donenfeld didn't want to inherit the problems of OpenVPN's OpenTAP adapter code, and when he investigated Microsoft's built-in VPN API, he didn't like that either. So his first move was to take a giant step backward on the Windows platform and develop an extremely simple virtual adapter that could be used not only for WireGuard, but also for other projects that might need the same kind of very basic, socket-and-tunnel functionality. This became Wintun.
For the moment, WireGuard for Windows is still in what creator Jason Donenfeld refers to as "pre-alpha," with an alpha build due out sometime in the next week or two. The good news is that it's an easy install now, with no dev-fu required to get it running happily on a Windows 10 (or Server 2016, as seen below) system. There are self-contained, signed MSI installers for both 64-bit and 32-bit builds there; downloading and running them just works, with no complaints from Defender about unsigned or untrusted anything. I was curious about what makes v0.0.14 "pre-alpha" rather than merely "alpha." Donenfeld told me one reason he called it pre-alpha was to keep journalists like me (as well as the generally unadventurous) from writing about it before it's ready.
Pressed for more detail, it became clear that he's laser-focused on security-and Windows as a platform diverges far more radically from Linux, Android, macOS, and iOS in that regard than any of them do from one another. There's no access to Windows kernel source code, and the documentation is insufficient for his needs. As a result, he has spent hundreds of hours in a disassembler, reverse-engineering ntoskrnl.exe and ndis.sys to make absolutely sure he understands exactly what's going on at an extremely low level most developers never bother with.
Read 5 remaining paragraphs | Comments