[zx2c4]

The OpenVPN Windows kernel TUN/TAP driver is really super scary. That alone has a larger code base than all of WireGuard...

At the moment, the efforts around the cross-platform userspace-based WireGuard implementations have focused on targeting that TUN/TAP driver, which is pretty ugly business. But thanks very much for pointing me toward this more general purpose API.

It might wind up being _easier_ to use this than having to talk to terrible OpenVPN kernel drivers. I'll investigate this thoroughly.

By the way, if you're into Windows programming and want to help out, don't hesitate to email [e-mail].

[justabystander]

> The OpenVPN Windows kernel TUN/TAP driver is really super scary.

I believe you. Everything about OpenVPN code scares me. Not sure if it helps, but I checked out an article by Dmitri Varsanofiev on using the TUN/TAP driver (http://www.varsanofiev.com/inside/using_tuntap_under_windows...) and it seems he was able to work with the driver from managed (C#) code without actually modifying the driver source at all. It seems he was just invoking two Win32 API call methods from Kernel32.dll: CreateFile and DeviceIoControl. If he can do it from C#, it should be doable from rust.

From his sample, it seems you could work with the tunnel device without modifying the source code at all. Although that means you've still got a major code wart from OpenVPN haunting you. And even if it works, I'm not sure if that's the recommended approach. But if you're insistent on supporting Wireguard on Windows versions before 10, the TUN/TAP driver might be the only route available. I don't think those VPN APIs existed in Windows 7 and I think they were private in 8/8.1, if memory serves.

The good news about the UWP APIs is that you once you confirm that it works, you could potentially get it up on the Windows store and make it easy for people to install and update. Though there's tons of notes that the VPN APIs are restricted, and you can only publish apps that use them after you get reviewed and your account gets those permissions. You can still sideload, (locally install) though. Honestly, I don't think the review would be a huge obstacle, though. I think Wireguard has some fans in MS.

> By the way, if you're into Windows programming and want to help out, don't hesitate to email [e-mail].

I mostly work on the managed side of things, but I try to keep fresh on APIs and platform features. I'm not sure my workload really allows me to be a major part of the project, but if you've got a public portal that tracks your tasks, I might be able to subscribe and pop in and do some legwork from time to time. Especially if someone's writing the core functionality in some DLL that's easy to call. Do you have a public issue tracker? Or is it mostly IRC and mailing lists?

[zx2c4]

> he was able to work with the driver from managed (C#) code without actually modifying the driver source at all

Yea, I wouldn't need to (or want to) modify the source, and using the actual driver from userspace isn't that bad. Also, having a pre-signed win32k driver is a nice thing that I wouldn't want to give up. My motivation is mainly to avoid using it all together, if possible, which is I think what the API you linked to prior will allow.

So the UWP API looks like the right way forward. I wonder if we could launch it as Win 10+ without too many complaints. Nobody is really using 8/8.1, but there are of course corporate Win7 holdouts.

> Do you have a public issue tracker? Or is it mostly IRC and mailing lists?

There's wireguard.com/todo/ but it hasn't been populated with the particular TODOs for the userspace stuff. But if you send me an email or come into the IRC, I can fill you in at the optimal time when it seems like _the one thing remaining_ is just to fill in some platform-specific stubs for win32. If that's appealing to you, of course.

[voltagex_]

Yeah, don't give up a signed driver on Win10+ at all - Microsoft are making it prohibitively expensive for new drivers: https://blogs.msdn.microsoft.com/windows_hardware_certificat...