The Ultimate Guide to Setting Up WireGuard on Ubuntu 22.04

Protect your traffic and speed up your connections with the world's leanest, most powerful VPN protocol. Here is your step-by-step guide.

Install WireGuard on Ubuntu 22.04

WireGuard and Ubuntu

What is WireGuard?

Have you ever worried about your privacy while using the free Wi-Fi at a coffee shop or hotel? A Virtual Private Network (VPN) solves this by creating a secure, secret tunnel for your internet traffic, keeping your data safe from prying eyes no matter where you are. WireGuard is a modern, incredibly fast, and lightweight VPN designed to give you this peace of mind without slowing down your connection.

Unlike older VPN options that are bulky and complicated to set up, WireGuard is built for speed and simplicity. Traditional VPNs rely on hundreds of confusing security formulas and certificates, which can make them sluggish and prone to configuration errors. In contrast, WireGuard uses a streamlined "lock and key" system with public and private keys to connect devices securely, making it faster, less demanding on your battery, and far easier to get right.

In this tutorial, you will learn exactly how to build your own secure VPN step-by-step. We will guide you through setting up a WireGuard server on Ubuntu 22.04 and connecting another device to it using modern IPv4 and IPv6 internet connections. By the end, you will know how to route all of your device's web traffic through your new secure gateway, giving you a completely private internet experience wherever you go.

Prerequisites

A WireGuard Server: An Ubuntu 22.04 server set up with a basic firewall and a non-root user (a regular user account with admin privileges).
A WireGuard Peer: The device you want to connect to your new VPN, such as your personal computer or smartphone. (Note: If you use a remote server as your peer instead of your local device, be sure to follow the steps carefully so you don't accidentally lock yourself out!)
IPv6 Capability (Optional): If you want to use modern IPv6 connections, make sure your server is configured to support it.

Step 1 — Installing WireGuard and Generating a Key Pair

Let's get right into it! Your first task is to install the WireGuard software on your Ubuntu server.

To do this, you will need to update your server's system list and then install the program using a few simple commands. Keep in mind that you might be asked to type in your admin sudo password to give the server permission to make these changes.

BASH

sudo apt update
sudo apt install wireguard

Now that WireGuard is ready, your server needs a secure digital identity. You will do this by creating a private and public keypair:

Create the Keys: Use the built-in wg genkey command to generate your secret private key, and the wg pubkey command to create your matching public key.
Lock it Down: After adding the private key to your configuration file, you must use the chmod command to restrict the file's permissions. This is a crucial security step because it prevents anyone else on the server from reading your secret key.

BASH

wg genkey | sudo tee /etc/wireguard/private.key
sudo chmod go= /etc/wireguard/private.key

The sudo chmod go=... command removes all permissions for group and other users so only root can access the private key file. The command outputs a single line of base64-encoded text representing the private key, while tee also saves a copy to /etc/wireguard/private.key for later use. You should record this key because it will be needed in the WireGuard configuration. The next step is generating the public key derived from this private key.

BASH

sudo cat /etc/wireguard/private.key | wg pubkey | sudo tee /etc/wireguard/public.key

The command chain uses the | (pipe) operator to pass output between commands:

sudo cat /etc/wireguard/private.key reads the private key file and sends it to standard output.
wg pubkey takes that output as input and generates the corresponding public key.
sudo tee /etc/wireguard/public.key saves the generated public key into /etc/wireguard/public.key.

When executed, it outputs a single line of base64 encoded text, which is the WireGuard server’s public key. This public key should be copied and shared with peers that need to connect to the server.

Step 2 — Choosing IPv4 and IPv6 Addresses

In the previous section, WireGuard was installed and a key pair was generated to encrypt server traffic. In this section, you create the server’s configuration file, configure WireGuard to start automatically on reboot, and assign private IPv4 and/or IPv6 addresses for the server and its peers. Follow the instructions for IPv4, IPv6, or both depending on your VPN requirements.

Step 2(a) — Choosing an IPv4 Range

If you run a WireGuard server with IPv4 peers, the server must assign private IPv4 addresses to the clients and its tunnel interface.You can choose these addresses from the standard private IP ranges:

10.0.0.0 to 10.255.255.255 (10/8 prefix)
172.16.0.0 to 172.31.255.255 (172.16/12 prefix)
192.168.0.0 to 192.168.255.255 (192.168/16 prefix)

This tutorial uses 10.8.0.0/24 as the private IP range for WireGuard. This range supports up to 255 peer connections and is chosen to avoid conflicts with other private networks. You can choose a different range if it fits your network configuration better.

The WireGuard server needs one private tunnel IPv4 address from a chosen range. In this example, 10.8.0.1/24 is used, but any address between 10.8.0.1 and 10.8.0.255 would work. If you choose a different address, remember it, because you’ll need to include it later in the server configuration file when creating the WireGuard server config in Step 3.

Step 2(b) — Choosing an IPv6 Range

To configure WireGuard with IPv6, you must generate a unique local address prefix within the reserved fd00::/8 block, adhering to the algorithm outlined in RFC 4193. This method ensures uniqueness by hashing a system identifier together with the current time. To begin this process, use the date utility to capture a 64-bit timestamp by running the following command.

BASH

date +%s%N

You will get a value like this, representing the total time since 1970-01-01 00:00:00 UTC. In the date command, %s corresponds to the seconds part, and %N corresponds to the nanoseconds part:

OUTPUT

1650301699497770167

Save the value for later reference in this section. Then, retrieve the machine-id from the /var/lib/dbus/machine-id file on your server. This ID is unique to your system and will remain the same for the lifetime of the server.

BASH

cat /var/lib/dbus/machine-id

You will get an output like the following:

OUTPUT

/var/lib/dbus/machine-id
610cef4946ed46da8f71dba9d66c67fb

Next, merge the timestamp with the machine-id and generate a hash of the combined value using the SHA-1 algorithm. The command should follow this format:

OUTPUT

printf <timestamp><machine-id> | sha1sum

Run the command substituting in your timestamp and machine identity values:

BASH

printf 1650301699497770167610cef4946ed46da8f71dba9d66c67fb | sha1sum

You will get a hash value like the following:

OUTPUT

442adea1488d96388dae9ab816045b24609a6c18  -

Keep in mind that the output from the sha1sum command is hexadecimal, meaning each byte of data is represented by two characters. For instance, 4f and 26 in the example correspond to the first two bytes of the hash.

The RFC algorithm only needs the least significant 40 bits (5 bytes) of the hash. You can use the cut command to extract the last 5 hexadecimal bytes from the hashed output:

BASH

printf 442adea1488d96388dae9ab816045b24609a6c18 | cut -c 31-

The -c option in the cut command specifies that only certain characters should be selected. Using 31- instructs cut to display all characters starting from position 31 through to the end of the line.

The output you get should look similar to this:

OUTPUT

24609a6c18

In this example output, the set of bytes is: 24 60 9a 6c 18.

You can create your own unique IPv6 network prefix by combining the 5 bytes you generated with the fd prefix. For better readability, separate every two bytes with a colon :. Since each subnet within your unique prefix can accommodate 18,446,744,073,709,551,616 IPv6 addresses, it’s common to limit the subnet to a /64 size for simplicity.

Based on the bytes you generated and using a /64 subnet, your resulting prefix will be:

OUTPUT

Unique Local IPv6 Address Prefix
fd24:609a:6c18::/64

You’ll use the fd24:609a:6c18::/64 range to assign IP addresses to the WireGuard tunnel interfaces on both the server and its peers. To assign an IP to the server, append 1 after the final ::, giving you fd24:609a:6c18::1/64. For peers, you can pick any address within this range, usually incrementing by one for each new peer—for example, fd24:609a:6c18::2/64. Be sure to note these IPs before moving on to set up the WireGuard server in the next part of the tutorial.

Step 3 — Creating a WireGuard Server Configuration

Before setting up your WireGuard server configuration, gather the following information:

Ensure you have the private key generated in Step 1 — Installing WireGuard and Generating a Key Pair.
If using WireGuard with IPv4, have the server IP you selected in Step 2(a) — Choosing an IPv4 Range. In this example, it’s 10.8.0.1/24.
If using WireGuard with IPv6, have the server IP from Step 2(b) — Choosing an IPv6 Range. In this example, it’s fd24:609a:6c18::1/64.

Once you have the necessary private key and IP address(es), create a new configuration file by opening your editor (like nano) and running the following command:

BASH

sudo nano /etc/wireguard/wg0.conf

Insert the following lines into the file, replacing the highlighted base64_encoded_private_key_goes_here with your actual private key, and updating the Address line with your IP address(es). You can also modify the ListenPort line if you want WireGuard to use a different port:

OUTPUT

/etc/wireguard/wg0.conf
[Interface]
PrivateKey = base64_encoded_private_key_goes_here
Address = 10.8.0.1/24, fd24:609a:6c18::1/64
ListenPort = 51820
SaveConfig = true

The SaveConfig line makes sure that any changes made to the WireGuard interface are saved back to the configuration file when the interface is stopped.

After adding this, save and close the /etc/wireguard/wg0.conf file. If you’re using nano, press CTRL+X, then Y, and hit ENTER to confirm. You now have a basic server configuration that can be expanded based on how you intend to use your WireGuard VPN server.

Step 4 — Adjusting the WireGuard Server’s Network Configuration

If your WireGuard peer only needs to access services on the server, you can skip this section. However, if you want the peer’s Internet traffic to pass through the WireGuard server, you’ll need to enable IP forwarding by following the steps in this part of the tutorial.

To set up forwarding, open the /etc/sysctl.conf file using nano or your preferred text editor:

BASH

sudo nano /etc/sysctl.conf

If you are using IPv4 with WireGuard, add the following line at the bottom of the file:

/etc/sysctl.conf

net.ipv4.ip_forward=1

If you are using IPv6 with WireGuard, add this line at the bottom of the file:

/etc/sysctl.conf

net.ipv6.conf.all.forwarding=1

If you’re using both IPv4 and IPv6, make sure to add both lines. After making the changes, save and close the file.

To apply the new settings to your current terminal session, run:

BASH

sudo sysctl -p

OUTPUT

net.ipv6.conf.all.forwarding = 1
net.ipv4.ip_forward = 1

With this setup, your WireGuard server can forward traffic from the VPN’s virtual Ethernet interface to other devices on the server and out to the public Internet. This allows all web traffic from your WireGuard peer to go through the server’s IP address, effectively masking the client’s public IP.

Before this routing works correctly, you need to set up firewall rules. These rules ensure that traffic between your WireGuard server and its peers is handled properly.

Step 5 — Configuring the WireGuard Server’s Firewall

In this part, you’ll modify the WireGuard server’s configuration to add firewall rules that ensure traffic between the server and clients is routed properly. If your VPN is only for connecting machines to access restricted resources, you can skip this step.

To let WireGuard traffic pass through the server’s firewall, you’ll need to enable masquerading. This iptables feature performs dynamic network address translation (NAT) to correctly route client connections.

Start by identifying your WireGuard server’s public network interface using the ip route command:

OUTPUT

ip route list default

The public interface is the string found within this command’s output that follows the word “dev”. For example, this result shows the interface named eth0, which is highlighted below:

OUTPUT

default via 203.0.113.1 dev eth0 proto static

Make a note of your device’s name, as you’ll need it when adding the iptables rules in the next step.

Then, to configure the firewall rules for your WireGuard server, reopen the /etc/wireguard/wg0.conf file using nano or your preferred text editor.

BASH

sudo nano /etc/wireguard/wg0.conf

At the bottom of the file after the SaveConfig = true line, paste the following lines:

BASH

/etc/wireguard/wg0.conf
. . .
PostUp = ufw route allow in on wg0 out on eth0
PostUp = iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PostUp = ip6tables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PreDown = ufw route delete allow in on wg0 out on eth0
PreDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
PreDown = ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

The PostUp lines execute when the WireGuard server starts the VPN tunnel. In this example, they add three UFW and iptables rules:

ufw route allow in on wg0 out on eth0 – This allows IPv4 and IPv6 traffic coming into the wg0 VPN interface to be forwarded to the server’s eth0 network interface. It works together with the net.ipv4.ip_forward and net.ipv6.conf.all.forwarding sysctl settings you configured earlier.
iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE – Enables masquerading for IPv4 traffic, rewriting packets from wg0 so they appear to originate from the server’s public IPv4 address.
ip6tables -t nat -I POSTROUTING -o eth0 -j MASQUERADE – Enables masquerading for IPv6 traffic, rewriting packets from wg0 so they appear to originate from the server’s public IPv6 address.

The PreDown lines run when the VPN tunnel is stopped. They reverse the PostUp rules, removing forwarding and masquerading settings for the VPN interface.

Edit your configuration to include only the IPv4 or IPv6 rules relevant to your VPN. For example, if using only IPv4, you can remove the ip6tables lines. If using only IPv6, keep only the ip6tables lines. The UFW lines should remain regardless of whether you use IPv4, IPv6, or both. Save and close the file when done.

Finally, allow traffic to and from the WireGuard UDP port itself. If you didn’t change the default port in /etc/wireguard/wg0.conf, this will be 51820. If you chose a different port, use that instead in the UFW command.

If you haven’t already opened the SSH port during the prerequisites, add it here as well:

BASH

sudo ufw allow 51820/udp
sudo ufw allow OpenSSH

Note: If you’re using a different firewall or have a customized UFW setup, you might need to add extra rules. For instance, if you route all network traffic through the VPN, you must allow port 53 for DNS queries, and ports 80 and 443 for HTTP and HTTPS traffic. Any additional protocols used over the VPN will also require corresponding firewall rules.

After adding those rules, disable and re-enable UFW to restart it and load the changes from all of the files you’ve modified:

BASH

sudo ufw disable
sudo ufw enable

You can verify that the rules have been applied by executing the ufw status command. When you run it, you should see output similar to this:

BASH

sudo ufw status

OUTPUT

Status: active

To                         Action      From
--                         ------      ----
51280/udp                  ALLOW       Anywhere                  
22/tcp                     ALLOW       Anywhere                  
51280/udp (v6)             ALLOW       Anywhere (v6)             
22/tcp (v6)                ALLOW       Anywhere (v6)

Your WireGuard server is now set up to manage VPN traffic properly, including forwarding and masquerading for connected peers. With the firewall rules configured, you can now start the WireGuard service to begin accepting peer connections.

Step 6 — Starting the WireGuard Server

WireGuard can be configured to run as a systemd service using its built-in wg-quick script. While you could manually use the wg command to create the tunnel every time you want to use the VPN, doing so is a manual process that becomes repetitive and error prone. Instead, you can use systemctl to manage the tunnel with the help of the wg-quick script.

Using a systemd service means that you can configure WireGuard to start up at boot so that you can connect to your VPN at any time as long as the server is running. To do this, enable the wg-quick service for the wg0 tunnel that you’ve defined by adding it to systemctl:

BASH

sudo systemctl enable wg-quick@wg0.service

Notice that the command specifies the name of the tunnel wg0 device name as a part of the service name. This name maps to the /etc/wireguard/wg0.conf configuration file. This approach to naming means that you can create as many separate VPN tunnels as you would like using your server.

For example, you could have a tunnel device and name of prod and its configuration file would be /etc/wireguard/prod.conf. Each tunnel configuration can contain different IPv4, IPv6, and client firewall settings. In this way you can support multiple different peer connections, each with their own unique IP addresses and routing rules.

Now start the service:

BASH

sudo systemctl start wg-quick@wg0.service

Double check that the WireGuard service is active with the following command. You should see active (running) in the output:

BASH

sudo systemctl status wg-quick@wg0.service

OUTPUT

wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
     Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled; vendor preset: enabled)
     Active: active (exited) since Mon 2022-04-18 17:22:13 UTC; 2s ago
       Docs: man:wg-quick(8)
             man:wg(8)
             https://www.wireguard.com/
             https://www.wireguard.com/quickstart/
             https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
             https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
    Process: 98834 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=0/SUCCESS)
   Main PID: 98834 (code=exited, status=0/SUCCESS)
        CPU: 193ms

Apr 18 17:22:13 thats-my-jam wg-quick[98834]: [#] wg setconf wg0 /dev/fd/63
Apr 18 17:22:13 thats-my-jam wg-quick[98834]: [#] ip -4 address add 10.8.0.1/24 dev wg0
Apr 18 17:22:13 thats-my-jam wg-quick[98834]: [#] ip -6 address add fd24:609a:6c18::1/64 dev wg0
Apr 18 17:22:13 thats-my-jam wg-quick[98834]: [#] ip link set mtu 1420 up dev wg0
Apr 18 17:22:13 thats-my-jam wg-quick[98834]: [#] ufw route allow in on wg0 out on ens3
Apr 18 17:22:13 thats-my-jam wg-quick[98890]: Rule added
Apr 18 17:22:13 thats-my-jam wg-quick[98890]: Rule added (v6)
Apr 18 17:22:13 thats-my-jam wg-quick[98834]: [#] iptables -t nat -I POSTROUTING -o ens3 -j MASQUERADE
Apr 18 17:22:13 thats-my-jam wg-quick[98834]: [#] ip6tables -t nat -I POSTROUTING -o ens3 -j MASQUERADE
Apr 18 17:22:13 thats-my-jam systemd[1]: Finished WireGuard via wg-quick(8) for wg0.

The output displays the ip commands used to create the virtual wg0 device and assign it the IPv4 and IPv6 addresses specified in your configuration file. You can use these commands to troubleshoot the tunnel or manually configure the VPN interface using the wg command.

Once the server is set up and running, the next step is to configure your client machine as a WireGuard peer and connect it to the server.

Step 7 — Configuring a WireGuard Peer

Setting up a WireGuard peer is much like configuring the WireGuard server. After installing the client software, you’ll generate a public and private key pair, assign one or more IP addresses for the peer, create a configuration file, and start the tunnel using the wg-quick script.

You can add multiple peers to your VPN by repeating these steps for each one. Be sure to track their private IP addresses carefully to avoid conflicts.

To configure the WireGuard peer, first make sure the WireGuard package is installed by running the following apt commands on the peer machine:

BASH

sudo apt update
sudo apt install wireguard

Creating the WireGuard Peer’s Key Pair

Next, generate a key pair for the peer following the same process used on the server. On your local machine or remote server that will act as the peer, create the peer’s private key using the following commands:

BASH

wg genkey | sudo tee /etc/wireguard/private.key
sudo chmod go= /etc/wireguard/private.key

You will once again get a single line of base64 encoded output, which is the private key. A copy is also saved at /etc/wireguard/private.key. Be sure to record this private key, as you’ll need it later when setting up the WireGuard configuration file.

Next, run the following command to generate the public key file:

BASH

sudo cat /etc/wireguard/private.key | wg pubkey | sudo tee /etc/wireguard/public.key

You’ll get a single line of base64 encoded output again this time it’s the public key for your WireGuard peer. Save a copy of it, as you’ll need to provide this public key to the WireGuard server to set up the encrypted connection.

Creating the WireGuard Peer’s Configuration File

After generating the key pair, you can create a configuration file for the peer that includes all the details required to connect to the WireGuard server.

To complete this configuration file, you’ll need the following information:

The base64 encoded private key generated on the peer.
The IPv4 and IPv6 address ranges configured on the WireGuard server.
The WireGuard server’s base64 encoded public key.
The public IP address and port used by the WireGuard server. This is typically the server’s IPv4 address, but if the server has an IPv6 address and the client also has IPv6 internet connectivity, you can use that instead.

Once you have gathered this information, create a new /etc/wireguard/wg0.conf file on the peer machine using nano or any text editor you prefer:

BASH

sudo nano /etc/wireguard/wg0.conf

Add the following lines to the file, substituting in the various data into the highlighted sections as required:

BASH

/etc/wireguard/wg0.conf
[Interface]
PrivateKey = base64_encoded_peer_private_key_goes_here
Address = 10.8.0.2/24
Address = fd24:609a:6c18::2/64

[Peer]
PublicKey = U9uE2kb/nrrzsEU58GD3pKFU3TLYDMCbetIsnV8eeFE=
AllowedIPs = 10.8.0.0/24, fd24:609a:6c18::/64
Endpoint = 203.0.113.1:51820

Note that the first Address line contains an IPv4 address from the 10.8.0.0/24 subnet you selected earlier. This address can be any unused IP within that subnet, as long as it doesn’t match the server’s IP. A simple approach is to increase the address by one each time you add a new peer.

Similarly, the second Address line uses an IPv6 address from the subnet you generated previously, typically by incrementing the server’s IPv6 address by one. Any unused IP within that range can be assigned if you prefer a different value.

Another important part of the configuration is the final AllowedIPs line. The IPv4 and IPv6 ranges specified there tell the peer to route traffic through the VPN only when the destination IP falls within those ranges. With the AllowedIPs setting, you can limit the VPN to communication between peers and internal services, or configure it to route all traffic through the VPN so that the WireGuard server acts as a gateway.

If you are using only IPv4, remove the fd24:609a:6c18::/64 portion (including the comma). On the other hand, if you are using only IPv6, keep the fd24:609a:6c18::/64 prefix and remove the 10.8.0.0/24 IPv4 range.

If you want the peer to route all of its traffic through the VPN and use the WireGuard server as its gateway, you can specify 0.0.0.0/0 for the entire IPv4 address space and ::/0 for the entire IPv6 address space.

(Optional) Configuring a Peer to Route All Traffic Over the Tunnel

If you configured the peer to send all its traffic through the VPN using the 0.0.0.0/0 or ::/0 routes and the peer is a remote system, you should follow the steps in this section. However, if the peer is a local machine, it’s better to skip this part.

For remote peers that you access through SSH or another protocol using a public IP address, additional rules must be added to the peer’s wg0.conf file. These rules make sure that you can still reach the system from outside the VPN while the tunnel is active. Without them, once the tunnel is established, traffic that normally uses the public network interface may not be routed correctly and could be forced through the wg0 tunnel interface, potentially making the remote system unreachable.

To begin, identify the system’s default gateway IP address by running the following ip route command:

BASH

ip route list table main default

You will receive output like the following:

OUTPUT

default via 203.0.113.1 dev eth0 proto static

Take note of the highlighted gateway IP address, 203.0.113.1, as well as the network interface eth0, since you’ll need them later. Your interface name may be different, so replace eth0 with the appropriate device name in the upcoming commands if necessary.

Next, determine the system’s public IP address by checking the network interface using the ip address show command:

BASH

ip -brief address show eth0

You will receive output like the following:

OUTPUT

eth0             UP             203.0.113.5/20 10.20.30.40/16 2604:a880:400:d1::3d3:6001/64 fe80::68d5:beff:feff:974c/64

In this example, the highlighted IP address 203.0.113.5 (excluding the /20 suffix) is the public IP assigned to the eth0 interface. You’ll need to include this address in the WireGuard configuration.

Next, open the WireGuard peer’s /etc/wireguard/wg0.conf file using nano or any text editor you prefer.

BASH

sudo nano /etc/wireguard/wg0.conf

Before the [Peer] line, add the following 4 lines:

BASH

PostUp = ip rule add table 200 from 203.0.113.5
PostUp = ip route add table 200 default via 203.0.113.1
PreDown = ip rule delete table 200 from 203.0.113.5
PreDown = ip route delete table 200 default via 203.0.113.1

[Peer]
. . .

These lines add a custom routing rule and route to ensure that traffic destined for the system’s public network continues to use the default gateway instead of being sent through the VPN tunnel.

PostUp = ip rule add table 200 from 203.0.113.5 – This command creates a rule that checks routing entries in table 200 whenever the source IP matches the system’s public address 203.0.113.5.
PostUp = ip route add table 200 default via 203.0.113.1 – This command sets the default route for table 200, directing traffic through the gateway 203.0.113.1 rather than the WireGuard interface.

The PreDown lines remove this custom rule and route when the VPN tunnel is stopped.

Note: The routing table number 200 used in these rules is simply an example and can be changed. You may choose any value between 2 and 252, or define a custom name by adding a label in the /etc/iproute2/rt_tables file and referencing that name instead of a numeric table ID.

If you are routing all the peer’s traffic over the VPN, ensure that you have configured the correct sysctl and iptables rules on the WireGuard Server in Step 4 — Adjusting the WireGuard Server’s Network Configuration and Step 5 — Configuring the WireGuard Server’s Firewall.

(Optional) Configuring the WireGuard Peer’s DNS Resolvers

If you are using the WireGuard server as a gateway to route all of a peer’s traffic, you should add a DNS resolver entry in the [Interface] section of the configuration. Without this setting, DNS queries might not pass through the VPN and could instead be visible to your Internet Service Provider or other third parties.

However, if you are only using WireGuard to access resources within the VPN network or for peer-to-peer connections, this step can be skipped.

To configure DNS resolvers for the peer, first identify which DNS servers the WireGuard server is using. On the WireGuard server, run the following command (replace eth0 with your network interface name if it differs in your setup):

BASH

resolvectl dns eth0

You should get an output like the following:

OUTPUT

Link 2 (eth0): 67.207.67.2 67.207.67.3 2001:4860:4860::8844 2001:4860:4860::8888

The IP addresses shown in the output represent the DNS servers currently used by the system. You can select one or more of them depending on your needs, and you may choose to use only IPv4, only IPv6, or both. Record the resolver addresses that you plan to use.

Next, add the selected DNS resolvers to the WireGuard peer’s configuration file. On the peer machine, open the /etc/wireguard/wg0.conf file using nano or your preferred text editor:

BASH

sudo nano /etc/wireguard/wg0.conf

Before the [Peer] line, add the following:

BASH

DNS = 67.207.67.2 2001:4860:4860::8844

[Peer]
. . .

Again, depending on your preference or requirements for IPv4 and IPv6, you can edit the list according to your needs.

After connecting to the VPN in the next step, you can verify that your DNS requests are being routed through the VPN by using a website.

You can also confirm that the peer is using the configured DNS servers by running the resolvectl dns command, just as you did on the server. The output should display the DNS resolvers you specified for the VPN tunnel.

OUTPUT

Output
Global: 67.207.67.2 67.207.67.3
. . .

Once you’ve configured the DNS resolvers, the next step is to add the peer’s public key to the server and then start the WireGuard tunnel on the peer.

Step 8 — Adding the Peer’s Public Key to the WireGuard Server

Before the peer can connect to the server, you must first add the peer’s public key to the WireGuard server. This step is essential for enabling the peer to send and receive traffic over the VPN. If this isn’t done, the server will block all traffic from the peer.

Make sure you have the peer’s base64 encoded public key by running:

BASH

sudo cat /etc/wireguard/public.key

OUTPUT

PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg=

Now log into the WireGuard server, and run the below command:

BASH

sudo wg set wg0 peer PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg= allowed-ips 10.8.0.2,fd24:609a:6c18::2

Keep in mind that the allowed-ips part of the command accepts a comma-separated list of IPv4 and IPv6 addresses. You can specify individual IPs to restrict which address a peer can use, or provide a range if peers are allowed to choose any IP within the VPN subnet. Each peer must have a unique allowed-ips setting no duplicates are allowed.

If you need to update the allowed-ips for an existing peer, you can rerun the command with the new IP addresses. Multiple IPs are supported. For example, to add 10.8.0.100 to a peer that already has 10.8.0.2 and fd24:609a:6c18::2 assigned, you would run the following:

BASH

sudo wg set wg0 peer PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg= allowed-ips 10.8.0.2,10.8.0.100,fd24:609a:6c18::2

Once you have run the command to add the peer, check the status of the tunnel on the server using the wg command:

BASH

sudo wg

OUTPUT

interface: wg0
 public key: U9uE2kb/nrrzsEU58GD3pKFU3TLYDMCbetIsnV8eeFE=
 private key: (hidden)
 listening port: 51820

peer: PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg=
 allowed ips: 10.8.0.2/32, fd24:609a:6c18::/128

Observe that the peer entry displays the WireGuard peer’s public key along with the IP address or range it is permitted to use.

With the peer’s connection settings now configured on the server, the next step is to start the VPN tunnel on the peer machine.

Step 9 — Connecting the WireGuard Peer to the Tunnel

With both the server and peer configured for IPv4, IPv6, packet forwarding, and DNS resolution, you’re ready to connect the peer to the VPN tunnel.

If you only want to use the VPN occasionally, you can manually start the connection using the wg-quick command. If you prefer the tunnel to start automatically like on the server, follow the instructions in Step 6 — Starting the WireGuard Server instead of using wg-quick.

If you are routing all traffic through the VPN and have configured DNS forwarding, you’ll first need to install the resolvconf utility on the WireGuard peer before starting the tunnel. Use the following command to do this:

BASH

sudo apt install resolvconf

To start the tunnel, run the following on the WireGuard Peer:

BASH

sudo wg-quick up wg0

You will get an output like the following:

OUTPUT

[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.8.0.2/24 dev wg0
[#] ip -6 address add fd24:609a:6c18::2/64 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] resolvconf -a tun.wg0 -m 0 -x

Take note of the highlighted IPv4 and IPv6 addresses assigned to the peer.

If you configured the peer’s AllowedIPs to 0.0.0.0/0 and ::/0 (or to ranges different from the ones defined for the VPN), the output will look similar to the following:

OUTPUT

[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.8.0.2/24 dev wg0
[#] ip -6 address add fd24:609a:6c18::2/64 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] resolvconf -a tun.wg0 -m 0 -x
[#] wg set wg0 fwmark 51820
[#] ip -6 route add ::/0 dev wg0 table 51820
[#] ip -6 rule add not fwmark 51820 table 51820
[#] ip -6 rule add table main suppress_prefixlength 0
[#] ip6tables-restore -n
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
[#] iptables-restore -n

In this example, observe the highlighted routes added by the command, which match the AllowedIPs specified in the peer’s configuration.

You can view the tunnel’s status on the peer by running the wg command:

BASH

sudo wg

OUTPUT

interface: wg0
 public key: PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg=
 private key: (hidden)
 listening port: 49338
 fwmark: 0xca6c

peer: U9uE2kb/nrrzsEU58GD3pKFU3TLYDMCbetIsnV8eeFE=
 endpoint: 203.0.113.1:51820
 allowed ips: 10.8.0.0/24, fd24:609a:6c18::/64
 latest handshake: 1 second ago
 transfer: 6.50 KiB received, 15.41 KiB sent

You can also check the tunnel status on the server, which should show similar output.

To confirm that the peer is routing traffic through the VPN, use the ip route and ip -6 route commands. If the VPN is configured as a gateway for all Internet traffic, verify which interface is being used for traffic to Cloudflare’s DNS servers at 1.1.1.1 and 2606:4700:4700::1111.

If your WireGuard setup is only for accessing resources within the VPN, replace the addresses in these commands with a valid IPv4 or IPv6 address from the VPN, such as the gateway for example, 10.8.0.1 or fd24:609a:6c18::1.

BASH

ip route get 1.1.1.1

OUTPUT

1.1.1.1 dev wg0 table 51820 src 10.8.0.2 uid 1000
   cache

Observe that the wg0 interface is being used along with the IPv4 address 10.8.0.2 assigned to the peer. Similarly, if you are using IPv6, run the following command:

BASH

ip -6 route get 2606:4700:4700::1111

OUTPUT

2606:4700:4700::1111 from :: dev wg0 table 51820 src fd24:609a:6c18::2 metric 1024 pref medium

Take note once more of the wg0 interface and the IPv6 address fd24:609a:6c18::2 assigned to the peer.

If the peer has a web browser, you can visit a related web site to verify that its traffic is being routed through the VPN.

When you’re ready to disconnect the peer from the VPN, use the wg-quick command:

BASH

sudo wg-quick down wg0

You will get an output like the following indicating that the VPN tunnel is shut down:

OUTPUT

[#] ip link delete dev wg0
[#] resolvconf -d tun.wg0 -f

If the peer’s AllowedIPs are configured as 0.0.0.0/0 and ::/0 (or if you use ranges different from the ones defined for the VPN), the output will look similar to the following:

OUTPUT

[#] ip rule delete table 200 from 203.0.113.5
[#] ip route delete table 200 default via 203.0.113.1
[#] ip -4 rule delete table 51820
[#] ip -4 rule delete table main suppress_prefixlength 0
[#] ip -6 rule delete table 51820
[#] ip -6 rule delete table main suppress_prefixlength 0
[#] ip link delete dev wg0
[#] resolvconf -d tun.wg0 -f
[#] iptables-restore -n
[#] ip6tables-restore -n

To reconnect the peer to the VPN, run wg-quick up wg0 again. If you want to fully remove a peer’s configuration from the WireGuard server, use the following command, making sure to replace it with the correct public key of the peer you wish to delete:

BASH

sudo wg set wg0 peer PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg= remove

Usually, you only need to delete a peer’s configuration if the peer is no longer in use or if its encryption keys have been compromised or updated. Otherwise, it’s best to keep the configuration intact so the peer can reconnect to the VPN without having to re-add its key and allowed-ips every time.

In this tutorial, you installed the WireGuard package and tools on both the server and client running Ubuntu 22.04. You configured firewall rules for WireGuard and updated kernel settings on the server to enable packet forwarding using sysctl. You also learned how to generate private and public encryption keys and set up the server and peers to connect securely.

For networks using IPv6, you learned how to create a unique local address range for peer connections. Additionally, you saw how to control which traffic passes through the VPN by restricting allowed network prefixes for peers, and how to use the WireGuard server as a gateway to route all Internet traffic for connected peers.

To explore more advanced WireGuard features, including setting up complex tunnels or using WireGuard with containers, check out the official WireGuard documentation.

Explore Dedicated Servers

CTCservers Recommended Tutorials

Discover CTCservers Dedicated Server Locations

CTCservers servers are available around the world, providing diverse options for hosting websites. Each region offers unique advantages, making it easier to choose a location that best suits your specific hosting needs.

North America

South America

Europe

Asia

Australia

Africa