How to Set Up WireGuard VPN on Ubuntu Server 24.04 (Secure Remote Access in 15 Minutes)

Why WireGuard is a smart VPN choice in 2026

WireGuard is a modern VPN that focuses on speed, simplicity, and strong security. Compared to traditional VPN stacks, it uses fewer lines of code, performs well on low-cost VPS servers, and is easy to troubleshoot. This tutorial shows how to install and configure WireGuard on Ubuntu Server 24.04 so you can safely access your home or office network, manage servers remotely, and protect traffic on public Wi‑Fi.

What you need before starting

You will need: (1) an Ubuntu Server 24.04 machine with root or sudo access, (2) a public IP address or a router that can forward ports to the VPN server, and (3) a client device (Linux, Windows, macOS, Android, or iOS). If your server is behind NAT (common at home), you must forward a UDP port from your router to the server’s local IP.

Step 1: Update the server and install WireGuard

Start by updating packages and installing WireGuard and the helper tools. On Ubuntu 24.04, WireGuard is included in the standard repositories.

Run:

sudo apt update && sudo apt -y upgrade
sudo apt -y install wireguard

Step 2: Generate server keys (securely)

WireGuard uses public/private key pairs. Keep private keys secret and never paste them into tickets or chat. Create a dedicated directory and lock down permissions.

sudo -i
umask 077
mkdir -p /etc/wireguard
cd /etc/wireguard
wg genkey | tee server.key | wg pubkey > server.pub

You can view the public key with cat /etc/wireguard/server.pub. Avoid printing the private key unless absolutely necessary.

Step 3: Create the WireGuard server configuration

WireGuard’s default interface name is commonly wg0. Pick a private VPN subnet that does not conflict with your LAN. In this example, the VPN network is 10.10.10.0/24, and the server’s VPN IP is 10.10.10.1.

Create the config file:

nano /etc/wireguard/wg0.conf

Paste and adjust the following:

[Interface]
Address = 10.10.10.1/24
ListenPort = 51820
PrivateKey = YOUR_SERVER_PRIVATE_KEY

# Enable NAT so VPN clients can reach the internet (optional but common)
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

Replace YOUR_SERVER_PRIVATE_KEY with the content of /etc/wireguard/server.key. Also verify the server’s main network interface name. On many systems it is eth0, but it might be ens3, enp0s3, or similar. Check with ip a and update the PostUp/PostDown lines accordingly.

Step 4: Enable IP forwarding

If you want VPN clients to reach other networks (like the internet or your LAN), enable IP forwarding.

echo "net.ipv4.ip_forward=1" | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system

Step 5: Create a client profile and add it to the server

Now generate keys for one client (repeat for each device). This example creates a client named laptop1 with VPN IP 10.10.10.2.

cd /etc/wireguard
wg genkey | tee laptop1.key | wg pubkey > laptop1.pub

Edit the server config and add a peer section at the bottom:

nano /etc/wireguard/wg0.conf

[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.10.10.2/32

Replace CLIENT_PUBLIC_KEY with the content of laptop1.pub.

Step 6: Start WireGuard and enable it on boot

Bring up the VPN interface and ensure it starts automatically after reboots.

sudo systemctl enable --now wg-quick@wg0
sudo wg show

The wg show output is your first checkpoint. If the service fails, run sudo systemctl status wg-quick@wg0 to see exactly what went wrong (wrong interface name, missing key, or syntax issues are the usual suspects).

Step 7: Build the client configuration

Create a WireGuard client config file on your client device (or generate it on the server and copy it securely). You will need the server’s public key, the client’s private key, and your server’s public IP or DNS name.

Client config example:

[Interface]
Address = 10.10.10.2/32
PrivateKey = CLIENT_PRIVATE_KEY
DNS = 1.1.1.1

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = YOUR_SERVER_PUBLIC_IP:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

If you only want access to your private networks (and not route all traffic through the VPN), change AllowedIPs to your LAN subnet, for example 192.168.1.0/24, and keep 10.10.10.0/24 as needed. The PersistentKeepalive value helps mobile clients stay connected behind NAT.

Troubleshooting tips that save time

If the VPN connects but you cannot reach anything, check these items in order: (1) confirm UDP port 51820 is open/forwarded to the server, (2) verify your PostUp interface name matches the real outbound interface, (3) confirm IP forwarding is enabled, and (4) make sure the client’s AllowedIPs matches the routing you expect. Also review your firewall rules. On Ubuntu, you may need to allow the UDP port: sudo ufw allow 51820/udp. Finally, re-check keys; one incorrect character in a key line will prevent a proper handshake.

Next steps (best practices)

Once your first client works, add additional peers one at a time and assign each a unique VPN IP. Use a DNS name for the server if your IP changes often. Keep your system updated and consider restricting management access (SSH) to VPN-only for stronger security. WireGuard is lightweight enough to run on a small VPS, making it a practical “always-on” remote access solution for admins and power users.

Comments

Popular Posts

Install Ollama and Open WebUI on Ubuntu 24.04 with NVIDIA GPU Acceleration (Step-by-Step)

Install a Local AI Chatbot on Ubuntu 24.04 with Ollama and Open WebUI (Step-by-Step)

Install Ollama + Open WebUI on Ubuntu 24.04 with NVIDIA GPU Acceleration (Step-by-Step)

Trending Now

Homogeneous Nucleation on Mars: A Textbook Process Finally Observed in Nature

By the end of this piece, you will understand what the Arsia Mons Elongated Cloud is, why it resisted explanation for several years after its first observation, and what the newly published model reveals about a physical process that has never been directly confirmed on any planet's atmosphere. The cloud that broke the model Every morning during Martian spring and summer, a thin, extremely long cloud forms near the Arsia Mons volcano and gradually elongates until it stretches to more than 1,000 miles before dissipating. The cycle then repeats for several months. The formation was first recorded by a probe in 2018, and from that point onward it became a persistent puzzle for atmospheric scientists working with Mars data. The cloud's geometry, its timing, and its seasonal recurrence all pointed to a real and reproducible physical process, yet no existing model could reproduce it. For a technical audience familiar with simulation work, the situation is analogous to a product...