Aquilenet

---

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®](https://wireguard.com/) 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)](https://man.openbsd.org/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](https://www.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)](https://git.zx2c4.com/wireguard-tools/about/src/man/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)](https://man.openbsd.org/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)`](https://man.openbsd.org/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)](https://man.openbsd.org/unwind.8), with an [`unwind.conf(5)`](https://man.openbsd.org/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)`](https://man.openbsd.org/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)](https://man.openbsd.org/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)](https://man.openbsd.org/pf.4) needs to be configured to be more restrictive. 

[sshd(8)](https://man.openbsd.org/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)](https://man.openbsd.org/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.