[ANNOUNCE] Wintun: Layer 3 TUN Driver for Windows

[ANNOUNCE] Wintun: Layer 3 TUN Driver for Windows

[Jason A. Donenfeld]

Hi everybody,

[Cross-posting to WireGuard, OpenVPN, and Nmap/npcap mailing lists.]

Simon and I are pleased to announce the start of a new project, made
for WireGuard and for others too: Wintun, a layer 3 TUN driver for
Windows.

Homepage: https://www.wintun.net/

A TUN driver lets userspace programs act as virtual network cards,
reading and writing packets directly into the network stack, as though
they came from a real network adapter. While Linux and the BSDs have
had /dev/tun for ages, Windows typically hasn't had any native
facilities.

Recently, Microsoft released a VPN UWP API, but it's lacking in
features, documentation is under NDA, and after reversing it for a
bit, it doesn't seem capable of doing many of the more advanced
routing and roaming things we want. Indeed it turns out that having a
real network adapter and some basic file handles is much preferable to
layers of API and abstraction.

On the flipside, OpenVPN's tap-windows6 project and the numerous
drivers from SoftEther have all provided similar functionality for
many years, and these efforts have produced something moderately
stable. We were, in fact, quite inspired by SoftEther's Neo6 driver.
However, these projects were written in a different age, the era of
NDIS5, and then ported later to NDIS6. This means they haven't
benefited from things like Windows 7's NdisMediumIP, which allows for
native layer 3 tunneling, without having to do layer 2 emulation.
Drivers like OpenVPN's tap-windows6 also do some somewhat nasty
things, like emulate DHCP from inside the kernel for network
configuration. The code is old and complicated. As usual, I wanted
instead something tiny and dumb that we can reason about, which does
things in a "right" and "boring" way for a narrower use case: layer 3
TUN.

Wintun is our attempt at making a dumb layer 3 pipe, that doesn't do
anything fancy, and just shuffles bundles of packets between userspace
and the kernel driver. It's being used for WireGuard's Windows port.
We'd like to make it available and easy to use for other projects too
that need layer 3 userspace tunneling capabilities, like OpenVPN and
SoftEther. (Also, it may be just a matter of time before somebody
takes the tiny base of it, sticks the crypto in the kernel, and makes
WireGuard super fast on Windows.)

Have we succeeded in accomplishing our goals? Certainly not yet. At
the present moment [folks reading this in the future: check the date
of this email], I'd except for Wintun to be slower, buggier, and lower
quality than anything else out there. But we thought it'd be a good
idea to release sooner rather than later in order to have some more
eyeballs on it. It's the kind of codebase that _certainly_ needs some
cleanup and a thorough security audit. On the plus side, cloc(1) tells
me that it's only 950 lines. Still, NT programming is hard, and I'm
pretty certain we've made mistakes and left ugly corners. Consider
this email a statement of intent rather than an announcement of a
completed project.

So, if you're interested in NDIS programming and want to lend a hand,
don't hesitate to get in touch. We're eager for smart NT folks to help
us out.

Details are over on https://www.wintun.net/ where you may also find
rabbits bringing windows into tunnels. Enjoy!

Regards,
Jason
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [ANNOUNCE] Wintun: Layer 3 TUN Driver for Windows

[Alen Opacic]

[-- Attachment #1.1: Type: text/plain, Size: 3774 bytes --]

Download link for wintun.msi is not working.

sub, 23. ožu 2019. 02:05 Jason A. Donenfeld <Jason@zx2c4.com> je napisao:

> Hi everybody,
>
> [Cross-posting to WireGuard, OpenVPN, and Nmap/npcap mailing lists.]
>
> Simon and I are pleased to announce the start of a new project, made
> for WireGuard and for others too: Wintun, a layer 3 TUN driver for
> Windows.
>
> Homepage: https://www.wintun.net/
>
> A TUN driver lets userspace programs act as virtual network cards,
> reading and writing packets directly into the network stack, as though
> they came from a real network adapter. While Linux and the BSDs have
> had /dev/tun for ages, Windows typically hasn't had any native
> facilities.
>
> Recently, Microsoft released a VPN UWP API, but it's lacking in
> features, documentation is under NDA, and after reversing it for a
> bit, it doesn't seem capable of doing many of the more advanced
> routing and roaming things we want. Indeed it turns out that having a
> real network adapter and some basic file handles is much preferable to
> layers of API and abstraction.
>
> On the flipside, OpenVPN's tap-windows6 project and the numerous
> drivers from SoftEther have all provided similar functionality for
> many years, and these efforts have produced something moderately
> stable. We were, in fact, quite inspired by SoftEther's Neo6 driver.
> However, these projects were written in a different age, the era of
> NDIS5, and then ported later to NDIS6. This means they haven't
> benefited from things like Windows 7's NdisMediumIP, which allows for
> native layer 3 tunneling, without having to do layer 2 emulation.
> Drivers like OpenVPN's tap-windows6 also do some somewhat nasty
> things, like emulate DHCP from inside the kernel for network
> configuration. The code is old and complicated. As usual, I wanted
> instead something tiny and dumb that we can reason about, which does
> things in a "right" and "boring" way for a narrower use case: layer 3
> TUN.
>
> Wintun is our attempt at making a dumb layer 3 pipe, that doesn't do
> anything fancy, and just shuffles bundles of packets between userspace
> and the kernel driver. It's being used for WireGuard's Windows port.
> We'd like to make it available and easy to use for other projects too
> that need layer 3 userspace tunneling capabilities, like OpenVPN and
> SoftEther. (Also, it may be just a matter of time before somebody
> takes the tiny base of it, sticks the crypto in the kernel, and makes
> WireGuard super fast on Windows.)
>
> Have we succeeded in accomplishing our goals? Certainly not yet. At
> the present moment [folks reading this in the future: check the date
> of this email], I'd except for Wintun to be slower, buggier, and lower
> quality than anything else out there. But we thought it'd be a good
> idea to release sooner rather than later in order to have some more
> eyeballs on it. It's the kind of codebase that _certainly_ needs some
> cleanup and a thorough security audit. On the plus side, cloc(1) tells
> me that it's only 950 lines. Still, NT programming is hard, and I'm
> pretty certain we've made mistakes and left ugly corners. Consider
> this email a statement of intent rather than an announcement of a
> completed project.
>
> So, if you're interested in NDIS programming and want to lend a hand,
> don't hesitate to get in touch. We're eager for smart NT folks to help
> us out.
>
> Details are over on https://www.wintun.net/ where you may also find
> rabbits bringing windows into tunnels. Enjoy!
>
> Regards,
> Jason
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>

[-- Attachment #1.2: Type: text/html, Size: 4651 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [Openvpn-devel] [ANNOUNCE] Wintun: Layer 3 TUN Driver for Windows

[Arne Schwabe]

Am 23.03.19 um 02:04 schrieb Jason A. Donenfeld:
> Hi everybody,
> 
> [Cross-posting to WireGuard, OpenVPN, and Nmap/npcap mailing lists.]
> 
> Simon and I are pleased to announce the start of a new project, made
> for WireGuard and for others too: Wintun, a layer 3 TUN driver for
> Windows.

I wish you good luck in this endeavour and welcome the prospect of
having a better tun driver for Windows. We know that our own TAP/TUN
driver is a pain point for us as well and having a better alternative is
something we would definitively like to have/support a more modern driver.

> Wintun is our attempt at making a dumb layer 3 pipe, that doesn't do
> anything fancy, and just shuffles bundles of packets between userspace
> and the kernel driver. It's being used for WireGuard's Windows port.
> We'd like to make it available and easy to use for other projects too
> that need layer 3 userspace tunneling capabilities, like OpenVPN and
> SoftEther. (Also, it may be just a matter of time before somebody
> takes the tiny base of it, sticks the crypto in the kernel, and makes
> WireGuard super fast on Windows.)

If someone does that, it would be nice to have a bit more generic so we
can also push our openvpn keys to the driver. Our AEAD-GCM data format
and Wireshark's data format are reasonable close to use the same code
for it.

The lack of tap is not a big deal for OpenVPN anymore. The world shifted
quite a bit and tap support is not needed that much anymore. Android
does not support it. MacOS client supports tun natively (utun) and tap
requires extra kext. And so on...

> Have we succeeded in accomplishing our goals? Certainly not yet. At
> the present moment [folks reading this in the future: check the date
> of this email], I'd except for Wintun to be slower, buggier, and lower
> quality than anything else out there. But we thought it'd be a good
> idea to release sooner rather than later in order to have some more
> eyeballs on it. It's the kind of codebase that _certainly_ needs some
> cleanup and a thorough security audit. On the plus side, cloc(1) tells
> me that it's only 950 lines. Still, NT programming is hard, and I'm
> pretty certain we've made mistakes and left ugly corners. Consider
> this email a statement of intent rather than an announcement of a
> completed project.

I am afraid our project members are currently busy and cannot really
contribute much to your new shiny driver. We barely have enough time for
OpenVPN itself. But if you have something that is good enough at least
for testing and has a reasonable stable API just an extra mail and I
think we can implement it as alternative to our own driver.

> Details are over on https://www.wintun.net/ where you may also find
> rabbits bringing windows into tunnels. Enjoy!

Frome the site: The source code is provided under the GPL 2.0 and is
available via git:

One detail here. If you have/add a file that defines the API for
external programs, to license it under a freeer license for 3rd party to
include that API file without license worries. Like our tap-windows.h
(https://github.com/OpenVPN/tap-windows6/blob/master/src/tap-windows.h).
This was primarily requested by the Freeswan developer iirc.

Arne
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [Openvpn-devel] [ANNOUNCE] Wintun: Layer 3 TUN Driver for Windows

[Jason A. Donenfeld]

Hey Arne,

On Mon, Mar 25, 2019 at 11:23 AM Arne Schwabe <arne@rfc2549.org> wrote:
> I wish you good luck in this endeavour and welcome the prospect of
> having a better tun driver for Windows. We know that our own TAP/TUN
> driver is a pain point for us as well and having a better alternative is
> something we would definitively like to have/support a more modern driver.
> The lack of tap is not a big deal for OpenVPN anymore. The world shifted
> quite a bit and tap support is not needed that much anymore. Android
> does not support it. MacOS client supports tun natively (utun) and tap
> requires extra kext. And so on...

That's good to know. I wasn't aware that that perspective was there
for OpenVPN as well. It certainly makes things simpler. In that case,
I'll certainly try to continue to keep OpenVPN in mind when developing
this. And depending on everybody's time availability, maybe at some
point we could work together in adding experimental support for Wintun
in OpenVPN.

> I am afraid our project members are currently busy and cannot really
> contribute much to your new shiny driver. We barely have enough time for
> OpenVPN itself. But if you have something that is good enough at least
> for testing and has a reasonable stable API just an extra mail and I
> think we can implement it as alternative to our own driver.

Great. I'll send a follow-up when we're at that point. At the moment
we're working out some details with IO_CSQ, and then we'll try to put
together some half-decent API documentation to make this easy. Then,
I'll poke you and we can get rolling with this.

> Frome the site: The source code is provided under the GPL 2.0 and is
> available via git:
>
> One detail here. If you have/add a file that defines the API for
> external programs, to license it under a freeer license for 3rd party to
> include that API file without license worries. Like our tap-windows.h
> (https://github.com/OpenVPN/tap-windows6/blob/master/src/tap-windows.h).
> This was primarily requested by the Freeswan developer iirc.

That's a good point. I'll certainly do something like that. Or,
possibly I'll just relicense the whole driver to MIT so nobody has to
worry. Will give it some thought.

Jason
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard