I recently published my OpenBSD-Wireguard project on GitHub. There is now a published wireguard role, found in my OpenBSD Dev repo, found here. Compared to some of my other playbooks, this one is fairly simple. All it does is configure a fresh OpenBSD server to act as a wireguard server, to which multiple connections over one tun3 device are allowed.

I have tested multiple times deploying the playbook in minutes to a Vultr VM. By the way, I would eagerly recommend vultr to anyone looking for a fast yet cheap VPS solution. I have had zero problems while using their services the past few months.

The OpenBSD-Wireguard project can be installed on any running OpenBSD installation, though I would highly recommend only installing it on a new server build. The playbook will overwrite multiple system files, including but not limited to, pf.conf, unbound.conf and various network files. This could accidental cause issues if the playbook is ran on a production server. Use at your own discretion, or use --check mode first!

I would like to go over a few of the configs deployed in playbook. I tried to configure as little as possible while ending up with a working wireguard server.


All this config does is ensure that the tun3 device remains up at all times. I personally have noticed that the iOS wireguard app will continue to try pushing data over a VPN, even if the remote tun device on the wireguard server is down. This causes the phone to not receive any data at all until the VPN is manually stopped on the client device.


I won’t post the entire unbound unbound here, as it too much to go over here. However, the one takeaway is that the service is only going to listen on the tun3 interface.


Again, I’d rather not go over more pf configs in this article. I plan to write up a long article just on pf one day. A couple of things to note though in the project’s pf.conf though, I do limit the bandwidth to 75M up and 75M down. This is the max that I’ve tested a 1 core, 1G RAM vultr VM. Also, I’d rather not hit the bandwidth cap in one day. If you would like to change this setting, please feel free.

I have commented out a block of code for pf queuing, for possible future use, but for the initial release, I did not see the benefit.


This is one of the more complicated interfaces I’ve set up on OpenBSD. Luckily, the BSD is very fluid in it’s approach with configuring tunnels.

That’s basically all their is to this playbook. The playbook does also push a handful of bash configs to root and the newly created admin user, and does switch the default shell to bash. This is done to make using OpenBSD a little more familiar for myself, so that my own systems remain similar.

Has been tested on OpenBSD 6.4

Updated 4/27/2019: Added link to newer repo.