Greg KH, some others, and I had a great session stepping through every line of the codebase yesterday. Even though the codebase is quite small -- under 4k LoC -- studying some of the related topics is kind of like a fractal...
Happy to answer any questions you all might have about WireGuard. We're in #wireguard on Freenode, too, if you need help with things in real-ish time. I'm also mailing out free stickers to anybody who wants some: https://lists.zx2c4.com/pipermail/wireguard/2017-May/001338.... -- just email team@wireguard.com and I'll throw them in an envelope.
First of all, love the project. Thanks for tackling it and sticking to it.
I know that talking about a windows client is really early at this point, but is your team considering implementing it in a way that actually uses the UWP VPN provider interfaces (https://docs.microsoft.com/en-us/uwp/api/Windows.Networking....) instead of (or in addition to) the OpenVPN-style system tray app? I know there's been some strides towards using UWP from rust. And if you're thinking about it, early consideration might give extra time for any necessary interactions with MS.
It would be really nice to have an open-source VPN implementation actually integrate with the OS, and I think it might provide the impetus people need to ditch OpenVPN. So even if you don't plan on directly working to integrate with the OS interfaces, please consider referencing the APIs when working on userspace libraries. Keeping the needs in mind could at least simplify any future efforts in that regard.
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 team@wireguard.com.
> 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 team@wireguard.com.
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?
> 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.
Hi Jason, thanks for your work on Wireguard! I evaluated it just a few weeks ago for my own usecase, but couldn't get it to work yet. Maybe you can tell me what I'm missing.
My usecase is as follows: I have a number of systems without publicly-routable IPs (i.e. behind NAT in different private networks) and two servers with public IPs (let's call these "head1" and "head2"). I want to build an overlay network between all of these servers, so that they can all reach each other. Since any of the two head servers may be down for whatever reason and I may not always have time to immediately investigate the problem, I want to have a highly-available setup where, upon failure of one head node, traffic goes over to the other head node without long disruption. I tried to give the clients a configuration like this:
But when I set up the wg0 interface with that configuration, it would discard the AllowedIPs setting for head1 upon finding the head2 peer with the same AllowedIPs value (at least according to `wg`). Am I doing something wrong, or is this an inherent limitation of Wireguard? (The fineprint: I did this two weeks or so ago and am recalling this from memory right now, so I may be wrong in the details.)
WireGuard enforces a very strict mapping between public keys and IP addresses, so you can't have two public keys with the same internal tunnelled IP address ("AllowedIPs"). This way you can have rules like "if it comes from the WireGuard interface and it's from 10.8.3.9, then it must be from public key ABCD," which make firewalling and ACLs and the general security posture a lot more straightforward.
In your case, it sounds like you want to change the AllowedIPs from one peer to the other based on some kind of metric you have for determining disruption. In this case, you can do that switch at runtime:
$ wg set wg0 peer ABCD allowed-ips 0.0.0.0/0
or
$ wg set wg0 peer EFG9 allowed-ips 0.0.0.0/0
Alternatively, if you wish to determine this disruption situation using traditional routing daemons, that set actual routes, as opposed to WireGuard AllowedIPs, then you could just have two separate WireGuard interfaces, and leave it to your routing daemon to decide which one to use.
You can't have overlapping AllowedIPs for peers on the same interface. Wireguard has to decide which encryption/decryption keys to use based on the AllowedIPs.
For your use case you need two wg Interfaces on each host (w/ different ListenPort and AllowedIPs=0.0.0.0/0) and a routing daemon (like bird).
So wireguard is focused on the use case of having a single central point where all the traffic has to go through? Reading throught the page it seemed it was more the tinc model of distributed P2P VPN overlay which to me seems much more powerful. Redundancy comes for free and performance is improved because you get direct links between nodes instead of having to proxy all the traffic.
Porting to FreeBSD, where new GPL2 code in base is verboten. Whether you consider FreeBSD non-free or not is a matter of opinion.
Even if the existing kernel implementation is highly tied to Linux, it is legally problematic for FreeBSD developers to reference GPL2 code while writing BSD-licensed code.
I think for FreeBSD kernel-land, there will have to be significant rewrites, anyway, since the Linux code is fairly Linux-specific. At some point though, I'd love to do a kernel implementation for the BSDs (in addition to the userspace one, which is coming much sooner), and I suppose you could expect for that to be BSD-licensed, appropriately.
> I think for FreeBSD kernel-land, there will have to be significant rewrites, anyway, since the Linux code is fairly Linux-specific.
Probably true!
> At some point though, I'd love to do a kernel implementation for the BSDs
If BSD developers can reference the Linux implementation's source, it is easier for them to go ahead and do it independently :-). Do you anticipate having time to do a BSD kernel implementation soon yourself, or is it just a would-be-nice idea on the infinite TODO list? I'm trying to gauge whether we should wait for you or try and do it ourselves.
It might not be about commercializing so much as including it in some of the *BSDs which don't allow for GPL code in the core. Otherwise, they'll probably have to write a new implementation. But yes, there is that risk.
Happy to answer any questions you all might have about WireGuard. We're in #wireguard on Freenode, too, if you need help with things in real-ish time. I'm also mailing out free stickers to anybody who wants some: https://lists.zx2c4.com/pipermail/wireguard/2017-May/001338.... -- just email team@wireguard.com and I'll throw them in an envelope.