💻 [runtimeterror $]

2021-10-28

Cloud-hosted WireGuard VPN for remote homelab access

For a while now, I've been using an OpenVPN Access Server [1] virtual appliance for remotely accessing my homelab [2]. That's worked _fine_ but it comes with a lot of overhead. It also requires maintaining an SSL certificate and forwarding three ports through my home router, in addition to managing a fairly complex software package and configurations. The free version of the OpenVPN server also only supports a maximum of two simultaneous connections. I recently ran into issues with the `certbot` automated SSL renewal process on my OpenVPN AS VM and decided that it might be time to look for a simpler solution.

[1] OpenVPN Access Server

[2] homelab

I found that solution in WireGuard [3], which provides an extremely efficient secure tunnel implemented directly in the Linux kernel. It has a much smaller (and easier-to-audit) codebase, requires minimal configuration, and uses the latest crypto wizardry to securely connect multiple systems. It took me an hour or so of fumbling to get WireGuard deployed and configured on a fresh (and minimal) Ubuntu 20.04 VM running on my ESXi 7 homelab host, and I was pretty happy with the performance, stability, and resource usage of the new setup. That new VM idled at a full _tenth_ of the memory usage of my OpenVPN AS, and it only required a single port to be forwarded into my home network.

[3] WireGuard

Of course, I soon realized that the setup could be _even better:_ I'm now running a WireGuard server on the Google Cloud free tier, and I've configured the VyOS virtual router I use for my homelab stuff [4] to connect to that cloud-hosted server to create a secure tunnel between the two without needing to punch any holes in my local network (or consume any additional resources). I can then connect my client devices to the WireGuard server in the cloud. From there, traffic intended for my home network gets relayed to the VyOS router, and internet-bound traffic leaves Google Cloud directly. So my self-managed VPN isn't just good for accessing my home lab remotely, but also more generally for encrypting traffic when on WiFi networks I don't control - allowing me to replace the paid ProtonVPN subscription I had been using for that purpose.

[4] VyOS virtual router I use for my homelab stuff

It's a pretty slick setup, if I do say so myself. Anyway, this post will discuss how I implemented this, and what I learned along the way.

WireGuard Concepts, in Brief

WireGuard does things a bit differently from other VPN solutions I've used in the past. For starters, there aren't any user accounts to manage, and in fact users don't really come into the picture at all. WireGuard also doesn't really distinguish between _client_ and _server_; the devices on both ends of a tunnel connection are _peers_, and they use the same software package and very similar configurations. Each WireGuard peer is configured with a virtual network interface with a private IP address used for the tunnel network, and a configuration file tells it which tunnel IP(s) will be used by the other peer(s). Each peer has its own cryptographic _private_ key, and the other peers get a copy of the corresponding _public_ key added to their configuration so that all the peers can recognize each other and encrypt/decrypt traffic appropriately. This mapping of peer addresses to public keys facilitates what WireGuard calls Cryptokey Routing [5].

[5] Cryptokey Routing

Once the peers are configured, all it takes is bringing up the WireGuard virtual interface on each peer to establish the tunnel and start passing secure traffic.

You can read a lot more fascinating details about how this all works back on the WireGuard homepage [6] (and even more in this protocol description [7]) but this at least covers the key points I needed to grok prior to a successful initial deployment.

[6] WireGuard homepage

[7] protocol description

For my hybrid cloud solution, I also leaned heavily upon this write-up of a WireGuard Site-to-Site configuration [8] for how to get traffic flowing between my on-site environment, cloud-hosted WireGuard server, and "Road Warrior" client devices, and drew from this documentation on implementing WireGuard in GCP [9] as well. The VyOS documentation for configuring the built-in WireGuard interface [10] was also quite helpful to me.

[8] this write-up of a WireGuard Site-to-Site configuration

[9] this documentation on implementing WireGuard in GCP

[10] VyOS documentation for configuring the built-in WireGuard interface

Okay, enough background; let's get this thing going.

Google Cloud Setup

Instance Deployment

I started by logging into my Google Cloud account at https://console.cloud.google.com, and proceeded to create a new project (named `wireguard`) to keep my WireGuard-related resources together. I then navigated to **Compute Engine** and created a new instance [11] inside that project. The basic setup is:

[11] created a new instance

Image: Instance creation

The other defaults are fine, but I'll holding off on clicking the friendly blue "Create" button at the bottom and instead click to expand the **Networking, Disks, Security, Management, Sole-Tenancy** sections to tweak a few more things.

Image: Instance creation advanced settings

Network Configuration

Expanding the **Networking** section of the request form lets me add a new `wireguard` network tag, which will make it easier to target the instance with a firewall rule later. I also want to enable the _IP Forwarding_ option so that the instance will be able to do router-like things.

By default, the new instance will get assigned a public IP address that I can use to access it externally - but this address is _ephemeral_ so it will change periodically. Normally I'd overcome this by using ddclient to manage its dynamic DNS record [12], but (looking ahead) VyOS's WireGuard interface configuration [13] unfortunately only supports connecting to an IP rather than a hostname. That means I'll need to reserve a _static_ IP address for my instance.

[12] using ddclient to manage its dynamic DNS record

[13] VyOS's WireGuard interface configuration

I can do that by clicking on the _Default_ network interface to expand the configuration. While I'm here, I'll first change the **Network Service Tier** from _Premium_ to _Standard_ to save a bit of money on network egress fees. _(This might be a good time to mention that while the compute instance itself is free, I will have to spend about $3/mo for the public IP [14], as well as $0.085/GiB for internet egress via the Standard tier [15] (versus $0.12/GiB on the Premium tier [16]). So not entirely free, but still pretty damn cheap for a cloud-hosted VPN that I control completely.)_

[14] about $3/mo for the public IP

[15] $0.085/GiB for internet egress via the Standard tier

[16] $0.12/GiB on the Premium tier

Anyway, after switching to the cheaper Standard tier I can click on the **External IP** dropdown and select the option to _Create IP Address_. I give it the same name as my instance to make it easy to keep up with.

Image: Network configuration

Security Configuration

The **Security** section lets me go ahead and upload an SSH public key that I can then use for logging into the instance once it's running. Of course, that means I'll first need to generate a key pair for this purpose:

Okay, now that I've got my keys, I can click the **Add Item** button and paste in the contents of `~/.ssh/id_ed25519_wireguard.pub`.

Image: Security configuration

And that's it for the pre-deploy configuration! Time to hit **Create** to kick it off.

Image: Do it!

The instance creation will take a couple of minutes but I can go ahead and get the firewall sorted while I wait.

Firewall

Google Cloud's default firewall configuration will let me reach my new server via SSH without needing to configure anything, but I'll need to add a new rule to allow the WireGuard traffic. I do this by going to **VPC > Firewall** and clicking the button at the top to **Create Firewall Rule [17]**. I give it a name (`allow-wireguard-ingress`), select the rule target by specifying the `wireguard` network tag I had added to the instance, and set the source range to `0.0.0.0/0`. I'm going to use the default WireGuard port so select the _udp:_ checkbox and enter `51820`.

[17] Create Firewall Rule

Image: Firewall rule creation

I'll click **Create** and move on.

WireGuard Server Setup

Once the **Compute Engine > Instances** page [18] indicates that the instance is ready, I can make a note of the listed public IP and then log in via SSH:

[18] page

Preparation

And, as always, I'll first make sure the OS is fully updated before doing anything else:

Then I'll install `ufw` to easily manage the host firewall, `qrencode` to make it easier to generate configs for mobile clients, `openresolv` to avoid this issue [19], and `wireguard` to, um, guard the wires:

[19] this issue

Configuring the host firewall with `ufw` is very straight forward:

The last preparatory step is to enable packet forwarding in the kernel so that the instance will be able to route traffic between the remote clients and my home network (once I get to that point). I can configure that on-the-fly with:

To make it permanent, I'll edit `/etc/sysctl.conf` and uncomment the same line:

WireGuard Interface Config

I'll switch to the root user, move into the `/etc/wireguard` directory, and issue `umask 077` so that the files I'm about to create will have a very limited permission set (to be accessible by root, and _only_ root):

Then I can use the `wg genkey` command to generate the server's private key, save it to a file called `server.key`, pass it through `wg pubkey` to generate the corresponding public key, and save that to `server.pub`:

As I mentioned earlier, WireGuard will create a virtual network interface using an internal network to pass traffic between the WireGuard peers. By convention, that interface is `wg0` and it draws its configuration from a file in `/etc/wireguard` named `wg0.conf`. I could create a configuration file with a different name and thus wind up with a different interface name as well, but I'll stick with tradition to keep things easy to follow.

The format of the interface configuration file will need to look something like this:

There will be a single `[Interface]` section in each peer's configuration file, but they may include multiple `[Peer]` sections. For my config, I'll use the `10.200.200.0/24` network for WireGuard, and let this server be `10.200.200.1`, the VyOS router in my home lab `10.200.200.2`, and I'll assign IPs to the other peers from there. I found a note that Google Cloud uses an MTU size of `1460` bytes so that's what I'll set on this end. I'm going to configure WireGuard to use the VyOS router as the DNS server, and I'll specify my internal `lab.bowdre.net` search domain. Finally, I'll leverage the `PostUp` and `PostDown` directives to enable and disable NAT so that the server will be able to forward traffic between networks for me.

So here's the start of my GCP WireGuard server's `/etc/wireguard/wg0.conf`:

I don't have any other peers ready to add to this config yet, but I can go ahead and bring up the interface all the same. I'm going to use the `wg-quick` wrapper instead of calling `wg` directly since it simplifies a bit of the configuration, but first I'll need to enable the `wg-quick@{INTERFACE}` service so that it will run automatically at startup:

I can now bring up the interface with `wg-quick up wg0` and check the status with `wg show`:

I'll come back here once I've got a peer config to add.

Configure VyoS Router as WireGuard Peer

Comparatively, configuring WireGuard on VyOS is a bit more direct. I'll start by entering configuration mode and generating and binding a key pair for this interface:

And then I'll configure the rest of the options needed for the interface:

Note that this time I'm allowing all IPs (`0.0.0.0/0`) so that this WireGuard interface will pass traffic intended for any destination (whether it's local, remote, or on the Internet). And I'm specifying a 25-second `persistent-keepalive` interval [20] to help ensure that this NAT-ed tunnel stays up even when it's not actively passing traffic - after all, I'll need the GCP-hosted peer to be able to initiate the connection so I can access the home network remotely.

[20] 25-second `persistent-keepalive` interval

While I'm at it, I'll also add a static route to ensure traffic for the WireGuard tunnel finds the right interface:

And I'll add the new `wg0` interface as a listening address for the VyOS DNS forwarder:

I can use the `compare` command to verify the changes I've made, and then apply and save the updated config:

I can check the status of WireGuard on VyOS (and view the public key!) like so:

See? That part was much easier to set up! But it doesn't look like it's actually passing traffic yet... because while the VyOS peer has been configured with the GCP peer's public key, the GCP peer doesn't know anything about the VyOS peer yet.

So I'll copy `{VYOS_PUBLIC_KEY}` and SSH back to the GCP instance to finish that configuration. Once I'm there, I can edit `/etc/wireguard/wg0.conf` as root and add in a new `[Peer]` section at the bottom, like this:

This time, I'm telling WireGuard that the new peer has IP `10.200.200.2` but that it should also get traffic destined for the `192.168.1.0/24` and `172.16.0.0/16` networks, my home and lab networks. Again, the `AllowedIPs` parameter is used for WireGuard's Cryptokey Routing so that it can keep track of which traffic goes to which peers (and which key to use for encryption).

After saving the file, I can either restart WireGuard by bringing the interface down and back up (`wg-quick down wg0 && wg-quick up wg0`), or I can reload it on the fly with:

(I can't just use `wg syncconf wg0` directly since `/etc/wireguard/wg0.conf` includes the `PostUp`/`PostDown` commands which can only be parsed by the `wg-quick` wrapper, so I'm using `wg-quick strip {INTERFACE}` to grab the contents of the config file, remove the problematic bits, and then pass what's left to the `wg syncconf {INTERFACE}` command to update the current running config.)

Now I can check the status of WireGuard on the GCP end:

Hey, we're passing traffic now! And I can verify that I can ping stuff on my home and lab networks from the GCP instance:

Cool!

Adding Additional Peers

So my GCP and VyOS peers are talking, but the ultimate goals here are for my Chromebook to have access to my homelab resources while away from home, and for my phones to have secure internet access when connected to WiFi networks I don't control. That means adding at least two more peers to the GCP server. WireGuard offers downloads [21] for just about every operating system you can imagine, but I'll be using the Android app [22] for both the Chromebook and phones.

[21] offers downloads

[22] Android app

Chromebook

The first step is to install the WireGuard Android app.

_Note: the version of the WireGuard app currently available on the Play Store (v1.0.20210926) has an issue [23] on Chrome OS that causes it to not pass traffic after the Chromebook has resumed from sleep. The workaround for this is to install an older version of the app (1.0.20210506) which can be obtained from F-Droid [24]. Doing so requires having the Linux environment enabled on Chrome OS and the **Develop Android Apps > Enable ADB Debugging** option enabled in the Chrome OS settings. The process for sideloading apps is detailed here [25]._

[23] has an issue

[24] F-Droid

[25] detailed here

Once it's installed, I open the app and click the "Plus" button to create a new tunnel, and select the _Create from scratch_ option. I click the circle-arrows icon at the right edge of the _Private key_ field, and that automatically generates this peer's private and public key pair. Simply clicking on the _Public key_ field will automatically copy the generated key to my clipboard, which will be useful for sharing it with the server. Otherwise I fill out the **Interface** section similarly to what I've done already:

I then click the **Add Peer** button to tell this client about the peer it will be connecting to - the GCP-hosted instance:

I _shouldn't_ need the keepalive for the "Road Warrior" peers connecting to the GCP peer, but I can always set that later if I run into stability issues.

Now I can go ahead and save this configuration, but before I try (and fail) to connect I first need to tell the cloud-hosted peer about the Chromebook. So I fire up an SSH session to my GCP instance, become root, and edit the WireGuard configuration to add a new `[Peer]` section.

Here's the new section that I'll add to the bottom of the config:

This one is acting as a single-node endpoint (rather than an entryway into other networks like the VyOS peer) so setting `AllowedIPs` to only the peer's IP makes sure that WireGuard will only send it traffic specifically intended for this peer.

So my complete `/etc/wireguard/wg0.conf` looks like this so far:

Now to save the file and reload the WireGuard configuration again:

At this point I can activate the connection in the WireGuard Android app, wait a few seconds, and check with `wg show` to confirm that the tunnel has been established successfully:

And I can even access my homelab when not at home!

Image: Remote access to my homelab!

Android Phone

Being able to copy-and-paste the required public keys between the WireGuard app and the SSH session to the GCP instance made it relatively easy to set up the Chromebook, but things could be a bit trickier on a phone without that kind of access. So instead I will create the phone's configuration on the WireGuard server in the cloud, render that config file as a QR code, and simply scan that through the phone's WireGuard app to import the settings.

I'll start by SSHing to the GCP instance, elevating to root, setting the restrictive `umask` again, and creating a new folder to store client configurations.

As before, I'll use the built-in `wg` commands to generate the private and public key pair:

I can then use those keys to assemble the config for the phone:

I'll also add the interface address and corresponding public key to a new `[Peer]` section of `/etc/wireguard/wg0.conf`:

And reload the WireGuard config:

Back in the `clients/` directory, I can use `qrencode` to render the phone configuration file (keys and all!) as a QR code:

Image: QR code config

And then I just open the WireGuard app on my phone and use the **Scan from QR Code** option. After a successful scan, it'll prompt me to name the new tunnel, and then I should be able to connect right away.

Image: Successful mobile connection

I can even access my vSphere lab environment - not that it offers a great mobile experience...

Image: vSphere mobile sucks

Before moving on too much further, though, I'm going to clean up the keys and client config file that I generated on the GCP instance. It's not great hygiene to keep a private key stored on the same system it's used to access.

Bonus: Automation!

I've written before [26] about a set of Tasker [27] profiles I put together so that my phone would automatically connect to a VPN whenever it connects to a WiFi network I don't control. It didn't take much effort at all to adapt the profile to work with my new WireGuard setup.

[26] written before

[27] Tasker

Two quick pre-requisites first:

Open the WireGuard Android app, tap the three-dot menu button at the top right, expand the Advanced section, and enable the _Allow remote control apps_ so that Tasker will be permitted to control WireGuard.

Exclude the WireGuard app from Android's battery optimization so that it doesn't have any problems running in the background. On (Pixel-flavored) Android 12, this can be done by going to **Settings > Apps > See all apps > WireGuard > Battery** and selecting the _Unrestricted_ option.

On to the Tasker config. The only changes will be in the VPN on Strange Wifi [28] profile. I'll remove the OpenVPN-related actions from the Enter and Exit tasks and replace them with the built-in **Tasker > Tasker Function WireGuard Set Tunnel** action.

[28] VPN on Strange Wifi

For the Enter task, I'll set the tunnel status to `true` and specify the name of the tunnel as configured in the WireGuard app; the Exit task gets the status set to `false` to disable the tunnel. Both actions will be conditional upon the `%TRUSTED_WIFI` variable being unset.

Image: Tasker setup

_Automagic!_

Other Peers

Any additional peers that need to be added in the future will likely follow one of the above processes. The steps are always to generate the peer's key pair, use the private key to populate the `[Interface]` portion of the peer's config, configure the `[Peer]` section with the _public_ key, allowed IPs, and endpoint address of the peer it will be connecting to, and then to add the new peer's _public_ key and internal WireGuard IP to a new `[Peer]` section of the existing peer's config.

---

📧 Reply by email

Related articles

Blocking AI Crawlers

Self-Hosted Gemini Capsule with gempost and GitHub Actions

Dynamically Generating OpenGraph Images With Hugo

---

Home

This page on the big web