New WireGuardNT breaks throughput limits below Home windows


Enlarge / Forget flexible cell phones – we’re on the lookout for functional cell phone plushes.

The WireGuard VPN project today announced a major milestone for its Windows users – an entirely new kernel mode implementation of the VPN protocol called WireGuardNT. The new implementation enables massively improved throughput for 10 Gbit / s LAN connections – and also for many WLAN connections.

WireGuard (on Windows) and Wintun

The original implementation of WireGuard on Windows uses wireguard-go – a userspace implementation of WireGuard written in the Go programming language by Google. Wireguard-go is then bound to a virtual network device, the majority of which also lives in user space. Donenfeld didn’t like tap-windows, the virtual network interface of the OpenVPN project – so he implemented his own replacement called Wintun from scratch.

Wintun is a significant improvement over Tap-Windows – the OpenVPN project itself implemented Wintun support, with impressive results (414Mbps over Tap-Windows vs 737Mbps over Wintun). But although the use of Wintun is an improvement over Tap Windows, it doesn’t change the need to constantly switch contexts from kernel space (where the “real” network stack lives) and userspace (where OpenVPN and Wireguard both go live).

To remove the remaining performance bottlenecks, the entire stack – virtual adapter, crypto, and everything – has to be pulled into the kernel. Under Linux this means to be a DLKM (Dynamic-Loadable Kernel Module). On Windows, this means that it is a suitable in-kernel device driver.

WireGuardNT and the NT kernel

If you ditch the userspace components of the WireGuard stack on Windows and keep everything in the kernel, you’ll need to modify WireGuard to work on Windows the way it does on Linux. In fact, WireGuardNT began as a direct port of the Linux kernel WireGuard implementation.

According to WireGuard inventor Jason Donenfeld, once the initial port was successful, the NT code base quickly diverged to work well with native NTisms and NDIS APIs. The end result is a deeply integrated, high-performance implementation of WireGuard for the NT kernel that utilizes the full range of NT kernel and NDIS capabilities. “


  • This Ethr throughput test between Equinix Metal c3.small instances is limited to only 2 Gbps. How much improvement can eliminating many context switches make?

    Jason Donenfeld

  • Ethr running over the same tunnel between the same hosts – but with WireGuardNT and without a lot of context switching – triples the performance of the previous method.

    Jason Donenfeld

  • The lower latency per packet inherent in WireGuardNT also benefits users with fast WiFi.

    Jim Salter

  • On the download side of this connection, the performance boost is greater – which is not unusual. Mobile devices tend to have weaker transmissions than APs to save power, heat and size.

    Jim Salter

Of course, this also means avoiding a lot of context switches. The end results are solid: more than three times the peak performance as measured by Ethr on a pair of Equinix Metal (formerly c3.small instances.

However, the benefits of fewer context switches go further than Xeon servers with 10 Gbps interfaces – Donenfeld mentioned that some early testers reported that WireGuardNT sometimes solved massive performance penalties when using their VPN connection over Wi-Fi.

We tested the difference directly using an HP EliteBook with an Intel AX201 Wi-Fi 6 card connected to the router node of a test kit of Plume Wi-Fi 6 Superpods. Although our results weren’t as dramatic as those of some previous testers, they confirm a significant increase in performance. On the same device and with the same configurations, we measured that WireGuardNT iperf3 runs 10 to 25 percent faster than Wireguard-go and Wintun.

Try WireGuardNT today

WireGuardNT is now available from version 0.4 in the general Windows download for WireGuard for testing. However, since it is still classified as experimental, you will need to manually add a registry key and DWORD in order to use it. Open regedit as administrator and then navigate to HKLM -> Software. Next, create a key called WireGuard and within that key create a DWORD called ExperimentalKernelDriver.

If ExperimentalKernelDriver is set to 1, your tunnels will use the new WireGuardNT code – without it (or if it is set to 0) they will use the default behavior, the old Wireguard-go / wintun code. For your change to take effect, you must right-click the WireGuard icon in the system tray and click “Finish”. When you open the WireGuard app again, your ExperimentalKernelDriver setting will be taken into account.

In the future, WireGuardNT will be enabled by default and you will need to set a registration flag instead if you want to use the old code. In addition, the project plans to eventually completely disable Wireguard-go / wintun in the general binary. The projects themselves, however, remain as they have a wide range of uses beyond the standard WireGuard client.