WireGuard Connected but No Internet: Routing Checklist

When you see WireGuard connected but no internet, treat “connected” as an interface state, not proof of an end-to-end path. First prove the ordinary connection, then follow one test destination through route selection, peer selection, forwarding, translation, the return route, and DNS. This order prevents a DNS symptom from hiding a routing fault and prevents random configuration changes.

The complete VPN guide shows the whole connection lifecycle. This checklist stays with the narrower case where a WireGuard interface is up but an internet destination is not usable.

Key Takeaways

• Record one failing destination by IP and by name before changing anything.
• AllowedIPs participates in both route selection and peer selection; it is not merely an access list.［3］
• Separate IPv4, IPv6, and DNS results because each can follow a different path.
• A full-tunnel client also depends on gateway forwarding, NAT or routed return traffic, and firewall state.
• Stop after the first contradicted assumption, make one reversible change, and restore it if the result does not change.

How do you diagnose WireGuard connected but no internet?

An enabled interface proves that the operating system accepted an interface configuration. A recent latest handshake proves more: the two peers recently authenticated each other. Transfer counters prove that some encrypted packets were sent or received. None of those observations alone proves that a particular internet packet selected the intended peer, crossed the gateway, received a reply, and returned to the requesting application.

The wg tool reports configuration and runtime information such as peer public keys, endpoints, allowed IPs, latest handshakes, and transfer totals.［2］ Read those fields as separate evidence. Do not compress them into a single green-or-red connection label.

WireGuard uses cryptokey routing: destination addresses help select a peer for outgoing traffic, while a receiving peer is permitted to claim only addresses assigned to it.［3］ The wg-quick helper may also derive operating-system routes from AllowedIPs, including special handling for a default route.［1］ A route can therefore be absent, shadowed by a more specific route, installed in another table, or associated with the wrong peer even though the interface itself exists.

Observation	What it proves	What remains unproven
Interface is up	Local interface setup completed	Peer authentication and routing
Handshake time advances	The peers authenticated recently	The tested packet follows that peer
TX increases only	Local encrypted packets leave	Remote acceptance, forwarding, and return
RX increases only	The peer can deliver some traffic	The current request selected the right route
TX and RX increase	Encrypted traffic moves both ways	DNS and the final application work
IP works, name fails	At least one IP path works	Resolver selection and DNS reachability

Seven-step routing checklist

Step 1: Freeze a clean baseline

Before touching WireGuard, disconnect or pause the tunnel through its supported control and test the same physical network. Record whether the captive portal is complete, whether one known IPv4 address and one known IPv6 address are reachable, whether DNS resolves a stable name, and whether the system clock is correct. If the ordinary network is already broken, repair or change that network first.

Choose bounded probes. Use a destination you are authorized to test, record its address, protocol, and time, and avoid treating a blocked ping as proof that all traffic fails. A web request, name lookup, and route query answer different questions. A structured VPN connection test explains how to preserve those distinctions.

Capture the original interface configuration, active routes, policy rules, resolver state, and relevant counter values using local administrative tools. Redact private keys, preshared keys, complete configurations, account identifiers, and unrelated browsing data before sharing evidence. The baseline is your rollback reference.

Stop here if the non-tunnel baseline fails or if you are not authorized to inspect or change this device or gateway. Do not compensate for an upstream outage by weakening the tunnel.

Step 2: Verify that the destination enters the tunnel

Ask the operating system which interface, next hop, source address, and routing table it would use for the exact failing destination. Check both the numeric address and, after resolution, every returned address family. Do not infer route selection from an interface icon.

For a full tunnel, the effective routes must cover the intended IPv4 and, when promised by the configuration, IPv6 destinations. For a split tunnel, only the declared private or service prefixes should enter WireGuard. If ordinary internet traffic is intentionally outside the tunnel, “public IP did not change” may be correct rather than broken; the unchanged-IP guide covers that distinction.

Compare the route with AllowedIPs on the selected peer. The dedicated AllowedIPs guide explains prefix overlap and longest-prefix behavior. Here the immediate question is operational: does this one destination select exactly one intended peer, or does a narrower route, another peer, local subnet, policy rule, or exclusion win?

With wg-quick, routes are normally inferred from allowed IPs, while a default route can use policy routing and firewall marks rather than a visibly replaced main-table default.［1］ Inspect the actual platform state instead of assuming that 0.0.0.0/0 must appear in one familiar table.

Stop here when the route points outside the intended tunnel or selects the wrong peer. Correct only that route or peer mapping through the supported configuration, retest once, and revert if the route result remains unchanged.

Step 3: Separate DNS from packet routing

Test the recorded destination by numeric IP. Then query the configured resolver and retry each returned IPv4 and IPv6 address separately. If the numeric request works but the name does not, the encrypted data path is not your first suspect; examine resolver address, reachability, search suffixes, stale caches, and whether the resolver is meant to be inside or outside the tunnel.

A resolver can be reachable over IPv4 while applications prefer an unreachable IPv6 answer. It can also be installed by an interface helper but superseded by per-domain or per-interface resolver policy. Record the resolver actually chosen for the queried name, not just the address written in a configuration file.

Do not “fix” the symptom by publishing an arbitrary public resolver into a managed profile. That may leak queries, break internal names, or violate network policy. Restore the prior resolver after any temporary, authorized comparison.

Step 4: Test IPv4 and IPv6 as different paths

A common half-working state sends IPv4 through WireGuard while IPv6 remains on the physical interface, has no route, or reaches a gateway that does not forward it. The reverse is also possible. Test explicit IPv4 and IPv6 destinations and record route, source address, TX/RX counter changes, and outcome for each.

If the tunnel is intended to cover both families, both need coherent client routes, peer allowed prefixes, server forwarding, firewall policy, and return routing. NAT is common for IPv4 internet gateways but is not a universal requirement; a routed design can work without it when upstream routers know the client prefixes. IPv6 is normally routed, and hiding a missing route behind address translation is not a sound default.

If the service or profile promises only one family, do not invent coverage for the other. Prevent unintended leakage according to the product or administrator's documented policy, and escalate the missing family as a configuration requirement rather than improvising system-wide rules.

Step 5: Verify gateway forwarding and source handling

When the client sends packets into WireGuard and the server receives them, the gateway must still forward them toward the internet. Confirm that forwarding is enabled for the relevant address family and interface direction. Then determine whether the design uses source NAT, a routed client prefix, or another explicit return-path mechanism.

For a NAT design, confirm that the rule matches the actual WireGuard client prefix and intended egress interface. A rule tied to an old interface name, old prefix, or wrong address family can leave the handshake intact while internet replies never find the client. For a routed design, confirm that the upstream router has a route back to the WireGuard client network through the gateway.

Do not add blanket masquerade rules merely because a tutorial used them. They can conceal an intended routed design, affect unrelated traffic, and make later diagnosis harder. Make the smallest authorized change that matches the documented topology.

Step 6: Follow the return path and firewall state

One-way evidence is decisive. If client TX rises but server-side WireGuard RX does not, inspect the outer path, endpoint, and peer mapping rather than gateway NAT. If server WireGuard RX rises but no packet leaves the server's internet interface, inspect forwarding and firewall policy. If a packet leaves but no reply returns, verify the destination, upstream route, translation state, and external filtering. If the reply reaches the server but client RX stays still, inspect the peer's allowed source prefixes, return peer selection, and tunnel firewall.

Stateful firewalls can accept a handshake yet reject forwarded traffic because the traffic traverses a different chain, zone, namespace, or direction. Compare counters on the narrow rules relevant to the recorded probe. Do not disable the whole firewall; a temporary broad allow both changes the risk boundary and destroys evidence about which rule mattered.

Local firewalls also matter. A packet can return through WireGuard and still be rejected before the application receives it. Compare interface counters with an authorized local capture or rule counter, then restore any test rule immediately.

Step 7: Retest one complete path and roll back experiments

After correcting the first proven fault, repeat the same numeric probe, DNS lookup, and application request. Confirm the route and source address again, and compare fresh WireGuard TX/RX deltas rather than lifetime totals. Then test the other address family if it is in scope.

Restore every temporary MTU, route, DNS, firewall, or policy-rule change that did not explain the result. Keep a successful change only when it belongs in the supported persistent configuration and you understand its effect. If larger transfers alone still stall after small probes work, stop this checklist and move to the WireGuard MTU investigation rather than changing routing again.

Can a managed VPN app isolate the fault?

A managed client makes a quick control for the first step of this checklist. Install AethoVPN on the same device, connect with global mode on, and load a known site: if that works while your own WireGuard peer shows connected with no internet, the device's network stack and access network are fine, and the fault sits in your peer's routes, DNS, forwarding, or NAT. If both fail, look at the local network or firewall before touching the peer. The app documents connection states and a global-mode switch, not raw WireGuard profiles, peer tables, or gateway rules, so the deeper steps still belong to whoever runs your server. Download the client for your platform to run that control test.

Summary

• Prove the ordinary network before investigating the tunnel.
• Query the effective route for one exact destination and compare it with peer selection.
• Test names, numeric addresses, IPv4, and IPv6 separately.
• On a gateway, verify forwarding plus either valid translation or a valid routed return path.
• Use per-hop and per-direction counters; never disable broad security controls to obtain a result.
• Retest the same probe and restore every experiment that did not change the evidence.

FAQ

Can WireGuard say connected without a recent handshake?

Yes. Some interfaces or apps use “connected” to mean that the interface and configuration are active. Check the latest-handshake time and fresh transfer deltas separately.

Does 0.0.0.0/0 in AllowedIPs guarantee internet access?

No. It can make a peer eligible for IPv4 destinations and may cause route creation, but forwarding, firewall rules, source handling, the return path, and DNS still have to work.

Why does an IP address work while a website name fails?

That pattern points first to DNS selection or reachability. Check the resolver actually used, every returned address, and per-interface DNS policy before changing tunnel routes.

Why does IPv4 work but IPv6 fail?

The two families use separate routes, allowed prefixes, forwarding controls, firewall rules, and return paths. Verify each family rather than assuming one successful test covers both.

Is NAT always required on the WireGuard server?

No. NAT is one way to provide returnability, especially for private IPv4 client addresses. A routed design works when upstream networks have a correct route back to the client prefix.

Should I disable the firewall to test routing?

No. Use route queries, interface counters, narrow rule counters, and a single authorized temporary rule if necessary. Disabling the firewall expands exposure and removes useful diagnostic detail.

When should I stop changing routes?

Stop when the same probe demonstrably enters the right peer and returns in both directions. If names alone fail, move to DNS; if larger packets alone fail, move to MTU; if authentication is not current, diagnose the handshake.

Disclaimer: This guide provides general technical troubleshooting information. Change routes, forwarding, NAT, and firewall policy only on systems you are authorized to administer, and preserve a rollback path.

Sources:

1. WireGuard Tools, "wg-quick(8)": https://git.zx2c4.com/wireguard-tools/tree/src/man/wg-quick.8
2. WireGuard Tools, "wg(8)": https://git.zx2c4.com/wireguard-tools/tree/src/man/wg.8
3. WireGuard, "WireGuard: Next Generation Kernel Network Tunnel": https://www.wireguard.com/papers/wireguard.pdf

Sources checked 12 September 2026.

---

Related Articles:

• Understand the complete VPN path
• Understand WireGuard AllowedIPs
• Explain why the public IP may not change
• Run a bounded VPN connection test