VPN connected but no internet: nine causes and how to fix each
A VPN that shows connected but passes no traffic has almost always completed its handshake and then failed at routing, DNS or packet size. The tunnel is up; something after it is broken. Work through DNS first, then MTU, then the routing table, because that order finds it fastest.
6 min read
"Connected" in a VPN client means one specific thing: the client and the server finished their handshake and agreed on keys. It does not mean packets are reaching the internet. Almost every case of a connected tunnel with no traffic is a failure in one of the three layers that sit above the handshake — name resolution, packet size, or the routing table — and those three are worth checking in that order because that is roughly the order of how often they are the culprit.
Check whether it is DNS first
The single most common version of this symptom is not "no internet" at all. It
is "no DNS". Type an IP address straight into the browser — 1.1.1.1 works,
so does 9.9.9.9 — and see whether anything answers. If a bare IP loads and a
hostname does not, the tunnel is fine and name resolution is broken.
That happens when the VPN profile sets a resolver that the tunnel cannot
actually reach. A profile that hands the client 10.8.0.1 as its DNS server but
does not route 10.8.0.0/24 into the tunnel produces exactly this: every lookup
goes to an address with no path to it, times out after five seconds, and the
browser reports that the site cannot be found.
The fix is to point the client at a resolver that is reachable through the
tunnel. VPNmine's profiles use 1.1.1.1 and 1.0.0.1 and route 0.0.0.0/0
and ::/0, so the resolver is reachable by definition. If you are using a
hand-written config, either add the resolver's subnet to AllowedIPs or use a
public resolver instead of a tunnel-internal one.
Once traffic flows again, run the DNS leak test to confirm lookups are leaving through the tunnel rather than through your provider.
Check the MTU next
This is the failure that wastes the most time, because it does not look like a
network problem. Small requests work. ping works. Short pages load. Then a
page with images hangs forever, or an SSH session connects and freezes the
moment you run a command that prints more than a screen.
That signature is a path MTU black hole. Every tunnel adds a header, so the largest packet that fits inside it is smaller than the 1500 bytes a normal Ethernet link carries. WireGuard defaults to 1420. When the device sends a 1500-byte packet with the "don't fragment" bit set, a router on the path is supposed to reply with an ICMP "fragmentation needed" message carrying the correct size, which is the mechanism RFC 1191 defines. Plenty of networks drop that ICMP message. The sender never learns, and the large packets vanish silently while the small ones keep arriving.
| Connection type | MTU that usually works |
|---|---|
| Ethernet or Wi-Fi, WireGuard | 1420 |
| PPPoE broadband (most DSL and some fibre) | 1412 |
| Mobile data, when 1420 fails | 1380 |
| Double-tunnelled or unusual carrier paths | 1280 |
Lower the tunnel MTU in the client's settings and retest. 1280 is the floor worth trying, because it is the minimum every IPv6 path must carry, so nothing below it should ever be necessary. If 1280 fixes it, walk the number back up until it breaks again and then drop 20 bytes.
Check that a default route actually exists
A tunnel that carries no default route is up and useless. On desktop, look at the routing table while connected:
# Windows
route print 0.0.0.0
# macOS or Linux
ip route get 1.1.1.1
netstat -rn | head
You want the result to name the VPN interface. If it names your Wi-Fi adapter,
traffic is not entering the tunnel at all, and the usual cause is an
AllowedIPs value narrower than 0.0.0.0/0, ::/0 — a split-tunnel config that
was meant to route one subnet and is now routing nothing you care about.
On Windows there is a second version of this: two adapters both claiming a default route, with the physical one holding the lower metric. Windows then prefers the adapter that is not the tunnel. Setting the VPN adapter's interface metric lower than the physical one resolves it.
Check IPv6
If the tunnel carries IPv4 only and your connection has working IPv6, every dual-stack site is reachable two ways and your device will try the IPv6 address first. That address routes outside the tunnel. Depending on what the client does about it, the connection either leaks or stalls — and if a kill switch is blocking non-tunnel traffic, it stalls.
Two clean fixes: use a tunnel that carries both stacks, which is what
AllowedIPs = 0.0.0.0/0, ::/0 means, or disable IPv6 on the adapter for as long
as you are connected. Disabling IPv6 system-wide as a permanent habit is worth
avoiding; more of the internet depends on it every year.
Check for a captive portal
Hotel, airport, café and campus networks intercept the first HTTP request and redirect it to a sign-in page. A VPN that connects before you have signed in produces a tunnel that is technically up and a network that will not carry its packets anywhere.
Disconnect the VPN, open any plain HTTP page to trigger the portal — http://neverssl.com
exists for this — complete the sign-in, then reconnect. If the client has an
auto-connect or always-on setting, that setting is what put you in this state,
and it needs turning off for the duration.
Check whether the kill switch is doing exactly what you asked
A kill switch blocks traffic outside the tunnel. If the tunnel has a problem the client has not noticed — a stale endpoint, a peer that was rotated, a handshake that succeeded twenty minutes ago and has not been renewed — the kill switch faithfully blocks everything while the client still reports "connected".
Toggling the connection off and on again forces a fresh handshake and clears this. It is the one case where the useless-sounding advice is the actual fix.
Check the clock
WireGuard's handshake includes a TAI64N timestamp and rejects a message whose timestamp is older than the last one it accepted from that peer. That is a replay defence, and it means a device whose clock is badly wrong can complete a handshake once and then fail to renew it. Two minutes of drift is fine; two days is not. Turn automatic time-setting back on.
Check whether the server is the problem
Everything above is on your side. Rule it out in one move: connect to a different server, ideally in a different country. If the second server works, the first one is congested, misconfigured or mid-restart, and nothing you change locally will help.
The five-minute order
- Load a bare IP address. If it loads, fix DNS.
- Drop the MTU to 1280. If pages start finishing, raise it back gradually.
- Confirm the default route names the VPN interface.
- Turn off IPv6 on the adapter and retest.
- Disconnect, complete any captive portal, reconnect.
- Try a second server before changing anything else.
Confirm the fix with what is my IP: the address shown should be the server's, in the country you picked. If it shows your own address, the tunnel is not carrying traffic no matter what the client says.
What this cannot fix
None of the above helps when the underlying connection is down. If the VPN is off and pages still fail, the problem is upstream of everything here and no VPN setting will change it. It also cannot fix a network that blocks the VPN outright, which looks different: the handshake never completes and the client never reaches "connected" in the first place.
