OpenBSD

I’ve been running a OpenBSD server as my home router for a number of years now, moving between various configuration, scripts, and hardware. I’ve been running on the FW1 for a year now. I originally built the router as an escape from both ISP-provided router/modem combos, as well as custom firmware such as dd-wrt; I wanted more control.

Ever since I was a teenager, I always enjoyed the command line interface. It let me instruct EXACTLY what I wanted the OS to do, and have more control than any GUI out there. However, one area on my router that has always annoyed me was UPnP. This was, as far as I knew, a necessary evil. Without UPnP, online games had a difficult time with multiplayer.

A few years ago, I became fed up with my ISP-provided modem-router combo due to lagginess, sluggish DNS, and overall untrustworthiness. I ended up purchasing a Linksys WRT1900 and flashing it with dd-wrt, which chugged along happily for a couple years. However, later in its life, the router would sometimes stop responding, and lazily I would simply reboot it. Slowly, this pattern started occurring more and more frequently, up until the end of its life.

I decided to make a change. I had been using OpenBSD and Freebsd on and off for a better part of ten years, and I figured it was about time to move to a router that I could trust.

This is an announcement for a new repo I made on GitHub. Since I am constantly testing new deployments on vultr, I realized that it would make my life easier if I put all of my current projects into one public repo, to ease scripted deployments on Vultr.

This new repo will hopefully be the location of future projects, which may make their way into other public repos of mine. Be warned, it will probably be changing often, and may be broken at times.

In a previous article, I wrote of my OpenBSD-Wireguard ansible configuration that I’ve been using for my personal VPN’s recently.

Using Vultr’s startup scripts in addition to the OpenBSD-Wireguard ansible playbook, one is able to deploy a wireguard VPN to any of Vultr’s datacenters within ten minutes. This includes the OS installation by Vultr, as well as the playbook execution following a final reboot.

Welcome to part two of using WireGuard on OpenBSD! The first post was about the initial release of the project; This followup is about one new role added to the playbook. Now in the initial release, I wasn’t attempting to compile wg or wireguard within the playbook itself. I had just planned to update the binaries every day/week with a cronjob run on one of my servers. However, thank you reddit user techsnapp for pointing out that there is actually a script that wireguard provides to assist in compiling the software on OpenBSD. This post will go over the new role written to reliably download and compile wg, wg-quick, and wireguard-go.

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.

Even though I am such a proponent of OpenBSD, and BSD’s in general, my first foray into opensource was actually with linux. Since I was so young at the time, all I really seemed to care about was gnome vs kde. I quickly learned about the importance of the command line, and gradually shifted to become more interested in more minimal window managers. Trying out wm’s like fluxbox, openbox, and ratpoison, I quickly became obsessed with the minimal.

I eventually settled on using i3wm on my thinkpad for awhile, but have since moved to simply ssh’ing into my servers from a chromebook. However, I recently game calm window manager a try, and have since fallen in love.

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.

Having the ability to rebuild a server/router from scratch in minutes with confidence, versus slaving over all your configs, trying to get everything working is life changing. I can’t remember how many times I’ve rebuilt a computer, only to run into an issue that I KNOW I’ve fixed before… over a year ago. With ansible, all the work goes into the first deployment, giving you the ability to redeploy a server at a moments notice.

OpenBSD does require some extra options to work properly, as ansible seems to work best with Linux. Hopefully my struggles can help some of you.

Being able to take off from work, and the next morning, be able to hop back into my tmux session from the day before is truly lifechanging. I used a custom screen config for a little while before stumbling across tmux. I read into tmux one day at work, and was simply amazed at how much easier it was to configure than screen! This led me to conduct an in-depth comparison between tmux and screen. Did you know, screen has some 254 known bugs? Some go back to 2005 the last time I checked.

Tmux is an active project that is significantly easier to configure, and just as stable in my experiance.