Install WireGuard on Ubuntu 24.04

Ubuntu 24.04 LTS ships with first-class WireGuard support: the kernel module is available, wireguard-tools is in the default apt repositories, and wg-quick systemd units make bring-up straightforward. You do not need third-party PPAs for a standard install.

This guide installs WireGuard on Ubuntu 24.04, creates a server interface, enables IP forwarding, configures UFW, and connects a client peer. The same steps apply to a DigitalOcean Droplet or any Ubuntu 24.04 VPS you administer. Commands assume sudo access and a public IPv4 address for the server peer.

Read this as an operator’s runbook, not a protocol deep dive. By the end you should have a persistent wg0 interface and a client config you can import into official WireGuard applications.

What You'll Learn

• How to install WireGuard packages on Ubuntu 24.04
• How to generate and protect keys
• How to write a minimal wg0.conf for a VPN server role
• How to enable IP forwarding and NAT for client internet egress
• How to allow UDP through UFW safely
• How to add peers, verify handshakes, and troubleshoot common failures

Prerequisites

• Ubuntu 24.04 LTS (server or cloud image)
• SSH access with sudo
• UFW available (default on Ubuntu Server)
• A free UDP port (this guide uses 51820)
• Client device with WireGuard installed

Install Packages

Update indexes and install tools:

sudo apt update
sudo apt install -y wireguard wireguard-tools

On Ubuntu 24.04, wireguard pulls in the userspace tools and ensures module support is present. Load and verify:

sudo modprobe wireguard
ip link help | grep -i wireguard
wg version

You should see WireGuard listed as a link type and a version string from wg.

Directory Layout and Permissions

sudo mkdir -p /etc/wireguard
sudo chmod 700 /etc/wireguard
cd /etc/wireguard

Private keys must not be world-readable. Use umask 077 when generating files in this directory.

Generate Server Keys

umask 077
wg genkey | tee server_private.key | wg pubkey > server_public.key
sudo chmod 600 server_private.key

Optional preshared key for an extra symmetric secret (per peer):

wg genpsk > client1_psk.key

A PSK is optional for correctness today; some teams add it for defense in depth. If you use one, the same PSK must appear on both peers.

Choose Tunnel Addressing

Avoid subnets that collide with common LAN ranges (192.168.0.0/24, 10.0.0.0/24). Example plan:

Stick to /32 AllowedIPs for road-warrior clients unless you intentionally route a LAN behind a peer.

Identify the Public Interface

NAT rules need the correct egress interface:

ip -br link
ip route show default

On many cloud images the default route goes out eth0 or ens3. Substitute the name you see in the commands below.

Create /etc/wireguard/wg0.conf

[Interface]
Address = 10.66.66.1/24
ListenPort = 51820
PrivateKey = PASTE_SERVER_PRIVATE_KEY

# Persist forwarding (also set via sysctl.d)
PostUp = sysctl -w net.ipv4.ip_forward=1
PostUp = iptables -t nat -A POSTROUTING -s 10.66.66.0/24 -o eth0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -s 10.66.66.0/24 -o eth0 -j MASQUERADE

Prefer reading the key from a file if you automate later; for a first manual server, pasting into PrivateKey is common. Restrict file mode:

sudo chmod 600 /etc/wireguard/wg0.conf

Make forwarding persistent:

printf '%s\n' 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system

Configure UFW

Allow SSH first if UFW is not yet enabled:

sudo ufw allow OpenSSH
sudo ufw allow 51820/udp comment 'WireGuard'
sudo ufw status verbose

If UFW is inactive:

sudo ufw enable

For client internet egress through the server, ensure forwarding is not dropped:

grep DEFAULT_FORWARD_POLICY /etc/default/ufw

If it is DROP, either set DEFAULT_FORWARD_POLICY="ACCEPT" and reload, or add explicit UFW route allow rules for 10.66.66.0/24. Accepting forward traffic is the quicker path for a dedicated VPN VPS; tighten later if the host runs other services.

Cloud provider security groups or DigitalOcean Cloud Firewalls must also allow UDP 51820. Host UFW cannot override an upstream deny.

Start wg-quick@wg0

sudo systemctl enable --now wg-quick@wg0
systemctl status wg-quick@wg0 --no-pager
sudo wg show
ip addr show wg0

Expect wg0 with 10.66.66.1 and listening port 51820. If the service fails, journalctl -u wg-quick@wg0 -e usually shows syntax or permission errors.

Create a Client Peer

Generate keys (on the client machine when possible):

wg genkey | tee client1_private.key | wg pubkey > client1_public.key

Add a peer block to the server config:

[Peer]
PublicKey = CLIENT1_PUBLIC_KEY
AllowedIPs = 10.66.66.2/32
# PresharedKey = CLIENT1_PSK   # optional

Apply without tearing down the interface:

sudo wg syncconf wg0 <(sudo wg-quick strip wg0)

Or restart:

sudo systemctl restart wg-quick@wg0

Client configuration

[Interface]
PrivateKey = CLIENT1_PRIVATE_KEY
Address = 10.66.66.2/32
DNS = 1.1.1.1

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

Notes:

• AllowedIPs = 0.0.0.0/0 sends all IPv4 traffic through the tunnel
• Split tunnel example: AllowedIPs = 10.66.66.0/24
• PersistentKeepalive keeps NAT mappings warm from client to server
• Set DNS when full-tunnel would otherwise break resolver reachability

Activate on the client, then on the server run sudo wg show and confirm a handshake timestamp.

Dual-Stack and IPv6 (Optional)

Ubuntu 24.04 handles IPv6 well if the VPS has an address. You can add an IPv6 tunnel address on the interface, for example Address = 10.66.66.1/24, fd42:42:42::1/64, include IPv6 in peer AllowedIPs, and open UDP 51820 for IPv6 in UFW (ufw allow 51820/udp covers both when IPv6 is enabled in UFW). Get IPv4 working first so you debug one stack at a time.

Useful Verification Commands

sudo wg show wg0 dump
ping -c 3 10.66.66.1          # from client
traceroute 1.1.1.1            # path sanity
curl -4 https://ifconfig.me   # expect server public IP if full-tunnel
sudo tcpdump -ni eth0 udp port 51820

If packets never hit tcpdump, the block is upstream (client network, cloud firewall) or the endpoint is wrong. If packets arrive but no handshake, keys or peer config are wrong.

Manage Peers Over Time

Revoke a peer by deleting its [Peer] section and reloading. Rotate keys by generating a new pair, updating both sides, then removing the old peer. Do not leave unused peers in the file “just in case.”

For more than a handful of peers, move to templates or a management platform. Hand-editing wg0.conf does not scale and increases the chance of a bad AllowedIPs entry.

Ubuntu 24.04 Specific Notes

• Kernel: WireGuard is in-tree; you should not need wireguard-dkms on stock Ubuntu 24.04 kernels
• nftables: UFW on 24.04 still provides the familiar CLI; underneath it uses nftables—manage policy via ufw unless you know you need raw nft
• systemd: wg-quick@.service is the supported enablement path; avoid custom rc scripts
• resolvers: systemd-resolved is default; client DNS= entries matter more for road warriors than server-side resolved quirks

Troubleshooting Playbook

Work through failures in this order—most “WireGuard is broken” reports are firewall or routing, not cryptography.

No handshake

1. Confirm the service is listening: sudo ss -ulpn | grep 51820
2. Capture on the public interface: sudo tcpdump -ni eth0 udp port 51820
3. If no packets arrive, fix cloud firewall / UFW / client Endpoint
4. If packets arrive but no handshake, compare public keys character by character; ensure you did not paste the private key into a PublicKey field
5. Confirm the client peer’s [Peer] block exists on the server and was reloaded

Handshake works, no ping

1. Check client Address= matches server AllowedIPs for that peer (10.66.66.2/32 both sides of the policy)
2. sudo wg show — look for transfer counters increasing when you ping
3. On the server, ip route get 10.66.66.2 should reference wg0
4. Disable conflicting policy routing or leftover Docker iptables rules if present

Ping works, no internet egress

1. sysctl net.ipv4.ip_forward must be 1
2. Confirm MASQUERADE/POSTROUTING uses the real egress NIC from ip route show default
3. Check UFW forward policy or route allows
4. From the client, curl -4 ifconfig.me should show the VPS public IP when full-tunnel is intended

DNS breaks after connect

Add DNS = to the client [Interface] block, or use split tunnel so the client keeps LAN DNS. On Linux NetworkManager clients, also check that the connection profile is not ignoring WireGuard DNS.

MTU Notes

Path MTU issues show up as “small pings work, large HTTPS stalls.” If you see that pattern, try on the client:

[Interface]
MTU = 1280

Or clamp TCP MSS via iptables on the server for traffic leaving wg0. Start with diagnosis (ping -M do -s 1400) before permanently lowering MTU. Many cloud paths work at WireGuard’s default; do not lower MTU preemptively without evidence.

Multiple Peers Quickly

Template approach for peer blocks:

PEER_NAME=alice
PEER_IP=10.66.66.3
PEER_PUB=$(cat alice_public.key)

sudo tee -a /etc/wireguard/wg0.conf >/dev/null <<EOF

[Peer]
# ${PEER_NAME}
PublicKey = ${PEER_PUB}
AllowedIPs = ${PEER_IP}/32
EOF

sudo wg syncconf wg0 <(sudo wg-quick strip wg0)

Keep a CSV or inventory file with name, IP, public key, and device. The conf file is not a CRM.

Best Practices

• Mode 600 on private keys and wg0.conf
• One tunnel IP per peer; never share private keys across devices
• Keep server AllowedIPs tight (/32 per client) unless routing a subnet by design
• Align host firewall and cloud firewall for UDP 51820
• Use wg syncconf for peer updates to avoid blipping active sessions when possible
• Record peer metadata outside the conf file (owner, device, date)
• Prefer hostname endpoints with short DNS TTLs if IPs change
• Test revoke and restore once before you need it in an incident

Common Mistakes

• Installing only wireguard-tools mentally but forgetting to start wg-quick@wg0
• MASQUERADE on the wrong interface — egress silently fails
• Client and server AllowedIPs inverted — classic “handshake works, nothing routes”
• Forgetting cloud security group UDP rules
• Using a LAN-colliding tunnel subnet
• Leaving SaveConfig = true enabled while also hand-editing — can surprise you on shutdown; prefer deliberate file edits for servers
• Copy-pasting private keys into tickets or chat

FAQ

Does this work on Ubuntu 22.04 as well?

Yes. Package names and wg-quick usage are the same. This article targets 24.04 because it is the current LTS many new VPS images use.

Do I need resolvconf or openresolv?

For server interfaces, usually no. Clients sometimes use those helpers so WireGuard can push DNS. Official mobile and desktop apps handle DNS from the config without extra packages on the server.

Can WireGuard listen on a port other than 51820?

Yes. Change ListenPort and matching firewall rules and client Endpoint ports together.

How do I run WireGuard without NAT?

If clients only need access to the tunnel subnet or to networks you route explicitly, you can omit MASQUERADE. NAT is for “use the VPS public IP for general internet egress.”

Why is my handshake older than two minutes and idle?

Idle peers may show older handshakes until traffic resumes. WireGuard rekeys as needed. Lack of any handshake after activation is the failure mode to debug.

Should I put WireGuard behind TCP 443?

WireGuard is UDP-native. Wrapping it in TCP adds latency and complexity. Prefer allowing UDP. Only add wrappers when a hostile network blocks UDP entirely.

Summary

Installing WireGuard on Ubuntu 24.04 is: apt install, generate keys, write wg0.conf, enable forwarding and NAT, allow UDP 51820, enable wg-quick@wg0, add peers with careful AllowedIPs, and verify with wg show plus a ping. Keep permissions tight and firewall layers consistent.

Once the tunnel works, invest in peer inventory and automation before the conf file becomes tribal knowledge.

If you want to automate VPN server deployment instead of configuring everything manually, TunnelFleet helps you provision and manage VPN infrastructure on your own cloud provider with minimal manual setup.