How to Install WireGuard VPN on Ubuntu 24.04 for Full-Tunnel Access

In this tutorial, you will install WireGuard on Ubuntu 24.04, create a server and one client peer, enable IPv4 forwarding and NAT, route the client’s IPv4 internet traffic through the Raff VM, and verify the tunnel end to end.

WireGuard is a VPN protocol that creates an encrypted network interface between peers. In this full-tunnel setup, the client uses AllowedIPs = 0.0.0.0/0, so all client IPv4 traffic is routed through the WireGuard server. The server then forwards and masquerades that traffic through its public network interface.

Raff Technologies supports 3,000+ customers and 15,000+ VMs. A Raff Linux VM provides the public IPv4 address, Ubuntu environment, root-level networking control, 3 Gbps unmetered VM traffic, firewall controls, and private networking needed for this setup.

The original full-tunnel workflow was tested on a Raff Ubuntu 24.04 VM with 1 vCPU and 2 GB RAM. The routing, masquerading, AllowedIPs, and keepalive guidance in this revision was reviewed against current Ubuntu Server and WireGuard documentation on August 14, 2026.

IPv4 scope: This tutorial deliberately builds a full-tunnel VPN for IPv4. If the client has working IPv6, IPv6 traffic is not covered by 0.0.0.0/0. Configure an IPv6 tunnel separately before claiming that every IPv4 and IPv6 packet uses the VPN.

Prerequisites:

• A Raff Ubuntu 24.04 VM with a public IPv4 address
• SSH access with sudo privileges
• A client device running Linux, macOS, Windows, Android, or iOS
• UDP port 51820 available on the VM
• A client network that does not already use 10.90.90.0/24

This tutorial uses:

Step 1 — Install WireGuard on Ubuntu 24.04

Update the package index and install WireGuard plus the firewall tools used in the tutorial:

sudo apt update
sudo apt install -y wireguard ufw iptables curl

Verify the userspace tools:

wg --version
wg-quick --help 2>&1 | head

Load the WireGuard kernel module and confirm it is available:

sudo modprobe wireguard
lsmod | grep '^wireguard'

On Ubuntu 24.04, WireGuard support is part of the standard kernel. The wireguard package supplies tools such as wg and wg-quick.

Verification is complete when wg --version succeeds and the wireguard module is available.

Step 2 — Generate the server key pair safely

Create the WireGuard configuration directory with restrictive permissions:

sudo install -d -m 700 /etc/wireguard

Generate the server private key without printing it to the terminal:

sudo sh -c 'umask 077; wg genkey > /etc/wireguard/server_private.key'

Derive the public key:

sudo sh -c 'wg pubkey < /etc/wireguard/server_private.key > /etc/wireguard/server_public.key'

Set explicit permissions:

sudo chmod 600 /etc/wireguard/server_private.key
sudo chmod 644 /etc/wireguard/server_public.key

Display only the public key:

sudo cat /etc/wireguard/server_public.key

Check the permissions:

sudo ls -l /etc/wireguard/server_private.key /etc/wireguard/server_public.key

Expected permissions include:

-rw------- ... server_private.key
-rw-r--r-- ... server_public.key

Do not paste or screenshot the private key. Anyone who obtains it can impersonate that WireGuard peer.

Verification is complete when both key files exist and only root can read the server private key.

Step 3 — Identify the public interface and enable IPv4 forwarding

Find the interface Ubuntu uses for its default IPv4 route:

OUT_IFACE="$(ip route show default | awk '/default/ {print $5; exit}')"
printf 'Outbound interface: %s\n' "$OUT_IFACE"

Typical names include eth0, ens3, and similar names. Do not hardcode eth0 without checking the VM.

Create a dedicated sysctl file for WireGuard routing:

sudo tee /etc/sysctl.d/70-wireguard-routing.conf > /dev/null <<'EOF'
net.ipv4.ip_forward = 1
EOF

Apply it immediately:

sudo sysctl -p /etc/sysctl.d/70-wireguard-routing.conf

Verify forwarding:

sysctl net.ipv4.ip_forward

Expected output:

net.ipv4.ip_forward = 1

Ubuntu’s current WireGuard default-gateway guidance requires both IPv4 forwarding and masquerading on the gateway server.

Verification is complete when the outbound interface is identified and net.ipv4.ip_forward equals 1.

Step 4 — Create the WireGuard server configuration

Load the server private key into a temporary shell variable and re-detect the outbound interface:

SERVER_PRIVATE_KEY="$(sudo cat /etc/wireguard/server_private.key)"
OUT_IFACE="$(ip route show default | awk '/default/ {print $5; exit}')"

Create /etc/wireguard/wg0.conf:

sudo tee /etc/wireguard/wg0.conf > /dev/null <<EOF
[Interface]
Address = 10.90.90.1/24
ListenPort = 51820
PrivateKey = ${SERVER_PRIVATE_KEY}
SaveConfig = false

PostUp = iptables -A FORWARD -i %i -o ${OUT_IFACE} -j ACCEPT; iptables -A FORWARD -i ${OUT_IFACE} -o %i -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT; iptables -t nat -A POSTROUTING -s 10.90.90.0/24 -o ${OUT_IFACE} -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -o ${OUT_IFACE} -j ACCEPT; iptables -D FORWARD -i ${OUT_IFACE} -o %i -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT; iptables -t nat -D POSTROUTING -s 10.90.90.0/24 -o ${OUT_IFACE} -j MASQUERADE
EOF

unset SERVER_PRIVATE_KEY

Protect the configuration:

sudo chmod 600 /etc/wireguard/wg0.conf

The NAT rule is restricted to the WireGuard subnet instead of masquerading unrelated VM traffic.

Validate the non-secret settings without dumping the private key:

sudo grep -E '^(Address|ListenPort|PostUp|PostDown)' /etc/wireguard/wg0.conf

Expected output includes:

Address = 10.90.90.1/24
ListenPort = 51820

Verification is complete when wg0.conf is mode 600, uses the detected outbound interface, and scopes masquerading to 10.90.90.0/24.

Step 5 — Allow WireGuard through UFW

Always keep the current SSH path allowed before changing firewall rules:

sudo ufw allow OpenSSH

Allow the WireGuard UDP port:

sudo ufw allow 51820/udp

Enable UFW if it is not already active:

sudo ufw --force enable

Review the rules:

sudo ufw status numbered

Expected output includes an SSH allow rule and:

51820/udp                 ALLOW IN

WireGuard uses UDP. There is no reason to open TCP port 51820 for this configuration.

Verification is complete when SSH remains reachable and UDP 51820 is allowed.

Step 6 — Generate the client key pair and add the peer

Generate the client private key on the client device when possible. This keeps the client private key off the server.

On a Linux client, install WireGuard:

sudo apt update
sudo apt install -y wireguard resolvconf

Generate the client key pair:

umask 077
wg genkey > ~/wg-client-private.key
wg pubkey < ~/wg-client-private.key > ~/wg-client-public.key

Display only the public key:

cat ~/wg-client-public.key

Copy that public key to the server. On the server, append the peer block to wg0.conf, replacing CLIENT_PUBLIC_KEY:

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

[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.90.90.2/32
EOF

Confirm that the peer block exists without printing private material:

sudo grep -A2 '^\[Peer\]' /etc/wireguard/wg0.conf

Expected output includes:

[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.90.90.2/32

Replace the placeholder before continuing.

Verification is complete when the client has its own private key and the server contains only that client’s public key plus 10.90.90.2/32.

Step 7 — Start the WireGuard server

Test the configuration by bringing up wg0:

sudo wg-quick up wg0

Check the interface:

ip -4 addr show wg0
sudo wg show wg0

Expected state includes:

10.90.90.1/24
listening port: 51820
allowed ips: 10.90.90.2/32

Verify the NAT rule is present:

sudo iptables -t nat -S POSTROUTING | grep '10.90.90.0/24'

Then enable the interface at boot:

sudo systemctl enable wg-quick@wg0

Check service state:

systemctl is-enabled wg-quick@wg0
systemctl is-active wg-quick@wg0

Expected output:

enabled
active

Verification is complete when wg0 owns 10.90.90.1/24, listens on UDP 51820, and the scoped masquerade rule exists.

Step 8 — Configure the client for full-tunnel IPv4 routing

Get the server public key on the server:

sudo cat /etc/wireguard/server_public.key

Get the Raff VM public IPv4 address from the dashboard or with:

curl -4s https://icanhazip.com

On a Linux client, load the client private key into a temporary variable:

CLIENT_PRIVATE_KEY="$(cat ~/wg-client-private.key)"

Create /etc/wireguard/wg0.conf, replacing SERVER_PUBLIC_KEY and your_server_ip:

sudo tee /etc/wireguard/wg0.conf > /dev/null <<EOF
[Interface]
PrivateKey = ${CLIENT_PRIVATE_KEY}
Address = 10.90.90.2/24
DNS = 1.1.1.1

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

unset CLIENT_PRIVATE_KEY
sudo chmod 600 /etc/wireguard/wg0.conf

AllowedIPs = 0.0.0.0/0 makes WireGuard the default route for IPv4. WireGuard’s documentation recommends a persistent keepalive interval such as 25 seconds when a peer behind NAT must keep its mapping alive.

Bring up the client tunnel:

sudo wg-quick up wg0

Verify the interface and routes:

ip -4 addr show wg0
sudo wg show wg0
ip route get 1.1.1.1

Expected state: wg0 has 10.90.90.2/24, the peer endpoint is the Raff VM, and the IPv4 default-route handling uses WireGuard.

On Windows, macOS, Android, or iOS, create the same interface/peer values in the official WireGuard application instead of using wg-quick.

Verification is complete when the client tunnel is active and the WireGuard peer is configured with 0.0.0.0/0.

Step 9 — Verify the full-tunnel VPN end to end

From the client, reach the server’s VPN address:

ping -c 4 10.90.90.1

Verify public IPv4 egress through the tunnel:

curl -4s https://icanhazip.com

The result should match the Raff VM’s public IPv4 address.

On the server, inspect the peer:

sudo wg show wg0

A connected peer should show:

latest handshake: ...
transfer: ... received, ... sent

Check the client route again:

ip route get 1.1.1.1

If the client has IPv6 connectivity, test it separately:

curl -6 --connect-timeout 5 https://icanhazip.com || echo 'No working IPv6 path'

If that command succeeds, IPv6 is still outside this IPv4-only tunnel. Configure IPv6 addressing, forwarding, firewalling, and routing separately before treating the VPN as an all-protocol full tunnel.

End-to-end verification is complete when:

• 10.90.90.1 responds through the tunnel
• The client’s public IPv4 address matches the Raff VM
• wg show reports a recent handshake
• Transfer counters increase
• The route to an IPv4 internet destination uses the WireGuard full-tunnel policy

Step 10 — Verify reboot persistence

Reboot the server during a safe test window:

sudo reboot

After the server returns, reconnect over SSH and verify WireGuard:

systemctl is-active wg-quick@wg0
sudo wg show wg0
sudo iptables -t nat -S POSTROUTING | grep '10.90.90.0/24'

Reconnect the client tunnel if necessary:

sudo wg-quick down wg0 2>/dev/null || true
sudo wg-quick up wg0

Repeat the IPv4 egress test:

curl -4s https://icanhazip.com

Verification is complete when the server restores wg0 and its NAT rule after reboot and the client again exits through the Raff VM’s IPv4 address.

Cleanup and rollback

To stop the VPN without deleting keys or configuration:

sudo wg-quick down wg0
sudo systemctl disable wg-quick@wg0

Because the NAT and forwarding filter rules are defined as PostUp/PostDown commands, wg-quick down wg0 removes the rules it added for this interface.

If the VM no longer needs to accept WireGuard connections, remove the UFW rule:

sudo ufw delete allow 51820/udp
sudo ufw status numbered

Keep /etc/wireguard if you intend to restore the VPN later. Delete private keys only when the VPN is permanently decommissioned and you have confirmed no peer still depends on them.

On a Linux client, disconnect with:

sudo wg-quick down wg0

Verification is complete when wg0 no longer exists and the server no longer has the WireGuard-specific NAT rule.

Troubleshooting

No WireGuard handshake appears

Check the server listener, UFW, endpoint, and peer keys:

sudo wg show wg0
sudo ss -lunp | grep ':51820'
sudo ufw status numbered

On the client, confirm the endpoint uses the Raff VM’s current public IPv4 address and UDP port 51820.

A missing handshake usually points to endpoint reachability, firewall rules, or mismatched public/private keys.

The handshake works but internet access fails

Check IPv4 forwarding and NAT on the server:

sysctl net.ipv4.ip_forward
OUT_IFACE="$(ip route show default | awk '/default/ {print $5; exit}')"
printf 'Outbound interface: %s\n' "$OUT_IFACE"
sudo iptables -t nat -S POSTROUTING | grep '10.90.90.0/24'
sudo iptables -S FORWARD | grep 'wg0'

Expected state includes net.ipv4.ip_forward = 1, the correct outbound interface, and the WireGuard forwarding/NAT rules.

DNS stops working after the client connects

On Linux, make sure resolvconf is installed if the client config contains DNS = 1.1.1.1:

sudo apt install -y resolvconf
sudo wg-quick down wg0
sudo wg-quick up wg0

Then test both DNS and direct IP connectivity:

getent hosts example.com
ping -c 2 1.1.1.1

If IP connectivity works but names do not resolve, the tunnel itself is working and the remaining issue is DNS configuration.

The client loses access to its local LAN

A full-tunnel route intentionally captures 0.0.0.0/0. If the client must keep access to a local printer, NAS, or router subnet, add an explicit local route outside the tunnel or use the separate private-access WireGuard tutorial, which is designed as a split-tunnel setup.

wg-quick up wg0 reports that the interface already exists

Inspect the existing interface:

ip link show wg0
sudo wg show wg0

If it is the same configuration, bring it down cleanly before retrying:

sudo wg-quick down wg0
sudo wg-quick up wg0

Reboot removes internet routing through the tunnel

Check the service and NAT hook:

systemctl status wg-quick@wg0 --no-pager
sudo wg show wg0
sudo iptables -t nat -S POSTROUTING | grep '10.90.90.0/24'

If the service failed, review its journal:

sudo journalctl -u wg-quick@wg0 -n 80 --no-pager

Conclusion and next steps

You now have a WireGuard server on Ubuntu 24.04 that routes a client’s IPv4 internet traffic through the Raff VM using wg0, IPv4 forwarding, scoped masquerading, UFW, and a full-tunnel AllowedIPs = 0.0.0.0/0 client policy.

For private-only access without routing all IPv4 internet traffic through the server, follow Set Up WireGuard VPN on Ubuntu 24.04 for Private Access. Continue with Set Up UFW Firewall on Ubuntu 24.04 and Set Up SSH Keys on Ubuntu 24.04 for the surrounding access controls.

For multi-network architectures, Raff VPC provides private networking and supports broader site-to-site VPN designs when you need to connect whole networks rather than a single client.