Setting up a VPN for Home/Intranet Access with WireGuard

If you’d like to securely make services in your home network available for yourself — and only yourself (and others you trust) — from outside, using WireGuard, this is the post for you! We’ll be setting up VPN Server on Linux for point-to-site access.

Prerequisites

• You’re vaguely familiar with WireGuard (“WG”); enough to know that it secures communication between two nodes and that you want to use it, but not how it works nor how to set it up.
• You have some networking knowledge and know-how, such as what NAT is, what a subnet is, and how to set up port forwarding in your router. It’s also helpful to know about virtual network interfaces (“VNI”) and a bit about how IP routing works (for example, that you can configure “traffic for 10.0.0.0/24 should go through the (virtual) interface ‘wg0′”).
• You understand basic usage of public/private key pairs (like using key-based authentication with SSH); you don’t need to know how they work.
• You’re fairly comfortable with Linux; e.g., how to install packages, how to run privileged commands and edit restricted files (e.g., `sudo vi /etc/wireguard/wg0.conf`).
  • You’re also comfortable with using iptables (including installing, if necessary), which has the risk of preventing you from being able remotely access your server even from your LAN!

Also, just to be sure it’s clear:

• Authentication/Authorization: Authentication (“AuthN”) is knowing/validating who is trying to connect/access, and authorization (“AuthO”) is deciding whether to allow connecting/access. For some services, non-authenticated (“anonymous”) clients may be allowed/authorized to connect and access, but in others, such as SSH, authentication implies authorization (at least at the connection-level; i.e., if you’re on the list, we know who you are and you’re allowed to log in; there may be finer-grained authorization at a higher level).
  • “Auth” = AuthN + AuthO: “Auth” may be used when both happen together (or when it’s not important which we’re talking about).

What you should know about WireGuard

WireGuard is a relatively basic tool, focused on just being a low-level secure communication mechanism, and lending itself to be configured for many different types of usages and topologies, whether point-to-point, mesh, point-to-site, site-to-site, etc. Likewise, configuration is also pretty basic and documentation on the official website is minimal, which means leaving it to us to set it up depending on how we want to use it (or leaving it to 3rd-party software and services to build more sophisticated use-cases and friendly UI around it). Since WireGuard is agnostic to topology and use…

WireGuard simply refers to each node on the network as a ‘peer’. “Node” and “peer” are mostly synonymous in this context. Also in this context, “VPN server” or “server” will refer to the peer that is the gateway into the intranet (while “internal service” will be used for servers/services that a client wants to connect to within the intranet), and “clients” are just the peers that access the internal services (through the “server”).

WireGuard Auth: With WireGuard, each peer is configured with a list of peers — the public keys of those peers — that are allowed to communicate with it using a WireGuard tunnel. Such a peer is both authenticated and authorized (and not just one or the other).

WireGuard’s tunnels are encrypted: The tunnel that WireGuard creates between two peers is encrypted. While this may be obvious, it’s important to point out that this benefit is distinct from the others (auth) because some topologies may use WireGuard only to protect access to the intranet, not through the intranet all the way to the internal service (end-to-end)…

WireGuard’s auth and encryption are likely to be — should be, even — at least somewhat redundant with the traffic going through it. The communication between a client and the internal service may be using an end-to-end encrypted protocol (such as SSH or HTTPS) and doing their own auth of the client (e.g., SSH keys, web-based login). Such communication through WG would first be auth’d and encrypted by WG, and then auth’d and encrypted with the internal service.

WireGuard as a first line of defense

We could just poke a bunch of holes — set up a bunch of port forwarding rules — in the router, forwarding all connections to various internal services, and rely on the internal services doing their own auth and encryption. However:

• Their auth and/or encryption might not be strong. More exposed services means more opportunities for weak links (for example, a web-based service using an older HTTP engine with vulnerabilities), and an attacker may only need to compromise one service in order to gain access to other services on your network.
• They might not be great at protecting themselves from other attacks. For example, many aren’t great at protecting themselves from brute-force authentication or denial-of-service attacks.

So, even if all of your internal services do auth and use encryption, WireGuard is still a good option as the first line of defense to mitigate other potential vulnerabilities by limiting access before reaching those services.

Site access VPN with WireGuard

Again, WG can be utilized in many different types of topologies, and even if we focus on just the scenario of allowing secure access to services in your home network (“intranet”) there are still several options. Here are just two of the main ones:

End-to-End (peer-to-peer) vs Point-to-Site

End-to-end: Clients and all internal services use WireGuard to create end-to-end tunnels directly between each client-service pair. The router has multiple port-forwarding rules, one for each internal service, which is what allows clients to reach services.

Point-to-site: There is one WireGuard “VPN Server” in the intranet that all clients tunnel to, so there’s also just one port forwarded from the router. From the VPN server, the packets leave the WG tunnel and traverse the intranet to the internal service “normally”; i.e., the same as if the client were in the intranet.

Auth and Encryption ≠ Access

So, one of the most significant differences between these two topologies is how and where they provide encryption, and how/where they limit access.

Point-to-site: Access to the intranet is controlled in a single place, the VPN server’s WireGuard. While the communication between the VPN server and the internal services are not protected by WireGuard, they may be protected by the services themselves (as well as by being in an intranet). It’s not any worse than a client within the intranet accessing the service, for whatever that’s worth.

End-to-end: Access into the intranet is via more holes (forwarded ports) and endpoints, and access to each internal service is controlled by that service’s WireGuard.

	End-to-End	Point-to-Site
Access to enter the home intranet	By the Router. Access into the network is via port-forwarding on the router directly to each internal service. All access attempts will reach those internal services’ WireGuard.	Mostly by the VPN Server’s WireGuard. Access into the network is via a single port-forward to the VPN Server, which uses WireGuard’s auth to determine whether to accept the connection and forward it on to the internal service.
Access to the hosts in the intranet (which hosts within the intranet can be accessed)	The router’s port-forwarding configuration limits which hosts and ports the clients can reach. Each host that you want to be able to access must have a port-forwarding rule (excluding creating another tunnel, such as an SSH tunnel, from one of the hosts that you can reach).	WireGuard’s `AllowedIPs` configuration is flexible; easy to allow clients to access any host on the intranet (as though it’s on the intranet itself), or to just specific hosts.
Encryption	WireGuard ensures encryption end-to-end (which could mean double encryption end-to-end).	WireGuard only ensures encryption from the client to the VPN server. Traffic from the VPN server to the internal service might not be encrypted (the same as when the client in the intranet).
Amount of Configuration to setup and maintain	🟨 Router: One port-forwarding rule for each internal service. 🟢 VPN Server: None. 🔻 Clients: Every client needs public keys and WG IPs of every internal service. 🔻 Internal Services: Every internal service needs public keys of every client. With n clients and m services, there need to be 2 × n × m configuration entries. Adding a client entails updating all internal services, and adding an internal service entails updating all clients.	🟢 Router: One port-forwarding rule (to the VPN Server). 🔶 VPN Server: Public keys of all clients. One-time iptables configuration for NAT, and a server to maintain. 🟢 Clients: Just the public key of the WG VPN server. 🟢 Internal Services: None. Adding a client only entails updating the VPN server (no updates needed to add access to additional internal services).
Other considerations		🔻 The VPN Server is an additional single point of failure. 🟢 This setup also easily allows clients to communicate with each other.

I have chosen to use the point-to-site topology because:

• It’s less configuration to add clients or services, and
• It allows more open access to the intranet (any service on any host rather than just specifically configured services) easily.

If you also want to set up point-to-site access, let’s continue!

Setting up a WireGuard VPN server for point-to-site access

A few details and assumptions about the setup

• The Linux WireGuard VPN server (“server” hereafter) is in the internal network; it is behind a router with NAT, has an internal IP, and is in a position to communicate with and forward traffic to internal services. If your server has an external IP or is your router, you can still mostly follow this guide, but there may be extra steps or tweaks that won’t be covered here (but you should be able to handle since you’ve set things up that way).
• All WG nodes (server and clients) will get a new WireGuard virtual network interface (“WG-VNI”) which will be part of a new, dedicated subnet. For example, let’s say your physical intranet is 192.168.0.0/24. We’ll create a 10.0.0.0/24 subnet for the WireGuard server and clients.
  • You’re responsible for manually assigning unique IPs to each client. While you’re likely using DHCP to assign IPs to nodes in your intranet, each node in the WireGuard network will have its IP defined manually in WG configuration files (WireGuard doesn’t have dynamic IP support built in). Each client’s IP will appear in at least two places: the server’s configuration file (which will have all clients’ IPs), and the client’s own configuration.
• We’ll need to use Network Address Translation (“NAT”) (using iptables) so that VPN clients (on 10.0.0.10/24) can communicate with services (on 192.168.0.0/24).

Here’s a summary of the values that we’ll be using in this guide (and depicted in Figure 3):

• The physical intranet of the home is 192.168.0.0/24.
• The network interface of your VPN server connected to your intranet is enp0s20 (eth0 or eno1 are other common names).
• The virtual WireGuard network will be 10.0.0.0/24.
  • We’ll assign 10.0.0.1/24 to the VPN server
  • The first client will get 10.0.0.10/24.
• The public IP of your home’s internet: 88.88.88.88.
• We’ll use port 51820 (UDP), the default port for WireGuard, both internally (on the WireGuard server) and externally (on the router). You may choose a different external port for a smidge of security-through-obscurity. Using a different port internally only adds confusion (since this is internal to your network and only affects the port-forwarding rule of your router).

Adjust as necessary for your existing network’s configuration and/or your preference.

1. Install WireGuard on the server and client(s)

1a. Install WireGuard on the server

`sudo apt install wireguard`

1b. Install WireGuard on a client

The client in this guide will use the official WireGuard Android client. Whatever client you end up using, the configuration parameters should be the same (just the way you enter them will vary).

2. Create key pairs for the server and the first client

2a. Create key pairs for the server

It doesn’t particularly matter where you run this command and where the files that it outputs goes (except that it’s a secure location; e.g., where only root can read it) because configuration won’t read these files (unlike certificate files for web or key files for ssh servers); you’ll be pasting the values into WG’s configuration file. After you paste the values into configuration files (a few steps from now) you could delete the key files (or just store them in the same location that the WG configuration files go, /etc/wireguard).

# * `wg genkey` creates a private key
# * `| tee privatekey` writes that private key to the file 'privatekey' and
#   also writes it to stdout for the next pipe...
# * `wg pubkey > publickey` take the private key in (via the pipe / stdin) and
#   writes the public key to the file 'publickey'
wg genkey | tee privatekey | wg pubkey > publickey

2b. Create key pairs for the client

My first client was an Android device using the official WireGuard Android app, and I’ll share how I set it up with its UX. Other types of clients (of which there are many) will each have its own way of setting it up, so you’ll just have to follow that app’s instruction with this as a bit of guidance.

Android

Because of how the UX of the WireGuard Android app is designed, you’ll need to do a bit of a dance to get the server’s public key in and this clients’s public key out.

1. First, make sure you have access to the server’s public key (generated above) on this device so you can paste it in (or fill it in with 1Password, or manually type it in!).
2. Click on the ‘+’ floating action button at the bottom right and choose ‘Create from scratch’ to start the ‘Create WireGuard Tunnel’ flow.
   • Interface: This is the virtual network interface that selected traffic will go through when the tunnel is active.
     • Name: “Home VPN” or whatever you want.
     • Private key: Click the two arrows in a circle icon (looks kind of like ‘↺’) which will generate a new key pair.
     • Public key: This will be generated along with the private key, and you’ll need to paste this into the server’s configuration later. You can copy it out now (dance out of the app, paste it somewhere, dance back into the app), or you can return later to access the public key.
     • Addresses: This is the address that you want this client to have on the VPN subnet, along with the subnet prefix length (in CIDR notation). As stated above, we’ll give this first client “10.0.0.10/24“.
     • ‘All Applications‘: Click this to choose which applications’ traffic — if they are destined to the Addresses above —should go through the tunnel.
       • You could just choose apps that are for the services running in your home, such Home Assistant.
       • If you leave it as ‘All Applications’ and Addresses blank, then all internet traffic will go through your home’s internet.
   • Peer: These are the details for the VPN server (for our topology).
     • Public Key: Enter the server’s public key (from 2a, above).
     • Endpoint: The external IP address or DNS name, with port, of the server. For example, “home.mydomain.net:51820” or “88.88.88.88:51820“.
       • This is actually the IP address of your modem/router. We’ll configure port-forwarding later to get the traffic from the router to the actual server.
     • Allowed IPs: These are the destination addresses that will be forwarded by the tunnel (i.e., these will be routes that are added with the Endpoint as the gateway).
       • Enter the subnet of your intranet, “196.168.0.0/24“, so that any attempts to access your intranet will go through your WG tunnel
         -or-
       • Enter the subnet of your VPN as well as intranet (“10.0.0.0/24, 192.168.0.0/24“) if you’d also like to be able to communicate with other VPN clients
         -or-
       • Enter “0.0.0.0/0” so all traffic will be forwarded to your VPN (and access to the internet will go through your home internet; but you’ll need extra configuration on the VPN server, too).
3. Click the floppy disk icon (‘💾’) at the top-right to save the configuration.

3. Configure the server

Now we’ll configure the new WG-VNI on the server and routing/NAT so that traffic can go back and forth between the WireGuard subnet and your intranet.

We’ll name the WG-VNI “wg0” (you can give it another name if you’d like; just replace all occurrences of “wg0“).

3a. Enable routing/NAT

We will need to use NAT so that the server can get packets from the VPN subnet (10.0.0.0/24) to the intranet subnet (192.168.0.0/24) and back. If you’d like to better understand how and why, see Why not use the intranet’s subnet? Why do we need NAT / iptables? in the appendix.

First, here, we just need to enable using NAT, and following steps will actually configure it.

IP forwarding

First enable IP forwarding by adding (or uncommenting; it’s likely the line in already there, but commented out) the following line in /etc/sysctl.conf:

# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

iptables

Install iptables (if it isn’t already):

sudo apt install iptables

Intranet network interface name

In order to configure NAT (in the following step), we’ll need to know the name of the adapter connected to your intranet. Run ifconfig and look for the one with an ‘inet’ address on your intranet, which will look something like this:

$ /usr/sbin/ifconfig
enp0s20: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.2  netmask 255.255.255.0  broadcast 192.168.0.255
<...>

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
<...>

In this example, “enp0s20” is the adapter on the “192.168.0.0/24” intranet.

3b. Create the WireGuard configuration file

Create ‘/etc/wireguard/wg0.conf‘ with the following contents:

[Interface]
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = <the server's private key from step 2a>

# When the WireGuard interface (wg0) is brought up, add iptables
# rules that allow it to forward and NAT packets to the intranet
# (which enp0s20 is connected to).
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o enp0s20 -j MASQUERADE

# When the WireGuard interface is brought down, remove the
# above PostUp rules.
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o enp0s20 -j MASQUERADE

#== Robert's devices ==========================================
#-- Robert's phone
[Peer]
PublicKey = <the client's public key from step 1b>

• Interface
  • Address: : The address that you want the server to have on the VPN subnet, along with the subnet prefix length (in CIDR notation).
  • ListenPort: 51820
  • PrivateKey: Enter the server’s private key that you generated in step 1A.
  • PostUp and PostDown: Enables peers (clients) to communicate with devices on your intranet. Replace “enp0s20” with the name of the network adapter on the intranet (from step 3a)
    • If you have existing iptables rules, you may need additional configuration to allow WireGuard traffic through your filters. See Additional iptables hints.
• Peer: You’ll create one ‘[Peer]‘ entry for each client that you want to allow into your network. For now we’ll create just one for the client we set up in the previous step.
  • PublicKey: Enter the client’s public key from step 2b.

3c. Start up the WireGuard virtual network interface

`sudo wg-quick up /etc/wireguard/wg0.conf`

If all goes well the output is pretty much just the list of commands it ran (which you could have run yourself), which should look like this:

[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.0.0.3/24 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] iptables -A FORWARD -i wg0 -j ACCEPT
[#] iptables -t nat -A POSTROUTING -o enp0s20 -j MASQUERADE

At this point, clients within the LAN can use the VPN server. To be able to connect from it outside we just need to set up port-forwarding on the router.

4. Set up port-forwarding on the router

Forward UDP on port 51820 on your router to your VPN server’s port 51820. There are so many different routers and UI, so I leave this to you to figure out!

Done!

Now you should be able to access your intranet from outside!

If your client is a phone, try turning off WiFi and enabling the WireGuard tunnel.

If things aren’t working and you have existing iptables rules, you may need additional configuration to allow WireGuard traffic through your filters. See Additional iptables hints.

Appendix

Why not use the intranet’s subnet? Why do we need NAT / iptables?

IP Fundamentals

When a node wants to communicate with — send an IP packet to — another node, it has two ways to get it there:

1. Send the packet directly there if it’s on the same subnet. When two nodes are on the same subnet, they can send packets directly to each other.
2. Through a route. A route basically consists of an address range, the IP of the node (the “gateway”) that is responsible for packets in that range, and the network interface that that gateway can be reached though. Most of the time, there’s just one consequential route: the default route (where to send packets to if not directly (#1 above), and if no other routes match). The gateway for the default route is usually your internet router. That is, if you have a packet destined for anywhere other than other devices on your LAN, give it to the router (which will send it over to your ISP’s router, which will send it on its way, magically finding its way through the internet to the destination).

Regardless, packets aren’t sent using IPs directly, but by MAC address (with the help of ARP). We’ll see why this is significant later.

In a typical network, each node gets their routes configured by the router using DHCP (the same mechanism used to assign IP addresses to each node).

WireGuard needs its own subnet

Let’s actually explore what would happen if we were to configure the WireGuard virtual network interfaces to be on the same subnet. We’ll use figure 3 as a basis, but where the VPN server’s WireGuard virtual network interface (WG-VNI) has an IP of 192.168.0.3, and the client’s WG-VNI has an IP of 192.168.0.10.

Given that, let’s try to get a packet from Internal Service B back to the client — so the packet is addressed to 192.168.0.10. Remember, the usual behavior (based on usual routing, covered above) is for packets with a destination on the same subnet to go directly to the destination, via MAC address:

1. Based on the routing table, the packet destined for an address in the same subnet should be sent directly to the destination via MAC address.
2. In order to get the MAC address, an ARP request is broadcast to the network, which sounds like “Hey, whoever has IP 192.168.0.10, what is your MAC address?” That broadcast is propagated by the LAN (switches, mainly) to all clients on the network.
3. Normally, the destination node — the one with IP 192.168.0.10 — will respond “The MAC address for 192.168.0.10 (my IP) is 11:22:33:44:55:66 (my MAC).”
4. However, such broadcasts are not propagated to the client because its not on the LAN.
   • For this ARP dance to work, the WireGuard interface would have to propagate the ARP request through the tunnel to the client and the ARP response back. Not only is this Bad™, there are still more problems downstream. But let’s say we did this and let’s continue…
5. So, Internal Service B now knows the MAC address to send the packet to (11:22:33:44:55:66) and sends the packet…
6. None of the switches in the LAN actually know where 11:22:33:44:55:66 is; none of them have 11:22:33:44:55:66 connected to them.
   • In order to make this work, the VPN server would have to claim that it is the owner of 192.168.0.10 (i.e., respond to ARP requests with its own MAC address), or by claiming that it has MAC address 11:22:33:44:55:66 (so that switches will route the packet to it, after which it can send the packet through the tunnel to the client). Both of these are also bad.
     • Note that it would have to do this with all WG clients; it could be claiming ownership of dozens or hundreds of IPs or MAC addresses.

Here’s another idea: We set up routes so that the VPN server is the gateway for such packets (e.g., 192.168.0.10/32 ⇒ 192.168.0.2). For this to work, we have to configure all nodes on the LAN (that might communicate with WG clients) with such a route. We could do it manually (go to each node and edit routes), or get our DHCP server to send these route configurations. However, many consumer routers don’t support this. It’s also a bit cumbersome (update DHCP settings for each new client) and bad (this one isn’t so bad, but it’s more bad than NAT).

Additional iptables hints

If you have existing iptables rules, some of them may interfere with your WireGuard setup. Here are a couple things you can try (for all of these, you could add them to your iptables rules file so they always apply, or you could add them to your ‘wg0.conf‘ file under the ‘[Interface]‘ section so they only apply while the WG-VNI is up (in which case you’ll want ‘PostDown’ rules to undo them):

• If your rules have a default policy of DROP for the INPUT chain, you may need to add a rule to accept UDP on WireGuard’s port. For example, by adding the following to your iptables rules file:

-A INPUT -p udp --dport 51820 -j ACCEPT -m comment --comment "ACCEPT WireGuard"

• If your rules only allow connections from listed networks, you may need to add a rule to accept connections from your WireGuard network. For example, by adding the following to your iptables rules file:

-A INPUT --source 192.168.87.0/24 -j ACCEPT -m comment --comment "WireGuard"

• If your rules set up a default policy of DROP for the FORWARD chain, you may need to update the chain to ACCEPT by default. For example, add the following to your ‘wg0.conf‘ file under the ‘[Interface]‘ section:

PostUp = iptables -P FORWARD ACCEPT
PostDown = iptables -P FORWARD DROP

Why not end-to-end / peer-to-peer?

The main reason is simplicity. I don’t need peer-to-peer, so it’s not worth the substantial extra work for me.

• Every internal service that you want to access will need to have WireGuard installed on it (whereas with the VPN setup, only the VPN server needs WireGuard).
• Every internal service will need to be configured with all of the clients that can access it (whereas with the VPN setup, only the VPN server needs such configuration).
• Every client will need to be configured with all of the internal services that it wants to be able to access.
• You’ll need a port-forwarding rule on your router for each internal service.

This is even more complex in a true peer-to-peer setup where “client” and “server” are blurred — they’re all “nodes” — and where clients/server/nodes (some of which could be mobile and behind different NATs) might need to be able to connect with each other.

What about other topologies, such as a cloud-based VPN server?

As mentioned before, WireGuard is a relatively basic tool which can be configured for many different types of topologies. For example, you could use it to tunnel all of your traffic while you’re on untrusted networks, set up an end-to-end topology with the VPN server in the cloud (useful if you can’t port-forward), or set up a site-to-site tunnel. There are too many possibilities too to cover here. I’ll give you a couple hints here, and hopefully what you’ve learned here can help you set up whatever other topology you’d like!

Hub-and-spoke end-to-end VPN (optionally with the server in the cloud)

Somewhat of a hybrid of the two options presented above, you could have all peers connect to a VPN server.

• This gives you end-to-end-ish WireGuard encryption. Communication from the peer to the VPN server is encrypted, then encrypted again from the VPN server to the other peer (“internal service”), but the VPN server has access to the traffic (which is likely encrypted at a higher level).
• It’s less configuration than the true end-to-end setup; each peer only needs to be configured with the VPN server’s public key.

How

1. Install WireGuard on each internal service, configuring it mostly the same as you would a client. You probably need to add PersistentKeepalive configuration so the internal service maintains a connection with the server while it lays dormant waiting for incoming traffic.
2. You don’t need to set up NAT as long as you’re only accessing WireGuarded services (peers).
3. Now each client accesses the internal service using their WireGuard IP.

Private privacy tunnel

There are many VPN services that offer to help protect your privacy by routing your traffic securely through their servers, which helps protect your communication when using untrusted providers such as cafe WiFi…

You could set up all of your traffic to go through your WireGuard server. Not that your internet-bound traffic leaving your VPN server still goes through some ISP (your home’s ISP or the cloud service provider if your VPN server is on the cloud) who can see your traffic (most of which will be encrypted).

How

1. Set ‘Allowed IPs’ on the client to “0.0.0.0/0” so that it’ll send all traffic to your VPN server.
2. Probably some update to the WG configuration on the VPN server to forward internet-bound traffic.