WireGuard Not Connecting? 12 Fixes That Actually Work

New country, open laptop, tunnel won't connect. I've been the person staring at that screen in a hotel lobby, and I can tell you: WireGuard failures are almost always one of a dozen familiar causes. Here's the WireGuard not connecting fix playbook, ordered the way I'd actually troubleshoot it: quick triage first, then the checklist from most to least likely.

Triage: client, server, or network?

Three quick tests narrow it down before you touch any config:

Test 1: does it work on the home LAN? Connect a client while on home WiFi, using the server's LAN IP as the endpoint. If the tunnel comes up, your server and keys are fine; the problem is reachability from the internet (port forwarding, DDNS, CGNAT, or the remote network blocking you).

Test 2: switch networks on the client. Try mobile data instead of hotel WiFi. If it connects on mobile, the hotel network is filtering VPN traffic, and no amount of server-side tweaking will help. You need a fallback protocol, not a fix.

Test 3: did it ever work? Something that stopped working points at changed IPs, dead DDNS, a server that rebooted without auto-starting, or an ISP change. Something that never worked points at config errors. Different history, different suspects.

The 12 fixes, in likelihood order

1. Swapped or mistyped keys. The classic. The server's peer entry must hold the client's public key; the client's peer entry must hold the server's public key. One wrong character and the handshake dies silently. When in doubt, regenerate both and re-paste carefully.

2. Wrong endpoint. Check the client's Endpoint line: hostname spelled right? Port matches the server's listen port and the forwarded port? Does the DDNS hostname currently resolve to your actual home IP? Stale DDNS is the "worked yesterday" culprit more often than anything else.

3. The server isn't running. Power cut? Update reboot? Check whether the WireGuard interface is up, and whether it's set to start on boot. Then actually test a reboot, because "should start on boot" and "starts on boot" are different things.

4. Port forwarding broke. The rule must forward UDP (not TCP) to the server's current LAN IP. If the server's LAN address drifted because you never set a static DHCP lease, the forward points at thin air. Set the reservation.

5. A firewall eats the packets. The server's own firewall (ufw, firewalld, iptables) must allow the WireGuard UDP port inbound. On the client side, hotel and corporate networks sometimes block UDP wholesale.

6. CGNAT appeared. Some ISPs quietly move residential customers behind carrier-grade NAT. Symptom: everything configured correctly, worked before, now nothing connects, and your router's WAN IP is in 100.64.0.0/10. Fix: Tailscale or another NAT-traversal design.

7. Wrong AllowedIPs on the client. A typo here produces "connected but nothing loads," which feels like a connection failure but is really routing. For full-tunnel, it should be 0.0.0.0/0.

8. MTU too big. Handshake completes but traffic stalls, big pages fail, small ones work? Lower the tunnel MTU (try 1280) and retest.

9. Clock skew. WireGuard handshakes are time-sensitive. A router that lost power and came back with a wrong clock and no NTP will fail handshakes mysteriously. Make sure NTP is enabled on both ends.

10. Address collision. If your tunnel subnet overlaps the local LAN you're visiting (both using 10.0.0.x, say), routing breaks in confusing ways. Use an uncommon tunnel range like 10.66.x.x.

11. Another VPN fighting it. Corporate security agents, other VPN clients, even browser "VPN" extensions can hijack routes and DNS. Disable everything else while testing.

12. Stale profile on the travel router. Changed server keys or ports? Every client profile must be re-exported and re-imported. Delete and re-import on the router rather than editing in place; cached profiles lie.

Reading the logs (they're terse but honest)

WireGuard doesn't chat, but sudo wg show on the server tells you plenty. Find your peer: if "latest handshake" never updates, packets aren't completing the round trip (network/firewall/CGNAT territory, fixes 4-6). If handshakes succeed but the transfer counters sit at zero, it's routing or crypto mismatch (fixes 1, 7, 10).

On the client, the WireGuard app log repeating "sending handshake initiation" with no reply means the same thing: your packets aren't reaching the server, or replies can't get back. On GL.iNet routers, the VPN status page plus the system log show the same story.

Memorize this: no handshake = reachability problem; handshake fine but no traffic = routing problem. That one distinction cuts troubleshooting time in half.

Quick questions

Need a second pair of eyes?

Our VPN audit is built for this: we diagnose the failure, harden the config, and set up tested fallback protocols so your next trip doesn't start with troubleshooting. https://homeipvpn.com.