We were slowly, but surely laying down the foundation for our final setup in the Wireguard VPN series. We setup the site to site connection, we made it persistent. Now we put the last piece together; the on-the-go VPN on your smartphone! This is where you shine in eyes of your significant other. Think of all that UK Netflix you will watch.

There are native Android & iOS applications for Wireguard, in this article, I will be focusing on Wireguard on iOS. Having said that let's jump in and prepare.

Requirements

You will need to download the official Wireguard application which can be fetched from here: App store. Now we can move to the actual setup.

There are 3 ways how to configure your VPN connection in Wireguard app:

1. Create from QR code.
2. Create from scratch.
3. Create from file.

I prefer the first option, as it's quick to use, once you setup all the necessary tooling for it. Here you can get creative.

The setup

First off, I assume you already have a working Wireguard setup, including working NAT rules in place, if not feel free to refer to the linked guide in the header of this article.

Generate Wireguard peer configuration

Your smartphone will act as an another peer in Wireguard network, therefore we will need to configure public & private keys for it. This can be done via following command:

wg genkey | tee iphone_lubos.key | wg pubkey > iphone_lubos.pub

Add peer's public key into your Wireguard config

Once you get your keys setup, it's time to add the peer's public key into your Wireguard configuration, so the peer gets to access your VPN.  To add the peer's public key into your configuration simply append following line into your main wg0.conf file:

[Peer]
PublicKey = 9fC02smHeQ79BMhWcxlHtAXMm5ptvBYL8A2oOWyVDzw=
AllowedIPs = 0.0.0.0/0

Make sure that the AllowedIPs is set to 0.0.0.0/0; this is necessary as our VPN server has to accept connections from any IPs from this peer. Remember in this case the AllowedIPs acts as a sort of access control list for the peer and you won't know ahead of time what external IP your peer(smartphone) will have when connecting to the VPN. Now apply the updated Wireguard configuration file to your Wireguard interface via following command:

wg setconf wg0 wg0.conf

With all this in place, your VPN instance is now ready to accept connection from your peer, so let's move to the peer configuration.

Peer configuration

As mentioned in the beginning of this article, I said that I prefer the configuration via QR code, however before we can generate a QR code, we should prepare the configuration file itself. The file is also useful, if you go with the setup method 2 and 3.

In the second case you can use the prepared file as a reference for typing down the configuration manually; that takes ages, but who am I to judge. In the third case you can simply share the file with the peer either via email/slack/etc and the peer can just load it and call it a day.

Back to our road warrior VPN configuration for the peer. It should look like this:

[Interface]
Address = 10.170.1.3/32
DNS = 192.168.1.122
PrivateKey = ch0R012Uq/IKAKQwTfGCuqCnrQ4BcTnYimOFpsz23Wk=

[Peer]
PublicKey = IYF1xaxijfg0f05y3fR4NIOzFJrmkPFkB5Y52yWW2AE=
Endpoint = x.x.x.x:51871
AllowedIPs = 0.0.0.0/0

Let's quickly walk through the parameters that we are setting in the Interface section we have two parameters:

• Address this should be an IP from our VPN network range that gets assigned to this peer, i.e in my case I went with 10.170.1.0/24 range, therefore I gave 10.170.1.3 to this peer.
• DNS sets the IP of the DNS server that our peer will use to resolve hostnames. Very crucial parameter, we need to make sure that we set this in order not to leak our IP by not making DNS resolution via our public IP.
• PrivateKey pretty self explanatory, it's the value of the private key that we generated at the start of this guide.

In the Peer section we 3 parameters that have to be set:

• PublicKey it's the value of public key of our VPN server. Not your peer's!
• Endpoint is the external IP and port of your VPN server that is reachable from the Internet.
• AllowedIPs this is the part where you either make it or break it, set it to 0.0.0.0/0 nothing else.

Remember, on the peer side the AllowedIPs parameter acts as a routing table for the peer. It tells Wireguard application to route traffic for all the IPs via your VPN tunnel, this is where the magic is.

We are almost done! Now you have 2 options how to get the QR code; the nerd way via command line or the boring way googling on how to generate QR code on the web and then leaking your private key to the Internet.

Generating QR code

If you don't want to install any fancy binaries on your VPN server, then just search the web for QR code generator and paste your peer configuration file in it. For example this one does the trick for your: Web based QR code generator. Please note, that using this method you might be sending sensitive stuff to a 3rd party server, which introduces security risk!

Now, if you take your security and safety seriously you should generate the QR in a safe manner. This can be done via command line tool such as qrencode. On Debian based systems the installation is as simple as running:

apt install qrencode

Getting a QR code in a secure manner is as easy as this, as demonstrated in the above gif. You can accomplish the same by running the command:

qrencode -t ansiutf8 < peer.cfg

If you wish to send the generated QR code as an image to the peer, you need to generate the image. This is done by running the following command:

qrencode -t png -o qrcode.png < peer.cfg

The payday; adding the connection to Wireguard application

With all the hard work we have done so far; we are getting there. Our sweet forbidden UK Netflix is almost within our grasp. Last thing we need to do is to scan the QR code with our Wireguard application and we are all set.

Wireguard application is very easy to use, you just click the blue plus icon in the top right corner of UI and a menu will pop up. Select Create from QR code and scan the QR code. Name your VPN connection and you are done.

Life behind 20 VPNs

As you can see, the setup was again straightforward with Wireguard, we managed to quickly generate a peer configuration for our smartphone, add it to the smartphone via a hefty QR code that we also generated. Now all that is left is to enjoy your secure connection via VPN.

Now, we can take our VPN experience one more level further! We can configure Wireguard application in such a way, that it will automatically enforce VPN connection based on our connection type. For example you can force it to use VPN whenever you are connected to the internet via cellular or you can also set it up to connect to VPN, whenever you are connecting via unknown WiFi. This is especially useful, if you don't want your IP to be leaked on public WiFis, or you don't want your background traffic being sniffed prior turning VPN on manually.

To set it up open up Wireguard application:

• Click your VPN connection.
• In the top right corner click Edit
• Scroll all the way down to the On-demand activation
• Configure your rules for On-demand.
• In my case I have VPN always on, when on cellular and Wifi expect of my home Wifi.

Aaaand done! Cheers, enjoy watching unlimited UK Netflix without any limitation! Assuming your VPN server is UK based.

Building on top of what we have setup in the last article: Site to Site VPN guide with Wireguard we should probably make our routing setup persist in between restarts. We don't want our work to vanish after a reboot and render our infrastructure unavailable, are we?

Now with our objective defined, how do we tackle this? First off, as mentioned in the previous article I run Debian stable which means that the networking stack isn't managed via systemd-networkd, but rather via /etc/network/. Therefore this configuration will be assuming you run the same.

To refresh your memory in my setup, I have only 2 peers:

• Peer 1 in home site acts as a gateway to my LAN.
• Peer 2 acts just as a standard Wireguard peer.

Configuration

Most of the configuration will be added to the interfaces configuration file that can be found at /etc/network/interfaces
One small change will be added to your sysctl configuration file, generally found at /etc/sysctl.conf

Peer 1 - Home Site (vpn.m8.sk)

This is where I keep main part of the network configuration as this peer is our entry gateway to my LAN, therefore it acts as a router for any incoming traffic to LAN from my VPN network device.

This router functionality is achieved by running a NAT, that enables 2 networks( 10.170.1.0/24  & 192.168.0.0/16) to interact between each other.

The specific configuration how to achieve this functionality is following:

# VPN Tunnel
auto wg0
iface wg0 inet static
   address 10.170.1.1/24
   netmask 255.255.255.0
   pre-up ip link add dev wg0 type wireguard
   pre-up wg setconf wg0 /data/containers/conf/vpn.m8.sk/wg0.conf
   pre-up iptables -A FORWARD -o wg0 -j ACCEPT
   pre-up iptables -t nat -A POSTROUTING -o enp1s0 -j MASQUERADE
   post-down ip link delete dev wg0
   post-down iptables -D FORWARD -o wg0 -j ACCEPT
   post-down iptables -t nat -D POSTROUTING -o enp1s0 -j MASQUERADE

As you can see there is nothing fancy going on, Wireguard accepts simple configuration, therefore we don't do any real magic in here. Let's go through what is being set:

• We specify what interface we want to configure.
• We assign IP address and broadcast to the interface.
• Before we bring up the network device, we create it.
• Once the network interface is created, we assign Wireguard configuration to it.
• Now, the main part! We setup NAT via iptables. Thing to watch out for is that you need to specify your main network interface that has access to your LAN in here. In my case this is enp1s0 and that's it!
• Last few bits are just cleanup commands for when we bring down the interface. In short, it deletes the network device and removes the setup NAT.

Last bit is to make sure that our Linux kernel knows how to forward ip packets. This can be achieved by adding following line into your /etc/sysctl.conf

net.ipv4.ip_forward = 1

With all this said, that's it. We don't need to do any further configuration on Peer 1. We can now verify that the setup works by rebooting our Peer 1

Peer 2 - Remote Site (hertzner-box)

Peers that will be connecting to your LAN via VPN, don't need any fancy NATs. The only thing that we need to add to the standard network interface configuration is a static route to our LAN.

We apply somewhat similar configuration, again to the same file located at /etc/network/interfaces:

# VPN Tunnel
auto wg0
iface wg0 inet static
   address 10.170.1.2/24
   netmask 255.255.255.0
   pre-up ip link add dev wg0 type wireguard
   pre-up wg setconf wg0 /data/containers/conf/vpn-2.m8.sk/wg0.conf
   up ip route add 192.168.0.0/16 dev wg0
   post-down ip link del dev wg0

This configuration is not that different than the first one, so let's go through the differences:

• The only difference is that after we bring the interface up, we setup a static route to my LAN. In this case 192.168.0.0/16 via wg0 VPN interface.

Setup wise we are done, let's test and see, if our configuration works!

We can see that the configuration works, and once the interface is brought up it gets setup properly and it automatically connects to Peer 1. In case you would have more peers, you just repeat the above configuration as many times as you have peers. Assuming your peers are setup properly for Wireguard in the first place.

Reverse route bonus!

Now that our remote site can access our LAN in our home site and the configuration is persisted, we should maybe look into the way, how we can enable our LAN clients to access VPN network without the need to install VPN!

Say no more! This part is specific for EdgeRouters, if you have other router taking care of your LAN, you will have to find the appropriate settings yourself.

Login to EdgeRouter WebUI, navigate to Routing section in the upper right menu bar. Once there, click the Add Static Route button.

Following window will pop up, here you will have to fill it based on your network configuration. In my case, my VPN network subnet is 10.170.1.0/24 and my VPN instance in home site that handles the VPN connections has an address 192.168.1.170/32

Once set, your configuration should look like something around these lines:

Now, it's testing time! Let's SSH into some of my machines in home site and test pinging one of our clients in VPN network.

Bingoo, everything works as a charm. Now I can reach my remote sites from all my devices on LAN and all my servers in remote sites can reach LAN without an issue. This opens up a lot of possibilities for the future projects! Let's see what will be our next project

Connecting your remote locations with your home network has never been so easy!

For quite a long time I've been running 2 sites, my home lab running multiple docker containers, VMs and many more devices that utilized LAN. Then for heavy duty stuff I pay for dedicated servers hosted at commercial datacenters, these run ElasticSearch clusters, Grafana/Prometheus stack and this website for example.

Whenever I needed to connect my "on-premise" stuff with remote infrastructure, I've always done it in a dirty way via SSH tunnels, this most of the time worked fine thanks to combination of autossh running in Docker, but it involved intermediate step of setting up the tunnel, whenever I wanted to connect some service between the sites, which at times could be cumbersome. I always wanted to have a proper site to site connection, but I've never put effort into setting it up, so here we are!

Why Wireguard?

I had prior experience with OpenSSL, but it just seemed too complex for this task. In the past I've also run tinc VPN which I really liked, but I felt like trying something new, so with a bit of searching around I stumbled upon Wireguard.

Some of the things I like about Wireguard

• Runs in Linux kernel, instead of userspace. This gives it the speed performance over OpenVPN or any other VPN that runs in userspace.
• Very simple configuration, you will see later down ;)
• Uses simple network interface, no need to play with taps and tuns!

Now without further ado, let's jump to mine setup.

Target Setup

What I need to achieve is to be able to call my home site network(192.168.0.0/16) from my remote site. For example Dedicated server in remote site needs to be able to call a service on my home network directly via it's IP, let's say 192.168.1.200. Here is what I've done to make it work.

Preparation

First off, we have to install Wireguard kernel module and the tools. I run most of my infrastructure under Debian Stable and at the time of writing this article Wireguard is not in the stable repository therefore I will have to use Backports. Luckily the process is pretty straightforward. If you use anything else refer to: Link

1. Add following line into your /etc/apt/sources.list:

echo 'deb http://deb.debian.org/debian buster-backports main' >> /etc/apt/sources.list

2. Afterwards update the list of available packages from the new repository you have added:

apt update

3. Install Wireguard:

apt-get -t buster-backports install "wireguard" -y

Configuration

Now that we have installed all the dependencies let's set this up!
The setup is fairly easy and this is the beauty of using Wireguard, however there are few things that we will cover, as it was not that clear to me from the documentation because I didn't read it thoroughly and I struggled little bit because of it.

As you can see in the diagram I show above, we will have 2 Wireguard peers. But before we proceed to exact configuration steps, we should specify baseline of our setup.

VPN interface: wg0
VPN network: 10.170.1.0/24
VPN port: 51871

Peers should be able to handle traffic for the VPN network itself, but also for my LAN network. Therefore we can say that allowed networks should be: 10.170.1.0/24, 192.168.0.0/16. We will get to why this is necessary to specify later when we go through the configuration file.

As we have sorted out what we want to setup, we can now move to the specific configuration steps. I usually like to keep configuration files together therefore I've created following folder structure on my Peer 1 VM.

root@vpn:/data/containers/conf/vpn.m8.sk# tree
.
├── certs
│   ├── hertzner-box
│   │   ├── hertzner.key
│   │   └── hertzner.pub
│   └── vpn.m8.sk
│       ├── vpn.m8.sk.key
│       └── vpn.m8.sk.pub
├── peers
│   └── wg0_iphone_lubos.conf
└── wg0.conf

5 directories, 8 files

Peer 1 - Home Site (vpn.m8.sk)

This peer is located in my home site and this is the configuration I decided to go with:

First off every single Wireguard peer needs to have its set of keys, this consist of a public and private key that is used for encryption and decryption of transmitted/received data and it is also used for the peer authentication.

Assuming we are in the folder certs/vpn.m8.sk we can run following command to generate private and public key for my Peer 1

wg genkey | tee vpn.m8.sk.key | wg pubkey > vpn.m8.sk.pub

This will create 2 files that will have private and public key in it respectively:

root@vpn:/data/containers/conf/vpn.m8.sk# cat *.pub *key
mdv9qFDGcfG5ec2Opk/fNhz84albmcdS2dlKoOeSEQg=
yNdDrdkpcIdTyI11fqPDEY2lMk09I+kYbRKjA9yG320=

We repeat the same command, but this time we change to folder certs/hertzner-box and we also adjust the output file names to hertzner.key and hertzner.pub.

In my case I have only 2 peers, therefore I don't need any additional key pairs, however, if you would have more peers you just repeat the commands, you can also run the commands on the any of the peers, or even your machine, if you have wg installed.

Now that we got our key pair we can create our initial configuration, which should look like this:

[Interface]
PrivateKey = yNdDrdkpcIdTyI11fqPDEY2lMk09I+kYbRKjA9yG320=
ListenPort = 51871

[Peer]
PublicKey = FqB69gnqdHtsST7R3QKVMZGNfUTFGFltqrKL343xdy5=
AllowedIPs = 10.170.1.2/32, 192.168.0.0/16
Endpoint = xxx.xxx.xxx.xxx:51871

I store this main configuration inside a file called wg0.conf which is in the base of my main configuration folder in this case /data/containers/conf/vpn.m8.sk

The file follows INI configuration format and consists of two sections: [Interface] and [Peer].

Interface

The interface section contains configuration properties for your VPN interface:

• The PrivateKey property takes the value of your private key that is stored in certs/vpn.m8.sk/vpn.m8.sk.key
• ListenPort property is the UDP port where you wish to receive VPN traffic.

If you follow guides on the Internet some of them also include configuration properties like:

• Address
• PreUp, PostUp, PreDown, PostDown

These properties are used by the wg-quick tool, but are not valid for the wg command!

Peer

The peer section contains configuration properties for your VPN peers, i.e the VPN clients that will connect to this VPN instance. For every single peer(client) that should connect to this specific VPN instance you have to set the [Peer] section.

Peer section holds following configuration properties:

• PublicKey holds the value of public key of the peer, in this case that would be certs/hertzner-box.pub
• AllowedIPs in the context of Peer section acts as a sort of ACL, i.e it tells our VPN instance what packets it should accept. In this case packets coming for 10.170.1.2/32, 192.168.0.0/16 are accepted by the instance.
• Endpoint property is access interface of your peer, i.e IP and a port combination where VPN instance can send the traffic to.

AllowedIPs property has also a second use, when sending the data from the VPN instance to it's peers, in this case the property is used as a sort of routing table, telling our VPN instance that the peer will accept the traffic for networks 10.170.1.2/32, 192.168.0.0/16 This is very crucial to understand when setting up Wireguard as you might run into issues, when AllowedIPs are not set properly.
For more examples I recommend reading the official documentation: Link. This was the part I skipped over initially when reading the documentation and it cost me some trial and error until I fixed it.

Network device

Now that we have our Wireguard configuration ready, we can move to setup of our network device that will be used by Wireguard. As promised by Wireguard, this is very simple and all you need is the ip command.

First off, you want to create a new network interface:

ip link add dev wg0 type wireguard

Then you need to assign it an IP address, we decided to use the range 10.170.1.0/24, therefore I will just use the first IP in the range for the Peer 1

ip address add dev wg0 10.170.1.1/24

Once we assign the IP, it's time to load our Wireguard configuration that we have prepared in the last step. Assuming we are in the configuration folder we setup earlier we run following command:

wg setconf wg0 wg0.conf

With all this in place we are now ready to bring up the wg0 interface up on Peer 1. You can do that via following command:

ip link set up dev wg0

What surprised me was the status of the interface after I brought it up, however this is normal:

root@vpn:/data/containers/conf/vpn.m8.sk# ip link show wg0
3: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none

We can now move on to the setup of Peer 2!

Peer 2 - Remote Site (hertzner-box)

I won't go into much details, as most of the details have been covered when we were preparing Peer 1. For Peer 2 we only need to prepare the configuration file and setup the network interface. Key pair doesn't need to be generated as we have already did that on Peer 1, therefore we just need to copy over the values.

Configuration for our Peer 2 should look like this:

[Interface]
PrivateKey = cCPxAr8vKhQtR4fFIgZF/j3cHXcW2oD8XytOHqwFlXo=
ListenPort = 51871

[Peer]
PublicKey = IYFNx4xijfW0805yqfR4NIOz5JrmkPFkB5Y02y6W2AE=
AllowedIPs = 10.170.1.1/32, 192.168.0.0/16
Endpoint = xxx.xxx.xxx.xxx:51871

I will now go briefly over the differences:

• PrivateKey should contain the value of certs/hertzner-box.key
• PublicKey should contain the value of certs/vpn.m8.sk.pub

As you can see the roles now switched and our home site acts as a Peer of remote site VPN instance. Make sure you don't mix up the keys in this configurations as then the authentication won't work.

Once you are done with the configuration file for the Peer 2 VPN instance we can move onto setting up the network interface.

Network device

We will repeat the same commands that we have used for Peer 1

ip link add dev wg0 type wireguard
ip address add dev wg0 10.170.1.2/24
wg setconf wg0 wg0.conf
ip link set up dev wg0

Please note that I have assigned different IP to the Peer 2! In this case second IP from our range, which is 10.170.1.2/24

Testing the VPN tunnel

With all the steps done on all of your Peers we can test the tunnel connectivity. I have no firewalls in place, therefore I just used simple ping from both sites.

As you can see in the picture both sites respond to the ping test! This confirms that we have successfully connected remote and local site. However, we are not done yet! Remember, we wanted to access my LAN network from the Remote site! so let's try that now:

This doesn't work out of the box and we get to why in the next section.

Routing from VPN network to LAN network.

In order to route traffic between our VPN network(10.170.1.0/24) and our LAN network(192.168.1.0/16) we need to setup few things:

• All remote peers need to have a static route to the LAN.
• Our Wireguard peer in LAN has to act as a router for routing traffic between VPN network and LAN network.

Routing

Setting up a static route is very simple on all the remote peers run following command:

ip route add 192.168.0.0/16 dev wg0

This will make sure that all the traffic for the 192.168.0.0/16 gets routed through wg0

NAT

In order to properly connect two networks together we will have to setup NAT on our VPN instance that is hosted in home site.
Add following iptables rules to enable the NAT:

iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o enp1s0 -j MASQUERADE

wg0 is our VPN network interface, enp1s0 is your main network interface that can reach your LAN.

Once that is set, you will need to tell the Linux kernel to forward ip packets:

sysctl -w net.ipv4.ip_forward=1

And with this in place we are done!

Wrap up

Now that we have managed to setup everything we can test our setup!

As you can see I am able to ping my LAN network from the remote site, I can even reach my IoT  network.

Please note that all the interface configurations that we setup are temporal, meaning that they will go away after you reboot your server. If you would like to see how to set this up permanently please read this article of mine: Persistent routing for your site to site Wireguard VPN

Also the sites are connected one way, e.g I am not able to call VPN network from inside my LAN network, this is something I want to setup in the future.

I've got a bonus!! I did brief tests with iperf3 to test out the network performance. My remote site has full 1gbit connection to the outside. My home site has 300/30Mbit.

TCP without VPN

I managed to push 229Mbit/s from my remote site to my home site without VPN.

TCP with VPN.

Now the interesting part, tests via VPN. I hit whooping 200Mbit