Earlier this week, I was casually discussing various VPN’s with my colleagues. I’ve tried my hand at OpenVPN a couple times in my life, but was turned off by the complicated setup, poor iOS compatibility (at the time), and slow reconnection speeds. The conversation quickly came to revolve around a relative newcomer to the VPN world: wireguard. With the promise of ease of use, minimalistic code base, proven security, wireguard threatens to take the VPN world by storm.

Currently, the project is not yet complete, with no stable 1.0 version released currently. However, wireguard is under active development, apparently with multiple donors, to include PIA. Personally, I do enjoy simple, yet robust software. With wirebase’s codebase currently around 4K lines of code, the project should be much easier to debug and verify.

Wireguard will most likely be added to the Linux kernel within the coming months. Now since I predominantly use OpenBSD, and with most tutorials online being written with the Linux audience in mind, I figured that configuration on OpenBSD would be difficult. Boy was I wrong.

It literally took one article to show how to create a functioning point to point tunnel from my home router to my phone. It was so easy, that I thought about adding this VPN tech to the playbook for my home OpenBSD router project.

However, a single p-to-p tunnel doesn’t do a whole lot of good when you have more than one mobile user. A single tunnel required on tun* device to be configured. Logically, a new tun* device would need to be created for each new user. This would aid in tracking data usage to individual endpoints. But I would rather not have to create more devices than needed. But theoretically, using only one tun* for multiple endpoints would prevent me from being able to accurately track endpoint usage, with that data being limited to the overall usage of the tun device.

I had a bit of trouble being able to get multiple endpoints to be routed through a single tun* device, as they are designed to operate as p-to-p connection, from my understanding. I was able to get around that by adding a static route to the interface, as I will show below.

I started working on a wgctl script to help manage wireguard installation, configuration, and management, but it turned into a much larger project than I anticipated. Perhaps I will finish it one day. The first step for running wireguard on OpenBSD is to compile the code from source.

# Declare dir to build in

# Downloaded required packages
pkg_add gmake go

# Make build dir and cd
mkdir $builddir && cd $builddir

# Clone the repos
git clone https://git.zx2c4.com/wireguard-go
git clone https://git.zx2c4.com/WireGuard

# Let's make some binaries!
cd $buildir/wireguard-go
cp wireguard-go /usr/local/sbin/
cd $builddir/WireGuard/src/tools
cp wg /usr/local/sbin/

Next, let’s create the tun* interface. I chose to use tun3, but you could use whatever tun* device that is not currently in use. You may notice that the file below calls a server.conf file that we have not created yet.

!/usr/local/sbin/wireguard-go -f tun3 &
!/bin/sleep 2
!/usr/local/sbin/wg setconf tun3 /etc/wireguard/configs/server.conf
!/bin/sleep 2
!/sbin/route add -inet

We will also have to nat the interface. Add this line to your pf.conf, with the port specified being whatever you choose, but it will have to match the server.conf file that we will create later.

/etc/pf.conf addition
# Wireguard tunnel
pass in on egress inet proto { tcp udp } from any to any port 9832
pass out on egress inet from (tun3:network) nat-to (egress:0)

If you haven’t already, you will also have to enable inet forwarding as well, in sysctl.conf, or by running sysctl net.inet.ip.forwarding=1.

/etc/sysctl.conf addition

For wireguard to function, we will also need to generate some key pairs for the server itself, and for any clients we would like to connect. Shown below is the method to create one server key pair, and five client key pairs.

# Declare and make some paths
mkdir -p $keys

# Create the server's public and private keys
wg genkey | tee $keys/server-private.key | wg pubkey > $keys/server-public.key

# Create client keys 1-5
for i in {1..5}
    wg genkey | tee $keys/client${i}-private.key | wg pubkey > $keys/client${i}-public.key

Now let’s shed some light on the magic that are wireguard config files.

The server.conf file must include the server’s private key, created above at /etc/wireguard/keys/server-private.key, along with a port wireguard will listen on. This port must match whe port that was opened in pf.conf earlier. The server.conf must also include each client’s public key, as well as their allowed ip range, which must be unique for each client.

PrivateKey = [server-private.key]
ListenPort = 9832

PublicKey = [client1-public.key]
AllowedIPs =

PublicKey = [client2-public.key]
AllowedIPs =


Now for each client, the configuration is somewhat reversed.

The interface block here specifies client1’s allowed ip and range, as well as the DNS server of choice. Here, I simply use my router’s DNS record, since I have an unbound daemon running.

The ‘[peer]’ configured here is actually the wireguard server itself. The server’s public key is specified, as well as the current IP of the server. Please note, that if your router’s IP ever changes, this IP will have to be updated.

AllowedIP’s here specifies that all IP’s are accessible to the client.

Address =
PrivateKey = [client1-private.key]

PublicKey = [server-public.key]
Endpoint = [router egress ip]:9832
AllowedIPs =

At the very end of this walk-through, I will show you a script that I wrote to simplify creating keys and configuration files called wgkeys.sh. I also did integrate this qrencode command into wgkeys.sh. Once the libqrencode pkg has been installed, you can simply run the following to display client1’s qr code:

wgkeys.sh -q 1

The final step is to bring up the tun3 interface. This should initialize the device, start wireguard-go on tun3, insert the server.conf, and establish the static route.

sh /etc/netstart tun3

Using wireguard

Wireguard is easily managed by wireguard-go and wg.

# This will display the running config, server, and peers
wg show 

# This will show you the running config
wg showconf

# Start running wireguard on tun device. You should only have to do this once
wireguard-go -f tun3

# Use new config for tun3
wg setconf tun3 /path/to/server.conf

The basic usage is as follows:

  • Run ./wgkeys.sh to create the server and five client keys.
    • keys are stored in /etc/wireguard/keys
    • configs are stored in /etc/wireguard/configs
  • Run ./wgkeys.sh -q [1..5] to display a qr code that can be scanned by a mobile app. Please note that the libqrencode pkg must be installed for this to work.

Has been tested on OpenBSD 6.4