Setting up a VPN can sometimes be tricky. A single typo in a key or a forgotten firewall rule can prevent it from working. This guide is designed to walk you through the most frequent issues step-by-step. The most important tool is the wg show command, which you should run on your server to get the status of your connections.

sudo wg show

Problem: No Handshake

You've activated the VPN on your client, but the connection doesn't work. When you run sudo wg show on the server, you see your client peer, but the latest handshake value is (none). This means the client and server are not successfully communicating.

1. Check Your Keys

This is the #1 cause of handshake failures. A single incorrect character in a key will break the connection.

2. Check the Endpoint and Port

In your client's configuration file, verify the Endpoint line.

[Peer]
PublicKey = ...
Endpoint = 123.45.67.89:51820 # <-- Is this correct?
...

3. Check Your Firewalls (Server and Cloud)

A firewall is likely blocking the WireGuard traffic. Remember to check both the firewall on the server itself (like UFW) and your cloud provider's firewall (like DigitalOcean Cloud Firewall or AWS Security Groups).

You can test if the port is reachable from another machine (not on the VPN) using nc:

nc -uzv YOUR_SERVER_PUBLIC_IP 51820

A "succeeded!" message means the port is open. A "timeout" message means a firewall is blocking it.

Problem: Handshake OK, But No Internet

The good news: your client and server are talking! sudo wg show shows a recent handshake. However, when you try to browse the web on your client, nothing loads.

1. Check IP Forwarding

Your server needs to be configured to forward traffic from the VPN interface to the internet. Run this command on your server:

cat /proc/sys/net/ipv4/ip_forward

The output must be 1. If it's 0, forwarding is disabled. You need to enable it in /etc/sysctl.conf and apply it with sudo sysctl -p.

2. Check Firewall NAT Rules

Your firewall needs a POSTROUTING rule to "masquerade" or NAT the traffic from your VPN clients. Check your iptables rules:

sudo iptables -t nat -S

You must see a line that looks similar to this. eth0 might be different on your server (e.g., ens3).

-A POSTROUTING -o eth0 -j MASQUERADE

If this line is missing, you need to add it back to your WireGuard PostUp configuration.

3. Check DNS Settings

Your client might be connected but unable to resolve domain names. Make sure you have a DNS entry in the [Interface] section of your client's configuration file.

[Interface]
PrivateKey = ...
Address = 10.0.0.2/32
DNS = 1.1.1.1 # <-- Make sure this line exists!

Problem: Cloud Provider-Specific Issues

Sometimes, the issue isn't with WireGuard itself, but with the specific configuration of your cloud provider.

DigitalOcean

The most common issue on DigitalOcean is forgetting about the two layers of firewalls. You must add your WireGuard UDP port rule to the Cloud Firewall in the DigitalOcean dashboard, which filters traffic before it even reaches your Droplet.

Amazon Web Services (AWS)

Your EC2 instance's Security Group acts as its firewall. You must add an "Inbound Rule" to allow "Custom UDP" traffic on your WireGuard port. Also, consider assigning an Elastic IP to your instance so its public IP address doesn't change if you reboot it.

Microsoft Azure

Azure uses Network Security Groups (NSGs). You must create an "Inbound security rule" to allow UDP traffic on your WireGuard port. It's crucial to give this rule a high priority (a low number like 100) to make sure it's processed before Azure's default "deny all" rule.

Conclusion

Troubleshooting is a process of elimination. Go through each step carefully. The vast majority of issues come down to a typo in a configuration file or a firewall rule. You can do it!