The Lone C++ Coder's Blog

The Lone C++ Coder's Blog

The continued diary of an experienced C++ programmer. Thoughts on C++ and other languages I play with, Emacs, functional, non functional and sometimes non-functioning programming.

Timo Geusch

4-Minute Read

I’ve blogged about putting together a WireGuard server using OpenBSD a couple of years back. The main purpose of the server was to ensure a slightly more secure connection when I was on hotel WiFi. Of course thanks to the pandemic, I have barely travelled in the past couple of years so the server was mostly dormant. In fact, I kept VM turned off for most of the time. The VPN server was set up on OpenBSD 6.6, which was the last release that supported user mode WireGuard and didn’t have an in-kernel implementation. It was finally time to change that as part of an upgrade to OpenBSD 7.0.

With OpenBSD you can’t skip releases when upgrading, so I had to upgrade to 6.7 first. OpenBSD 6.7 introduced in-kernel WireGuard, so that upgrade was the one that required most of the work. The main changes I had to make after the upgrade to OpenBSD 6.7 were as follows:

  • Uninstall the user mode WireGuard package (specifically wireguard-go). Don’t forget to remove the call to /usr/local/bin/wg in /etc/rc.local
  • Remove the tunnel device by removing hostname.tun0. Make sure that you keep the information about IP address settings etc though as you’ll need that in the next step.
  • Create an /etc/hostname.wg0 file to set up the WireGuard pseudo device. This pretty much only required converting the existing WireGuard configuration file by taking information out of at /etc/wireguard/server.conf and putting into hostname.wg0 while converting it to the new syntax. This sounds more daunting than it really is and turned into a five minute copy paste job. Both files contain exactly the same information, it’s the syntax that is different and as usual with OpenBSD, the man page describes the new syntax well.
  • Update /etc/pf.conf - my pf.conf was nat’ing the data from the VPN interface and because I made the change from using a tunnel device (tun0) to using wg0, I had to tweak the NAT rule.
  • Reboot or bring up the new interface and netstart it. I chose to reboot because I had made some other minor configuration tweaks at the same time.
  • Test that the VPN still works in the new configuration. In my case it did without any hiccups.

At this point I followed the expected upgrade sequence 6.7->6.8->6.9->7.0. I used the Interactive Upgrade method as the VPN server don’t have all source sets installed (no games or X11) and I wanted to keep it that way. My understanding of using sysupgrade is that it will install all packages. Is it a big deal if I do? Not really, the server has enough disk space, but I didn’t see the point of having packages I’ll never use.

Pretty much all of the other changes I had to make were due to general changes between 6.6 and 7.0. There aren’t that many outside the ones described in the upgrade documentation. The main changes I had to make were:

  • Update the hostname.<interface> file for the physical network interface the machine has. This is not strictly necessary as the older configuration syntax is still supported, but I decided to update the configration syntax to get rid of a deprecation warning. That sounds grander than it was, because it basically means to replace the -autoconfprivacy parameter for IPV6 configuration with -temporary.
  • Disable resolvd. The VPN server already had a local unbound instance configured that acts both as a validating and filtering DNS server. The latter being important because it filters advertising, known scam and social media domains. OpenBSD 7.0 will have resolvd update the local resolver config dynamically based on the interface configuration unless it detects a running instance of unwind. I don’t want this autoconfiguration in this case, so I ended up disabling resolvd and manually corrected my resolv.conf. If I only wanted to have a local validating DNS server I could switch to unwind, however I haven’t looked deeply into this and I know my unbound configuration works as is. It’ll be interesting to hear if unwind can also handle domain filteration rules, but right now that is not necessary.

Recent Posts

Categories

About

A developer's journey. Still trying to figure out this software thing after several decades.