How to Set Up a WireGuard VPN on a Dedicated Server (Ubuntu 24.04)

What Is a WireGuard VPN on a Dedicated Server?

A WireGuard VPN on a dedicated server is a private, self-hosted VPN endpoint that runs on a physical server you control. Your laptop, phone or office router connects to it through an encrypted tunnel, so you can reach private services securely or send your internet traffic out through the server's public IP address.

WireGuard is a modern, open-source VPN protocol built into the Linux kernel. It authenticates each peer with public-key cryptography and uses a small codebase, which makes it quick to configure and easier to audit than older VPN stacks such as OpenVPN or IPsec.

This guide walks you through the complete setup on Ubuntu Server 24.04 LTS:

• Installing WireGuard and identifying your network interface

• Generating server and client key pairs

• Enabling IPv4 forwarding

• Configuring UFW firewall rules and NAT (masquerading)

• Creating the wg0 interface and adding a peer

• Connecting a client and verifying the tunnel

• Troubleshooting, securing and scaling the VPN

The example uses one server and one client. You can repeat the peer steps for as many laptops, phones and remote systems as you need.

Why Run Your Own VPN Instead of Using a Commercial Provider?

A self-hosted VPN is a good fit when you want control more than convenience. On your own server you decide:

• Who has access. Every device has its own key pair, so you can grant and revoke access per device.

• Which IP address you appear from. Traffic exits through a dedicated, static public IP rather than a shared pool used by thousands of strangers.

• How traffic is routed. You can run a full tunnel, a split tunnel, or a private link to internal services such as databases, admin panels and staging servers.

• What is logged. Retention is entirely your decision and your responsibility.

One caution: a self-hosted VPN does not make you anonymous. Websites see your server's IP address, and your hosting provider can see that the server exists. A VPN protects traffic between your device and your server. It is a security and access tool, not an anonymity tool.

Why a Dedicated Server Suits a Self-Hosted VPN

You can run WireGuard on almost any Linux machine, but dedicated server hosting has practical advantages for a VPN endpoint:

• Predictable resources. Encryption and packet forwarding use CPU. With a dedicated server, no neighbouring tenant competes for it.

• Full network control. You manage the kernel settings, firewall and routing table yourself, which a full-tunnel VPN requires.

• A stable public IPv4 address. Clients need a fixed endpoint to connect to.

• Port speed and bandwidth. A 1 Gbps or faster port helps when several users stream, transfer files or back up through the tunnel. Real-world throughput still depends on CPU, upstream routing and the client's own connection.

• Location choice. Choose a data centre close to your users or to the services you need to reach, to keep latency low.

A dedicated server does not make a VPN faster or safer by itself. Correct configuration, key hygiene and regular updates matter more than the hardware.

What You Will Build: Network Layout

Your public IP address and outbound network interface will differ. Replace every example value before you apply a configuration.

How the VPN Traffic Flows

When the client connects, its IPv4 traffic travels through an encrypted WireGuard tunnel to the dedicated server. The server forwards that traffic to the internet through its public network interface using NAT, and replies return through the same path. This is a full-tunnel setup. A split-tunnel setup sends only selected private network traffic through WireGuard and leaves everything else on the local connection.

Requirements

Before you start, make sure you have:

• A dedicated server running Ubuntu Server 24.04 LTS

• A public IPv4 address assigned to the server

• Root or sudo access over SSH

• Permission to change firewall rules and enable IP forwarding

• Access to your provider's network firewall, if one is enabled

• A client device with the official WireGuard app or wireguard-tools

Important: Keep your current SSH session open while you change firewall or routing settings. If possible, have your provider's IPMI, KVM or out-of-band console ready in case a rule interrupts remote access.

Step 1: Connect to the Server and Install WireGuard

Connect over SSH:

Update the package index and installed packages:

Install WireGuard, its management tools and the UFW firewall:

The wireguard package provides the kernel module where the system needs it, and wireguard-tools provides the wg and wg-quick commands. The wg-quick utility reads an interface configuration file and handles setup, routing and shutdown.

Confirm the tools are installed:

Step 2: Identify the Server's Public Network Interface

NAT and forwarding rules must name the interface your server uses to reach the internet. Find it with:

Read the value after dev. Example output:

Here the outbound interface is eno1. Yours may be ens3, enp1s0 or another name. Write it down. The examples below use eno1.

Also confirm the public IPv4 address clients will use as the WireGuard endpoint. If your server sits behind provider-level NAT, confirm the public address and UDP port forwarding with your provider.

Step 3: Generate the WireGuard Server Keys

Every WireGuard peer has a private key and a public key. The private key stays secret. The public key is shared with the other peer so the two systems can authenticate each other.

Create the configuration directory with restricted permissions:

Generate the server private key:

Derive the server public key from it:

Display the public key so you can copy it into the client configuration later:

Never share or publish the private key.

Step 4: Enable IPv4 Packet Forwarding

A full-tunnel client uses the server as its internet gateway. The Linux kernel must therefore be allowed to forward packets from the wg0 interface to the public interface.

Create a persistent sysctl file:

Add this line:

Apply the setting and confirm it:

Expected output:

Forwarding only lets the kernel route packets between interfaces. NAT and firewall permissions come next.

Step 5: Configure the UFW Firewall and NAT

The server must accept WireGuard's UDP port and forward traffic from authenticated VPN clients to the internet.

Allow SSH and the WireGuard Port

Allow SSH first so you do not lock yourself out. With the standard SSH port:

If SSH uses a custom port, allow that specific TCP port instead. Do not enable UFW until SSH access is permitted.

Allow WireGuard's UDP port:

Add the NAT (Masquerade) Rule

NAT, also called masquerading, lets devices with private VPN addresses reach the internet through the server's public IP.

Open the UFW rules file:

At the very top of the file, above the existing *filter section, add:

Replace eno1 with the interface you found in Step 2. Keep all existing rules in the file.

Allow Forwarded VPN Traffic

Add a route rule that permits traffic from the VPN subnet to leave through the public interface:

Again, replace eno1 with your interface name. Replies to this traffic are allowed back automatically through connection tracking in UFW's default rules.

Enable UFW, or reload it if it is already running, then review the result:

Firewall caution: UFW setups differ between servers. Check your existing SSH, provider firewall and forwarding policies before applying changes. Your hosting provider's network firewall must also allow inbound UDP on port 51820. If you choose a different WireGuard port, update both firewalls and the client Endpoint to match.

Step 6: Create the WireGuard Server Configuration

Create the interface file:

Add:

Replace SERVER_PRIVATE_KEY with the output of:

Paste only the key value, not the command. Then restrict the file's permissions:

At this stage the file defines the server's VPN address and listening port. You will add the client as a peer once you have its public key.

Step 7: Generate the Client Key Pair

Install the official WireGuard app on the client device, or install wireguard-tools on a Linux client.

On a Linux client, generate the keys locally:

This creates two files:

• client_private.key: the client's secret key. It never leaves the client device.

• client_public.key: the public key you will register on the server.

On Windows, macOS, Android and iOS, the official WireGuard app generates a key pair when you create an empty tunnel. Use that public key on the server.

Show the client's public key on Linux:

Do not send a client's private key to the server. Each device keeps its own private key, and only its public key is registered.

Step 8: Add the Client as a WireGuard Peer

Back on the server, open the configuration again:

Add a [Peer] section below [Interface]:

Replace CLIENT_PUBLIC_KEY with the key from the client. On the server, AllowedIPs acts as a routing and access list for that peer. The /32 mask limits this peer to the single address 10.8.0.2, so it cannot claim the rest of the VPN subnet.

The complete server file now looks like this:

Step 9: Start WireGuard and Enable It at Boot

This starts the VPN interface immediately and makes it start automatically when Ubuntu boots. Check the service and the interface:

You should see the wg0 interface, its listening port and the configured peer. A recent handshake appears once the client connects. If the service fails, read the logs:

Fix any configuration or firewall errors before you continue.

Step 10: Configure the WireGuard Client

Create a new tunnel in the WireGuard app. On Linux, create a file such as wg-client.conf:

Replace the placeholders:

• CLIENT_PRIVATE_KEY: the private key generated on the client

• SERVER_PUBLIC_KEY: the public key from Step 3

• YOUR_SERVER_PUBLIC_IP: your server's public IPv4 address

What the key settings do:

• AllowedIPs = 0.0.0.0/0 routes all of the client's IPv4 traffic through the VPN. For split tunneling, list only the private ranges you want to reach, such as 10.8.0.0/24.

• DNS = 1.1.1.1 makes the client resolve names through the tunnel's configured resolver. Replace it with a resolver you trust.

• PersistentKeepalive = 25 sends a keepalive packet every 25 seconds. It helps clients behind NAT or restrictive firewalls stay reachable, and it is not required on every network.

IPv6 note: This example tunnels IPv4 only. Depending on the client's network and operating system, IPv6 traffic may keep using the local connection and bypass the VPN. For full-tunnel IPv6 protection, configure IPv6 addressing, forwarding, firewall rules and routing on both ends. Do not add ::/0 unless the server is correctly set up to route IPv6.

Connect from a Linux Client

The first command connects and the second disconnects. On Windows, macOS, Android and iOS, import the configuration into the official WireGuard app and switch the tunnel on.

Step 11: Test the WireGuard VPN Connection

Test in stages so you can see where a problem starts.

1. Check the handshake

On the server, run sudo wg show and look for a latest handshake line under the client peer. A recent handshake means both sides exchanged authenticated packets.

2. Ping the VPN server address

From the client:

A reply confirms basic communication over the tunnel, assuming ICMP is allowed.

3. Confirm the public IP changed

With the full tunnel active:

The returned address should be your dedicated server's public IPv4 address, not the client's usual one.

If the handshake works but there is no internet access, review IP forwarding, the NAT rule, the UFW route rule and the provider firewall.

Step 12: Add More Devices and Remove Old Ones

Add a device

Give every device its own key pair and VPN address. For a second client at 10.8.0.3, add another peer to /etc/wireguard/wg0.conf:

Apply the change:

Restarting briefly drops connected clients. To apply the change without disconnecting anyone, run:

Configure the second client with its own private key, the server's public key and its assigned address. Never reuse one client configuration on several devices, because separate identities make access control and revocation possible.

Remove a device

Delete that device's [Peer] block from wg0.conf and apply the change with one of the commands above. Without its public key on the server, the device can no longer connect. For larger deployments, keep a record of device names, VPN addresses, public keys and access status.

Troubleshooting Common WireGuard Problems

The client cannot connect to the server

Check that:

• The server's public IPv4 address and the client's Endpoint port are correct

• UFW allows inbound UDP on port 51820

• Your provider's network firewall also allows that UDP port

• The WireGuard service is running

Useful commands:

There is no recent handshake

A missing handshake usually means the peers are not exchanging WireGuard packets. Verify both public keys, the endpoint address, the UDP port and any firewall between client and server. Make sure the client's private key matches the public key registered on the server.

The handshake works, but there is no internet access

Confirm forwarding is on (sysctl net.ipv4.ip_forward should return 1). Then check that the NAT rule uses the correct outbound interface and VPN subnet, review the UFW route rule, and make sure the provider firewall is not blocking traffic.

The VPN stops working after a reboot

Confirm the service is enabled:

If it is not, run sudo systemctl enable wg-quick@wg0. Also confirm the forwarding setting is in /etc/sysctl.d/99-wireguard-forwarding.conf and the NAT rule is still in /etc/ufw/before.rules.

Some websites or apps do not load

Check DNS, IPv6, MTU and the destination service. Confirm the client uses the intended DNS resolver. If only certain networks or apps fail, inspect routing and firewall rules before changing the MTU. Make one change at a time, test, and keep a note of the original values.

WireGuard VPN Security Best Practices

A working VPN also has to be maintained. These habits reduce unnecessary exposure:

• 1. Protect private keys. Keep them readable only by the account or service that needs them, and never post them in tickets, screenshots or public repositories.

• 2. Use one peer per device. Separate keys and addresses make it simple to revoke a lost or retired device.

• 3. Keep Ubuntu updated. Apply security updates to the operating system and WireGuard packages. Our guide to hardening a Linux dedicated server covers the wider baseline.

• 4. Limit exposed ports. Allow only the services and VPN ports you need, keep SSH protected, and avoid exposing private applications directly to the internet.

• 5. Review peer access regularly. Remove public keys for devices that no longer need the VPN.

• 6. Monitor service health. Watch wg show, systemd status, logs and resource use. A Prometheus and Grafana monitoring setup makes this routine.

• 7. Back up the configuration. Store an encrypted copy of your server configuration and document how to restore it. Treat any backup that contains private keys as highly sensitive.

• 8. Understand the trust boundary. The VPN encrypts traffic between the client and your server only. Traffic leaving the server for its final destination is not automatically end-to-end encrypted, so keep using HTTPS, SSH and other application-level encryption.

How to Choose a Dedicated Server for a WireGuard VPN

The right specification depends on how many clients connect and what they do through the tunnel. Consider:

If you are comparing options, browse the dedicated server plans from KW Servers and match CPU, port speed and location to your expected traffic.

Conclusion

You now have a working self-hosted WireGuard VPN on an Ubuntu 24.04 dedicated server, with server and client key pairs, a private VPN subnet, IPv4 forwarding, UFW and NAT rules, and a client that routes its IPv4 traffic through your own server.

From here you can add devices, create split-tunnel routes for private services, or link separate private networks. Keep each peer's credentials unique, review access regularly and monitor the server so the VPN stays reliable.

If you need a server for a private VPN, remote administration or other network services, explore the dedicated servers available from KW Servers and choose a configuration that fits your traffic and performance needs. For more step-by-step guides, visit the KW Servers tutorials.