This post is a bit wider than usual. This is to preserve the examples
intact and paste-able. Hopefully it looks allright in your client. Let me
know otherwise.
The last few weeks I've been experimenting with Wireguard on OpenBSD in
various ways. Since I saw that support showed up in the kernel a while
ago, I was curious what it could be used for. Turns out that it is nicely
integrated, so that utilities like ifconfig and pf can be used to control
wireguard-interfaces, and hence they can also be defined in "hostname.if"
to be started at system boot and so on.
The obvious first thing was to try to set up a server, which I did quite
easily on a VPS:
This can be a bit clunky though. What I opted for instead is to use
rdomains and rtables to set up a separate routing table for the
wg-interface on the peer. That way, I can utilize pf on the peer to
control which traffic goes through the tunnel, or use "route -Tn exec" to
run specific applications in that specific rdomain, making it only go out
via the wg-interface. This is what I ended up with:
Here, I set the interface to belong to the rdomain 1, and I also add the
default routes, but to the rtable 1 in rdomain 1. I also set up a
loopback-interface so stuff that expects to be able to bind to it can do
that. This may or may not be desired. In my specific use-case, I used it
because the tor-browser-bundle expects to be able to bind to 127.0.0.1,
which it cannot if it's not available in the rdomain. Next, I used some
rules in pf to re-direct DNS to specific servers reachable through
wireguard. In this case, it's an unbound-instance running on the
wireguard-server, and I wanted all DNS-requests to go to that server. So I
did something along these lines on the peer:
pass out on rdomain 1 proto { udp tcp } from any to any port 53 \
rdr-to 192.168.100.1 port 53
This will make any traffic towards anything on port 53 (either tcp or udp)
be redirected to 192.168.100.1. This will force DNS-requests happening in
the rdomain go to a server on the other side of the tunnel. Once this is
done and the pf-config and brought up the interfaces, you should be able
to do stuff like this on the peer:
The first example should go through the default routing table, showing
your public IP. The second should go through the tunnel, and show the
corresponding public IP for that system. Success! (Hopefully). With this,
you can do all sorts of interesting things. You could for example run:
route -T 1 exec ksh
This will give you a shell belonging to rdomain 1, and hence, any process
spawned in that shell will inherit that. This is a simple way to not have
to prepend the route/exec-combination to run stuff through the tunnel.
So I hope that you enjoyed this little post. It may be a bit unclear, but
it's also a bit of a mental note to myself, even though the idea of
sharing it here is to give others a way to utilize similar solutions as
well. I've had a lot of fun with this during the last few days, and
hopefully it can be meaningful for others as well. Please send me some
feedback if you enjoyed it!
