5 ms·

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 -

by zx2c4 9y ago

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.html https://lists.zx2c4.com/pipermail/wireguard/2017-May/001338.... -- just email team@wireguard.com and I'll throw them in an envelope.

loeg 9y ago
How strongly do you feel about the GPL2 license (edit: for the kernel pieces)? Would you be willing to dual-license it under the BSD as well?
- zx2c4 9y ago
  The kernel code is for Linux, which is already GPLv2, so I don't think it would help you much there. The userspace implementation is also GPLv2 at the moment. What motivations do you have for desiring a BSD license? Plans to make non-free software?
  - jlgaddis 9y ago
    An in-kernel {Free,Open}BSD implementation is my first thought.
  - loeg 9y ago
    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.
    - zx2c4 9y ago
      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.
      - loeg 9y ago
        > 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.
  - justabystander 9y ago
    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.
- j_s 9y ago
  Based on progress demonstrated since June 2016, I'd say not any time soon. https://news.ycombinator.com/item?id=11996465 https://news.ycombinator.com/item?id=11996465
  - loeg 9y ago
    I'll keep asking ;-).
justabystander 9y ago
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.Vpn 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.
- zx2c4 9y ago
  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.
  - justabystander 9y ago
    > 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.htm 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?
majewsky 9y ago
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: [Interface] PrivateKey = ... ListenPort = 12345 [Peer] PublicKey = ... Endpoint = head1:12345 AllowedIPs = 0.0.0.0/0 [Peer] PublicKey = ... Endpoint = head2:12345 AllowedIPs = 0.0.0.0/0 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.)
- moreentropy 9y ago
  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).
  - pedrocr 9y ago
    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.
- zx2c4 9y ago

by zx2c4 9y ago

loeg 9y ago

How strongly do you feel about the GPL2 license (edit: for the kernel pieces)? Would you be willing to dual-license it under the BSD as well?

zx2c4 9y ago
The kernel code is for Linux, which is already GPLv2, so I don't think it would help you much there. The userspace implementation is also GPLv2 at the moment. What motivations do you have for desiring a BSD license? Plans to make non-free software?
- jlgaddis 9y ago
  An in-kernel {Free,Open}BSD implementation is my first thought.
- loeg 9y ago
  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.
  - zx2c4 9y ago
    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.
    - loeg 9y ago
      > 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.
- justabystander 9y ago
  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.
j_s 9y ago
Based on progress demonstrated since June 2016, I'd say not any time soon. https://news.ycombinator.com/item?id=11996465 https://news.ycombinator.com/item?id=11996465
- loeg 9y ago
  I'll keep asking ;-).

justabystander 9y ago

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.Vpn 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.

zx2c4 9y ago
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.
- justabystander 9y ago
  > 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.htm 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?

majewsky 9y ago

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: [Interface] PrivateKey = ... ListenPort = 12345 [Peer] PublicKey = ... Endpoint = head1:12345 AllowedIPs = 0.0.0.0/0 [Peer] PublicKey = ... Endpoint = head2:12345 AllowedIPs = 0.0.0.0/0 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.)

moreentropy 9y ago
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).
- pedrocr 9y ago
  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.
zx2c4 9y ago