WireGuarding the mainline

Quoting Linus Torvalds:[0]<p>&gt; I see that Jason actually made the pull request to have wireguard included in the kernel.<p>&gt; Can I just once again state my love for it and hope it gets merged soon? Maybe the code isn&#x27;t perfect, but I&#x27;ve skimmed it, and compared to the horrors that are OpenVPN and IPSec, it&#x27;s a work of art.<p>0) <a href="https:&#x2F;&#x2F;lwn.net&#x2F;ml&#x2F;linux-kernel&#x2F;CA+55aFz5EWE9OTbzDoMfsY2ez04Qv9eg0KQhwKfyJY0vFvoD3g@mail.gmail.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lwn.net&#x2F;ml&#x2F;linux-kernel&#x2F;CA+55aFz5EWE9OTbzDoMfsY2ez04...</a><p>Edit: fixed URL

I&#x27;m really looking forward to start experimenting with Wireguard. Jason A. Donenfeld is also the creator of my favorite password manager <a href="https:&#x2F;&#x2F;www.passwordstore.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.passwordstore.org&#x2F;</a> and recently I found a neat web frontend for git called cgit, lo and behold, when I looked it up I saw that Jason was the creator. He makes some really cool high quality stuff.

A couple of days ago I started testing with WireGuard and installed it to my Omnia Turris router. Mullvad provides WireGuard servers[0] for testing with a reasonable price, and I&#x27;ve been routing all the traffic from our apartment through WireGuard without any problems. The speed is just amazing after seeing the disappointing performance of OpenVPN, I can easily push 300-400 MB&#x2F;s through the router, finally removing the last reason to not use a VPN for all the traffic.<p>[0] <a href="https:&#x2F;&#x2F;mullvad.net&#x2F;en&#x2F;guides&#x2F;category&#x2F;wireguard&#x2F;" rel="nofollow">https:&#x2F;&#x2F;mullvad.net&#x2F;en&#x2F;guides&#x2F;category&#x2F;wireguard&#x2F;</a>

Does anyone know <i>why</i> reverse christmas tree order of declarations (i.e. longest to shortest line length) is part of the style guide?

That this has to be in the kernel is a failure of the Linux architecture. This is middleware.

&quot;He pointed out that Zinc cannot support hardware cryptographic accelerators, something that Donenfeld regards as a feature. &quot;<p>Why is not supporting hardware acceleration a feature? Or is the objection to something more specific having to do with currently-available accelerators?

Off topic: Does anyone have a good tutorial on setting up Wiregaurd on a cloud server to act as a VPN? I’m currently using Algo from Trail of Bits, which is great, but takes a lot on control out of my hands through its Ansible scripts.

What is the status of WireGuard in terms of client device support?<p>The main advantage of IPsec and OpenVPN is that they are either natively supported by all major OSs (desktop and mobile) or there are apps freely available for that purpose.

Does anyone know a good Windows client?<p>I only know TunSafe, which now has finally been open sourced. But it was still controversial software. So any alternative would be nice.

Wireguard looks awesome. Any news about a windows wireguard implementation?

&gt; <i>Andy Lutomirski was generally favorable as well, noting that he has tried to carry out some similar changes to the cryptographic code in the past. Support for hardware accelerators should, he said, be built on top of Zinc; code needing that support could then use the more complex API that would be required, and the Zinc implementations could be used as fallbacks when acceleration is not available or practical to use.</i><p>This seems like a flawless approach. The Zinc approach seems to be preferred (by those involved) for simple software-only use cases, and the more complex use cases seem to be composed of operations which Zinc could implement.<p>It&#x27;s good that they&#x27;re not just going to plop the thing in there in a degraded state (with probably worse performance [and DoS resistance] than the current out of tree&#x2F;dkms distributions of wireguard).