---

Title: Setting up a WireGuard® client with routing domains on OpenBSD
langs: en

Breaks: False¶

Setting up a WireGuard® client with routing domains on OpenBSD¶

Matthieu Herrb - last edited october 24, 2020.

OpenBSD-current recently got native support for the Wireguard® VPN, thanks to the work of Matt Dunwoodie and Jason A. Donefeld. Their code was merged by David Gwynne.
This is great, especially since I've been using WireGuard for various purposes already.
A local assocative ISP here in Toulouse is offering WireGuard based VPNs for 5€/month.
In this note, I'm going to show how to setup a machine running OpenBSD to connect to this kind of VPN, using routing domains to make the VPN the default interface.

This configuration can be used to get a fixed public IPv4 and IPv6 address for a self-hosted server to run any kind of internet services.

General principle¶

The client machine is going to connect to the internet via any kind of LAN that provides IPv4 DHCP auto-configuration.
It can be an ADSL or fiber modem at home or some enterprise network.
The only serious requirement is that UDP traffic on the WireGuard (51820) port goes out.
This connexion is only going to be used to connect to the VPN, and will be setup in routing domain 1.
The Wireguard connexion is going to be the egress connexion in the default routing domain (0).

In this setup there is no need to provide complicated routing or packet filter configuration.
All traffic will go through the VPN "naturally" as the default routing domain only knows about the VPN interface.

Routing Domains and routing tables¶

For those not familiar with routing domains and tables on OpenBSD, it is recommended to read the rdomain(4) manual page.
Routing domains are separated network address spaces in the OpenBSD kernel.
Each routing domain has at least one routing table, separated from the routing tables of other domains.
Network interfaces belong to one domain and are not usable by the others.
Also, processes are running inside a routing domain, using by default the default routing table of their domain.
So their network traffic can only use the interfaces in this domain.

So routing domains and tables are a great way to isolate network trafic between processes.

WireGuard® at Tetaneutral.net¶

The Tetaneutral.net non-profit ISP provides WireGuard based VPN connections with one fixed IPv4 address and a /56 IPv6 prefix.
When you subscribe to the service, you provide the public key for your end point, and Tetaneutral gives you back the assigned IP adresses and the IP address, port number and public key of the VPN endpoint.

It is likely that many other ISP providing WireGuard based VPNs will work approxymately the same as Tetaneutral, and thus this can be expaned easily.
You can even setup your own WireGuard VPN service using OpenBSD, but this is out of the scope of this note.

Let's go !¶

OpenBSD installation¶

OpenBSD is installed as usual on the machine, setting up the network connection for the network on which it is going to have its internet access.
In this example the re0 interface is going to be used for this. So with DHCP /etc/hostname.re0 looks like:

dhcp

Obtaining VPN parameters¶

Install the wireguard-tools package, to have access to the wg(8) command:

$ pkg_add wireguard-tools

Now the parameters for the VPN are needed. For this a private key will be generated using the following commands:

$ umask 077
$ wg genkey > /etc/wg0.key

The corresponding public key is displayed by the following command:

$ wg pubkey < /etc/wg0.key

Note: if you don't want to install the wireguard-tool package, the wg(4) manual page describes an alternate way to generate the private key and display the public key using tools in the base system.

To obtain the remaining of the parameters, contact the VPN provider and send them the public key shown above.
They should reply providing:

(the values below are fake examples)

• the IP and port number of their endpoint: 198.51.100.116 51820
• the public key of their endpoint: Qay+wLckmRMr08t/9psjhrltJ0T4xb0m8++gQj0FpEA=
• the IPv4 and IPv6 prefix assigned to your endpoint: 203.0.113.3/32 and 2001:db8:8087:300::/56 respectively.
• the addresses of the DNS servers that can be used inside the VPN: 198.31.100.10 and 198.51.100.11

Keep those informations somewhere, to use them later.

Moving the default interface to rdomain 1¶

Now edit /etc/hostname.re0 to add a rdomain directive to move this interface to rdomain 1:

rdomain 1
dhcp

That's it. If the machine is rebooted at this point, most processes won't have network access since only routing domain 1 has network access. So do not reboot for now.

Creating the VPN interface¶

A wg0 interface for the VPN is going to be setup. For this create the /etc/hostname.wg0 file, containing (using the fake information form the provider shown above):

up
wgkey <your wg private key>
wgpeer Qay+wLckmRMr08t/9psjhrltJ0T4xb0m8++gQj0FpEA= wgrtable 1 wgendpoint 198.51.100.116 51820 wgaip 0.0.0.0/0 wgaip ::/0
inet 203.0.113.3 255.255.255.255
inet6  2001:db8:8087:300::1 56
! route add default -link -iface wg0
! route add -inet6 default -link -iface wg0

The last two lines set up the default route for rdomain 0 via the wg0 interface.

Once /etc/hostname.wg0 is created, the /etc/wg0.key file created previously can be removed.
It was only used to keep the private key while obtaining the remaining information needed to create hostname.wg0

Setting up the DNS¶

There are different options to tell the VPN client which DNS resolvers to use.
The issue is that /et/resolv.conf still contains the adresses of the DNS servers on the LAN, provided by dhclient(8).
Generally when using a VPN you don't want to use those, because they will leak the domains that the users of the VPN are connecting to.

Simple forwarding¶

The simplest solution is to use the supersede option of dhclient.conf(5) to replace the DHCP provided servers by the ones provided by the VPN provider. This will be the contents of /etc/dhclient.conf:

supersede domain-name-servers 198.51.100.10, 192.51.100.11;

Using unwind(8)¶

Another option is to set up unwind(8), with an unwind.conf(5) configuration file specifying the VPN name servers as forwarders.

Add the DNS servers provided by the VPN provider in /etc/unwind.conf (see unwind.conf(5) for details):

forwarder { 198.51.100.10 192.51.200.11 }

Activate unwind with

rcctl enable unwind

And edit /etc/dhclient.conf to contain:

prepend domain-name-servers 127.0.0.1 ;

This solution also allows processes in routing domain 1 to use the DNS servers provided by the DHCP server.

SSH access from the LAN¶

If you want to be able to continue accessing the machine from the lan it is connected to, /etc/ssh/sshd_config needs to be told to also listen to routing domain 1.

ListenAddress 0.0.0.0 rdomain 0
ListenAddress :: rdomain 0

ListenAddress 0.0.0.0 rdomain 1

Otherwise, after reboot, the machine will only be accessible from the console and with SSH though the VPN.

Rebooting¶

And that's it. The machine can now be rebooted.
All processes in the default routing domain (0) will only see the lo0 and wg0 interfaces, while the dhclient process needed to bring up re0 will be in routing domain 1.
The wgrtable keyword in the wg0 interface configuration tells it ue use the routing table of routing domain 1 to reach the remote VPN endpoint.

Checking that it works¶

After rebooting, let's review the setup by cheching the wg0 interface:

# ifconfig wg0
wg0: flags=80c3<UP,BROADCAST,RUNNING,NOARP,MULTICAST> mtu 1420
    index 6 priority 0 llprio 3
    wgport 47326
    wgrtable 1
    wgpubkey <public key>
    wgpeer Qay+wLckmRMr08t/9psjhrltJ0T4xb0m8++gQj0FpEA=
            wgendpoint 198.51.100.116 51820
            tx: 45564, rx: 71200
            last handshake: 107 seconds ago
            wgaip ::/0
            wgaip 0.0.0.0/0
    groups: wg egress
    inet  203.0.113.3 netmask 0xffffffff
    inet6 2001:db8:8087:300::1 prefixlen 56

And the default routes:

# route -n show  | grep default
default            link#6             ULS        5      229     -     8 wg0  
default                            link#6                         ULS        0        4     -     8 wg0

You can test that all traffic will go through the VPN using traceroute(8).
The machine is reachable from the internet using both its public IPv4 and IPv6 addresses.

Finally, the ps command with option -o rtable will show routing table information in the last column:

# ps xau -o rtable
USER       PID %CPU %MEM   VSZ   RSS TT  STAT   STARTED       TIME COMMAND          RTABLE
root         1  0.0  0.0   468   408 ??  I       4:43PM    0:01.02 /sbin/init            0
root     95458  0.0  0.0   788   620 ??  Ip      4:43PM    0:00.24 /sbin/slaacd          0
_slaacd  30350  0.0  0.0   792   676 ??  Ip      4:43PM    0:00.08 slaacd: engine (      0
_slaacd  69167  0.0  0.0   800   720 ??  Ip      4:43PM    0:00.08 slaacd: frontend      0
root     59774  0.0  0.0   704   528 ??  IU      4:43PM    0:00.02 dhclient: re0 [p      1
_dhcp    30649  0.0  0.0   828   656 ??  Ip      4:43PM    0:02.77 dhclient: re0 (d      1
root     35197  0.0  0.1   548  2252 ??  IpU     4:44PM    0:00.02 syslogd: [priv]       0
_syslogd  1991  0.0  0.1  1120  1384 ??  Ip      4:44PM    0:00.14 /usr/sbin/syslog      0
root     76166  0.0  0.0   836   584 ??  IU      4:44PM    0:00.01 pflogd: [priv] (      0
_pflogd   9499  0.0  0.0   884   564 ??  Sp      4:44PM    0:01.26 pflogd: [running      0
_ntp     45580  0.0  0.1  1044  2872 ??  I<p     4:44PM    0:00.72 ntpd: ntp engine      0
_ntp     59996  0.0  0.1   888  2560 ??  Ip      4:44PM    0:00.09 ntpd: dns engine      0
root     30954  0.0  0.1   848  1616 ??  I<pU    4:44PM    0:00.06 /usr/sbin/ntpd        0
root     75315  0.0  0.1  1328  1496 ??  I       4:44PM    0:00.16 sshd: /usr/sbin/      0
root     60900  0.0  0.1  1716  2028 ??  Ip      4:44PM    0:00.07 /usr/sbin/smtpd       0
_smtpd   65700  0.0  0.2  1448  3832 ??  Ip      4:44PM    0:00.08 smtpd: klondike       0
_smtpd   90699  0.0  0.2  1656  4044 ??  Ip      4:44PM    0:00.07 smtpd: control (      0
_smtpd   31369  0.0  0.2  1536  3936 ??  Ip      4:44PM    0:00.07 smtpd: lookup (s      0
_smtpd   45982  0.0  0.2  1596  4064 ??  Ip      4:44PM    0:00.06 smtpd: pony expr      0
_smtpq   17106  0.0  0.2  1664  4048 ??  Ip      4:44PM    0:00.08 smtpd: queue (sm      0
_smtpd   94920  0.0  0.2  1444  3872 ??  Ip      4:44PM    0:00.05 smtpd: scheduler      0
_sndiop  35803  0.0  0.0   524   936 ??  IpU     4:44PM    0:00.00 sndiod: helper (      0
_sndio   61376  0.0  0.0   536   808 ??  I<p     4:44PM    0:00.00 /usr/bin/sndiod       0
root     97224  0.0  0.0   204   836 ??  I       4:44PM    0:00.01 /usr/sbin/apmd -      0
root     98386  0.0  0.1   668  1312 ??  Sp      4:44PM    0:00.08 /usr/sbin/cron        0
root     27323  0.0  0.0   940   932 p0  Ip      5:13PM    0:00.36 -ksh (ksh)            0
root     49147  0.0  0.0   484   432 p0  R+pU/3  6:30PM    0:00.00 ps -xau -o rtabl      0
root     42404  0.0  0.1   316  1312 C1  I+pU    4:44PM    0:00.03 /usr/libexec/get      0
root     52228  0.0  0.1   320  1308 C2  I+pU    4:44PM    0:00.02 /usr/libexec/get      0
root     71695  0.0  0.1   316  1308 C3  I+pU    4:44PM    0:00.03 /usr/libexec/get      0
root     90445  0.0  0.1   320  1320 C5  I+pU    4:44PM    0:00.03 /usr/libexec/get      0

Only the dhclient(8) processes are in the non-default routing domain 1.

What's next ?¶

As already said above, the machine is now reachable from the internet.
So perhaps pf(4) needs to be configured to be more restrictive.
sshd(8) can be configured to refuse password based authentication, in order to avoid brute force attacks.

You can then point a domain (leased from a registrar) to the IP addresses of the machine and httpd(8) can be set-up to provide web based services on this domain.

Or another interface can be added to that host to convert it into a router to connect to another network.
This can be either another physical interface or a vlan interface over the existing re0 interface.