WireGuard is currently implemented as a kernel module for Linux. Although this offers advantages over a user space implementation, both in terms of speed and latency, there are obvious reasons for also desiring a user space implementation:
-
Portability. A user space implementation is easier to port for a wide range of platforms, users of Windows, OSX and BSD in addition to older versions of Linux cannot currently use WireGuard.
-
Permissions. The environment may not allows for the installation of a kernel module (such as OpenVZ or in Docker) In the future, WireGuard will hopefully make it into the kernel itself mitigating some of these issues, but people are likely to run old Linux kernels well into the foreseeable future.
-
Ideology. Although the code base of the kernel module is small, some people believe that VPN clients/servers belong in user space.
My goal has been to create such a user space implementation in Golang.
The code can be found at:
git.zx2c4.com/wireguard-go/tree
The current version compiles and works (with the following disclaimer) on Linux, OSX and Windows (using the OpenVPN TAP driver).
Due to the nature of WireGuard, where peoples life, privacy and liberty may depend on the correctness of the software I do not consider the software anything but experimental before the code has been thoroughly reviewed by a number of people. In addition the kernel implementation is also under heavy development and the specification still subject to change.
The implementation functions with the CAP_NET_ADMIN capability. The interface is configured using the wg tool found in the WireGuard repository (no need to build/install the kernel module itself).
The application must be run as root to create the TUN device.
The WireGuard tools compile on OSX and functions the same.
Tools (wg & wg-quick) for configuring the interface (UAPI client) are not available on this platform yet. These tools are not part of the project. Testing was done by using a python script to write transcripts of the UAPI protocol to the bidirectional pipe on the Windows system.
This version requires the OpenVPN Tap-windows driver (NDIS 6)
It was a goal to achieve performance exceeding that of OpenVPN, the implementation out performs OpenVPN by a significant margin and fully saturates a gigabit connection using commodity laptop hardware. The primary reason for the difference in performance is the use of multi-threading and the speed of the cryptographic primitives employed in WireGuard (OpenVPN does 2 passes over the content).
Although the current version functions (with the previous disclaimer in mind).
The following 4 things must be fixed before the implementation is ready for use by the general public:
Due to the API in golang.org/x/crypto/* and the nature of Go, handling cryptographic secrets in a satisfactory way is currently challenging.
A common practice within the /x/crypto packages is providing a "New" function which returns an instance implementing an interface (e.g cipher.AEAD or hash.Hash), with the result that cryptographic state is stored on the ordinary heap (where it may be swapped to disk).
This issue is of great importance due to WireGuards forward secrecy guarantees.
This also includes additional measures to contain the process (e.g separation from the file system)
After an incoming datagram is received and authenticated, subsequent messages send to the peer should originate from the destination address of the datagram. There is no obvious way to do this within the net package, but required for the implementation to work correctly behind NAT in some cases.
According to the specification, a WireGuard implementation should respond to a number of error events with ICMP messages. These include (among others) when there is no peer configured for the given destination address (when handling an outbound packet).
I plan on working on the 4 points mentioned above with a primary focus on Linux. I hope the announcement of an experimental user space implementation will attract additional contributors, primarily on platforms for which WireGuard is not currently available (OSX, Windows and BSD).