WireGuard Connected but No Internet: A Layer-by-Layer Troubleshooting Guide
Diagnose WireGuard connectivity in packet order: interface, handshake, AllowedIPs, return routing, forwarding, NAT, firewall, and DNS.
4 分钟阅读
When WireGuard appears connected but cannot reach an internal service or the public internet, the cryptography is rarely the problem. One layer among handshake, routing, forwarding, NAT, firewall, and DNS is incomplete. The fastest diagnosis follows the packet path and proves each layer in order.
This guide assumes the tunnel has already been configured. Start with our Ubuntu WireGuard setup guide if it has not, then use the hardening guide for key rotation and DNS-leak controls.
Layer one: does the interface exist?
sudo wg show ip address show wg0 ip link show wg0
Confirm that the interface is up, the address is correct, and the private key was not accidentally replaced. Never expose a private key in a ticket or screenshot. If the interface is missing, inspect systemctl status wg-quick@wg0 and the startup log. There is no reason to investigate DNS yet.
Layer two: is there a recent handshake?
The latest-handshake field in wg show is the first decision point. With no handshake, check the endpoint, UDP port, server security group or firewall, and matching public keys. For a client behind NAT that must remain reachable after idle periods, WireGuard documents PersistentKeepalive; do not enable it without that need.
If a handshake exists but transfer counters grow in only one direction, the encrypted tunnel exists and the return route or firewall is more likely at fault. Capture on both the public interface and wg0 to see where packets stop:
sudo tcpdump -ni any udp port 51820 sudo tcpdump -ni wg0 host 10.0.0.2
Layer three: AllowedIPs is both routing and access control
WireGuard describes AllowedIPs as a cryptokey routing table. On transmit, it selects the peer for a destination. On receive, it restricts the source addresses that peer may claim. A split tunnel should list the internal networks it needs. A full tunnel commonly includes 0.0.0.0/0; IPv6 requires an explicit decision about ::/0. Overlapping ranges can cause longest-prefix routing to choose an unexpected peer.
ip route get 10.0.0.1 ip route get 1.1.1.1 ip -6 route get 2606:4700:4700::1111
Layer four: can the server forward?
A successful handshake means the peers authenticated; it does not make the server a router. A Linux gateway needs the appropriate IPv4 or IPv6 forwarding setting and a FORWARD policy that permits traffic between wg0 and the egress interface. Public-internet access generally needs correct SNAT or masquerading. For an internal network that already knows the WireGuard subnet, an explicit return route is usually more transparent than NAT.
sysctl net.ipv4.ip_forward sudo nft list ruleset sudo iptables -S FORWARD sudo iptables -t nat -S
Do not paste a random command that flushes the firewall. Read the rules and counters first, test the smallest temporary change, and only then persist a verified configuration through the system’s firewall manager.
Layer five: investigate DNS last
Enter the DNS branch only when a direct IP request works but a hostname fails. Inspect the resolver the operating system is actually using, not merely the intended configuration. On Ubuntu with systemd-resolved, resolvectl status shows DNS servers and routing domains per interface. A common split-tunnel failure sends internal names to corporate DNS correctly but unintentionally forces every public query there as well.
The shortest diagnostic path
- No interface: fix the wg-quick service or configuration.
- No handshake: check endpoint, UDP reachability, keys, and ingress firewall.
- Handshake but no bidirectional transfer: inspect AllowedIPs, return routing, and FORWARD.
- Tunnel address works but internet does not: inspect forwarding and NAT.
- IP works but hostname does not: inspect resolver and split DNS.
- Intermittent failure: observe MTU, NAT idle timeout, roaming, and keepalive before reinstalling.