[ANNOUNCE] Wintun 0.9 Released with Major Usability Improvements

Jason A. Donenfeld Jason at zx2c4.com
Mon Nov 9 17:25:58 CET 2020

Hi folks,

Simon and I are very excited to announce the release of Wintun 0.9, the
release in which Wintun finally becomes easy and enjoyable to use by
developers. I consider this the most significant release of Wintun yet.

Webpage: https://www.wintun.net/

For background: Wintun is a driver for the Windows kernel that enables
userspace programs to create network tunnels. It's a "/dev/net/tun" of the
Windows world. We use this for WireGuard. We had investigated OpenVPN's "tap6"
driver but found it to be a crumbling mess with dubious security, and instead
endeavored to write a lightweight minimal replacement that obtains extremely
high speeds using a ring buffer, similar to Linux's io_uring.

Big Change 1: API Library and Easy Distribution

We used to rely on an obscure Microsoft technology for distributing Wintun,
called MSI Merge Modules (MSM), in which application writers would bundle the
signed MSM we provided as part of their MSI installer. This was great in that
it encapsulated a lot of logic and hid it from developers, but relying on MSM
was a hassle and precluded the use of Wintun in many non-MSI apps.

The MSM also would simply make sure the driver was installed, but wouldn't
provide anything else. It was up to developers to then navigate arcane Windows
driver instantiation APIs, which are some of the oldest and most obscure to
use. Then, once installed, developers had to manage a ring and various IOCTLs
themselves. It all worked -- WireGuard and OpenVPN (after receiving our
assistance) successfully deployed it -- but it was cumbersome enough that
nobody else was going to use this.

With Wintun 0.9, we're changing what we distribute and also providing an easy
to use API. Rather than shipping MSMs to developers, we now ship a single
basic boring wintun.dll. This dll hides all of the driver installation and
adapter instantiation logic, and provides a nice interface for managing
adapters and shuffling data in and out of the ring buffer. So, application
developers can now just grab that dll, plop it into their application like
they would any other dll, and use Wintun without even noticing that it's
inserting a kernel driver when necessary

Big Change 2: Support for WOW64 and ARM

Windows does not support setupapi.dll and related driver functions on 32-bit
processes running on 64-bit operating systems. This meant that it was
impossible for WOW64 processes to use Wintun. Wintun also formerly required
64bit addresses, which made the kernel ABI clumsy for WOW64 processes. With
Wintun 0.9, we now bundle a 64-bit version of Wintun inside 32-bit versions of
the wintun.dll, and we marshal calls back and forth to an on-demand proxy
process running on the native architecture.

Not only do we have this for basic WOW64, but we also have this working for
Windows' ARM64 emulation of x86 binaries. So you can now run an x86 program on
ARM64 and wintun.dll will figure out what to do.

This has big effects for us. Since Go still has not been ported to ARM64, we
use an ARM build and rely on this new feature of Wintun. This means we should
have a WireGuard for ARM64 Windows release in the coming week or two.

Big Change 3: Administrator User Permissions

Wintun requires the Local System user. But if you're running as Administrator,
the wintun.dll library will attempt to do its operations as Local System,
automatically. This effectively means that normal apps can bundle Wintun now,
rather than just services.

Please let us know if you have any questions or feedback. We're certainly
interested in developer reports on what integrating this is like.

- The API reference is available online:

- And there's some simple example code too:

- A signed wintun.dll for amd64, arm64, x86, and arm is on the webpage:

- And of course, it's open source:
  git clone https://git.zx2c4.com/wintun


More information about the WireGuard mailing list