Contributed by Janne Johansson on from the passive vpns with aggressive cryptos dept.
In the following
(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: firstname.lastname@example.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: email@example.com 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
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)