OpenBSD Journal

WireGuard imported into OpenBSD

Contributed by Janne Johansson on from the passive vpns with aggressive cryptos dept.

In the following commit (and a bunch of others), David Gwynne (dlg@) imported most of the code submitted recently by Jason A. Donenfeld and Matt Dunwoodie to allow you to use WireGuard natively on OpenBSD:

CVSROOT:	/cvs
Module name:	src
Changes by:	dlg@cvs.openbsd.org	2020/06/21 06:11:26

Modified files:
	sys/net        : if.c 
Added files:
	sys/net        : if_wg.c if_wg.h wg_cookie.c wg_cookie.h 
	                 wg_noise.c wg_noise.h 

Log message:
add wg(4), an in kernel driver for WireGuard vpn communication.

thanks to Matt Dunwoodie and Jason A. Donenfeld for their effort.
it's at least as functional as the go implementation, and maybe
more so since this one works on more architectures.

i'm sure there's further development that can be done, but you can
say that about anything and everything that's in the tree.

ok deraadt@

The WireGuard VPN protocol has been available on OpenBSD as a port for a while, first as the wireguard-go implementation in Go, but later also as the wiresep port in C, both using tun(4) devices, much like OpenVPN and others, which incurs a slight penalty for crossing the kernel/userspace border for each packet.

WireGuard is a layer3 tunnel that can be run in passive mode, only sending packets when something needs to reach the other side (unless you enable heartbeats). It only allows selected modern crypto algorithms and hashes, chosen to be performant on CPUs which lack crypto accelerators, while still being secure. WireGuard packets are sent over UDP, and can run over and transport both IPv4 and IPv6. It handles NAT/port redirects and endpoints changing IP addresses, which is very nice when changing from wired to wifi or vice versa.

Jason and Matt have been busy making WireGuard work natively on OpenBSD, and sent a huge patch to tech@ recently [see earlier report] in order to be able to run it on OpenBSD, using ifconfig(8) and with kernel support for the wg(4) interfaces.

After three submitted patch revisions, dlg@ has now started to import it into base, and it should be enabled in GENERIC kernels soon.


Update 24 June 2020: wg(4) has been enabled and is now available in the latest snapshots:

CVSROOT:	/cvs
Module name:	src
Changes by:	dlg@cvs.openbsd.org	2020/06/23 17:35:39

Modified files:
	sys/conf       : GENERIC 

Log message:
enable wg(4).

this will make testing easier for everyone.

from Jason A. Donenfeld and Matt Dunwoodie
ok deraadt@ tobhe@

We take it for a quick spin on two vmm(4) virtual machines running the latest amd64 snapshot:

test1$ doas ifconfig wg0 create wgport 9999 wgkey `openssl rand -base64 32`
test1$ doas ifconfig wg0 wgpeer PvZvkFVrCX9bV1JG4BkGqRhmcbXt9KG3INwUJSbT7mE= wgendpoint fe80::fce1:bbff:fed1:c6db%vio0 9999 wgaip 10.0.0.1/32
test1$ doas ifconfig wg0 10.0.0.2/24

test1$ doas ifconfig wg0
wg0: flags=80c3<UP,BROADCAST,RUNNING,NOARP,MULTICAST> mtu 1420
        index 6 priority 0 llprio 3
        wgport 9999
        wgpubkey 5nYUSIRp3RlfRclN7Fz5KtFnLCECxxHJmL9TLmwE0A8=
        wgpeer PvZvkFVrCX9bV1JG4BkGqRhmcbXt9KG3INwUJSbT7mE=
                wgendpoint fe80:1::fce1:bbff:fed1:c6db 9999
                tx: 2608, rx: 2608
                last handshake: 82 seconds ago
                wgaip 10.0.0.1/32
        groups: wg
        inet 10.0.0.2 netmask 0xffffff00 broadcast 10.0.0.255

and

test2$ doas ifconfig wg0 create wgport 9999 wgkey `openssl rand -base64 32`
test2$ doas ifconfig wg0 wgpeer 5nYUSIRp3RlfRclN7Fz5KtFnLCECxxHJmL9TLmwE0A8= wgendpoint fe80::fce1:bbff:fed1:c6d9%vio0 9999 wgaip 10.0.0.2/32
test2$ doas ifconfig wg0 10.0.0.1/24

test2$ doas ifconfig wg0
wg0: flags=80c3<UP,BROADCAST,RUNNING,NOARP,MULTICAST> mtu 1420
        index 5 priority 0 llprio 3
        wgport 9999
        wgpubkey PvZvkFVrCX9bV1JG4BkGqRhmcbXt9KG3INwUJSbT7mE=
        wgpeer 5nYUSIRp3RlfRclN7Fz5KtFnLCECxxHJmL9TLmwE0A8=
                wgendpoint fe80:1::fce1:bbff:fed1:c6d9 9999
                tx: 2608, rx: 2608
                last handshake: 123 seconds ago
                wgaip 10.0.0.2/32
        groups: wg
        inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255

With that, the wireguard interfaces on test1 and test2 are created and configured. You can now reach one from the other over the VPN:

test1$ ping -c 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes
64 bytes from 10.0.0.1: icmp_seq=0 ttl=255 time=1.484 ms
64 bytes from 10.0.0.1: icmp_seq=1 ttl=255 time=1.309 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=255 time=1.549 ms

--- 10.0.0.1 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 1.309/1.447/1.549/0.101 ms

(Comments are closed)


Comments
  1. By Sebastian Rother (rother) gerd.sebastian.rother@googlemail.com on

    Do not get the following WRONG: I like the Protocol so far, I am thakfull for the work of others but my Crtic for OpenBSD would be:

    Write a Fuzzer, own the Kernel.. like with the USB Stack....
    Won't belief me? You do not have to. I am just a Voice on the Internet.

    It is a simple Protocol, you "mature Guys" can write Fuzzers, can't you?
    I was told it is easier for simple Protocols...

  2. By Amit Kulkarni (amitkulz) on

    A modern VPN in base!

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]