Introduction

In this article I want to talk about setting up a server and clients (in this case a vpn from OpenBSD.amsterdam) to work as a vpn.

The technology used in this case is wireguard because it is built into OpenBSD. No packages have to be installed for this tutorial.

For this tutorial I used a wonderful guide by Solene Rapenne
I had to make a few changes to Solenes setup, because the configuration only worked for me with one client. When using a second client, only the first client would have internet access and not the other one. I solved this issue by using 192.168.10.2/32 instead of 192.168.10.2/24 on the hostname.wg0 on the server. Unfortunately I do not know exactly why this is necessary.

The setup

I want to use several clients in conjunction with a server to connect the clients to the internet via a tunnel provided by wireguard. The vpn will consist of 3 machines: The server at 192.168.10.1 and the 2 clients at 192.168.10.2 and 192.168.10.3 respectively.

Private keys

Each machine needs a public key and a private key for wireguard. The private key can be generated with the following command:

openssl rand -base64 32

This command has to be issued for the server and the two clients as well. The out put of the command is used as the private key. In the /etc/hostname.wg0 config file this output is used for the first line that starts with wgkey myprivatekey. See the full config files below.

Public keys

In order to get the public keys for the wg0 interfaces you have to write the config files in /etc/hostname.wg0 for each machine like below, except for the public key. Now issue the command:

sh /etc/netstart wg0

This command will fail with an error, because the public key is still missing from the config file. But although the command has failed, it is now possible to retrieve the public key from ifconfig. It was automatically generated.

ifconfig wg0 | grep wgpubkey

Enter this public key in /etc/hostname.wg0 behind the wgpeer keyword. Repeat:

sh /etc/netstart wg0

Now the command will not fail anymore and wg0 is configured successfully.

Do the same on every machine.

Beware that the public key on the clients should be the public key of the server. And the public keys on the server hostname.wg0 are the public keys of the two clients.

sysctl rules on the server

Implement the following rule to enable ip forwarding. This is necessary, because on the server, the traffic is interchanged between two network interfaces.

sysctl net.inet.ip.forwarding=1
echo "net.inet.ip.forwarding=1" >> /etc/sysctl.conf

Firewall rules on the server

Open the port 4433 because we use it for wireguard. The nat rule is also crucial.

pass in proto udp to port 4433
pass out quick on egress from wg0:network to any nat-to (egress)
pass in on wg0 from (wg0:network)

Reload the firewall rules: pfctl -f /etc/pf.conf

hostname.wg0 at the server

wgkey myprivkey_server
wgpeer pubkey_client1 wgaip 192.168.10.2/32 wgpka 20
wgpeer pubkey_client2 wgaip 192.168.10.3/32 wgpka 20
inet 192.168.10.1/24
wgport 4433
up

hostname.wg0 at the client 1

wgkey myprivkey_client1
wgpeer pubkey_server wgendpoint 24.25.26.27 4433 wgaip 0.0.0.0/0 wgpka 20
inet 192.168.10.2/24
wgrtable 1
up
!route add -net default 192.168.10.1

hostname.wg0 at the client 2

wgkey myprivkey_client2
wgpeer pubkey_server wgendpoint 24.25.26.27 4433 wgaip 0.0.0.0/0 wgpka 20
inet 192.168.10.3/24
wgrtable 1
up
!route add -net default 192.168.10.1

hostname.urtwn0 at the client(s)

urtwn0 is a wifi interface, but for normal LAN nics it works the same way except that the first line is not needed.

join SSID wpakey password
rdomain 1
up
inet autoconf

Bypass the VPN on the client

If you need to bypass the VPN tunnel without changing the configuration of the network interfaces you can do this by using the route command. It is best to write a small shell script no_vpn and place it in ~/.local/bin (do not forget to chmod +x no_vpn):

#!/bin/sh

route -T 1 exec $1

Now you can execute a browser via command line by issuing:

no_vpn ungoogled-chromium

For this to work out you have to set an valid nameserver like 1.1.1.1 in /etc/resolv.conf. This is important, because most people use unwind on their PCs. unwind creates the entry nameserver 127.0.0.1 in /etc/resolv.conf. This address for localhost is not available in rdomain 0 anymore, so without the manual extra entry above you would have no name resolution with the no_vpn script.

/etc/resolv.conf should look like this:

nameserver 127.0.0.1 # resolvd: unwind
nameserver 1.1.1.1

Now name resolution works with VPN and without it.

Network printer and scanner

I have a HP Officejet Pro 8020 printer and scanner combi device. I recognized with this device that in my scenario with rdomain 1 as the default for the VPN to work printing and scanning won’t work anymore unless I return to rdomain 0.

This behaviour is of course not what I want. I want the printer and scanner to also work within rdomain 1.

The solution to this problem comes with assigning rtable 1 to the daemons involved: cupsd, cups_browsed and avahi_daemon. This is done with the following commands:

rcctl set cupsd rtable 1
rcctl set cups_browsed rtable 1
rcctl set avahi_daemon rtable 1
rcctl restart cupsd cups_browsed avahi_daemon

As scanning software I use skanlite. skanlite has to be executed for rdomain 1 explicitly:

route -T 1 exec skanlite

ssh

I also did this with sshd. For sshd I also edited the /etc/ssh/sshd_config:

...
ListenAddress 0.0.0.0 rdomain 0
ListenAddress 0.0.0.0 rdomain 1
...

rcctl restart sshd.

Now it is possible again to login via ssh.

ntpd

For ntpd I edited the /etc/ntpd.conf:

listen on 127.0.0.1
listen on 127.0.0.1 rtable 1
...

rcctl restart ntpd.

Conclusion

It took me a while to figure out all the details especially for the printer and scanner issue, but it all now works very reliably.