Culvert VPN

VPN says connected, but there is no internet

A VPN that shows connected with no internet is most often a DNS problem, an MTU problem or a captive portal on the Wi-Fi; here is how to tell which.

Speed, battery and reliability · 5 min read · By Culvert VPN

When a VPN shows connected but nothing loads, the tunnel itself is usually fine; what is broken is something the tunnel depends on. Three causes account for most cases: DNS lookups are not going anywhere, packets are too large for the tunnel to carry (an MTU problem), or the Wi-Fi has a captive portal that has not been accepted. Each has a distinct signature, so a minute of observation tells you which one you have.

Tell the three apart

What you seeMost likely cause
Nothing loads at all, not even by addressCaptive portal, or the tunnel is up but not carrying traffic
Nothing loads by name, but an address worksDNS
Small pages load, larger ones hang partwayMTU
Some apps work, others do notSplit tunnelling or Private DNS conflict
Everything worked, then stopped after some hoursSession expired and the reconnect failed

The second and third rows are the useful tests. Typing an address such as 1.1.1.1 into a browser and getting any response proves the tunnel carries traffic and points at DNS; a site that starts loading and stalls points at MTU.

Captive portals

Hotel, airport, campus and café Wi-Fi often intercept all traffic until you have accepted a terms page in a browser. The VPN app can reach the network, so it reports connected, but its packets are being swallowed by the portal along with everything else. The fix is ordinary: disconnect the VPN, open a browser, let the portal page appear, accept it, then reconnect. A good app detects the portal and tells you, rather than sitting on connected. Why the VPN won't connect until you accept the Wi-Fi terms covers the mechanics.

DNS

Every site name has to be turned into an address before anything loads. With a VPN, that lookup should go through the tunnel to the VPN's own resolver. If it does not, because the app failed to install the resolver, a previous VPN app left a stale setting behind, or Android's Private DNS is pointed at a server the tunnel cannot reach, then names stop resolving while the tunnel itself is healthy.

Check Android's Private DNS setting first. If it names a specific provider, set it to automatic and try again; the interaction between Private DNS and a VPN is covered in VPN and Android Private DNS. Then disconnect and reconnect the VPN so it reinstalls its resolver. If a second VPN or a DNS-filtering app is installed, it is very likely the cause, because only one can own the phone's DNS at a time.

MTU

Packets have a maximum size, and a VPN's packets have to be a little smaller than the network's, because the encryption adds a header. If the tunnel's packet size is set too large for the path, big packets are silently dropped, while small ones get through. The result is uncanny: messages send, small pages load, and then a large image or a login response hangs forever.

This is common on mobile networks with unusual limits and on any tunnel that itself runs inside another tunnel. A TLS-wrapped transport on TCP, which apps use on networks that block UDP, uses a conservative 1280-byte MTU for exactly this reason. If you can switch networks, doing so is the quickest test; if the same site loads on mobile data and hangs on Wi-Fi with the VPN, or the reverse, MTU is the cause. MTU and VPNs explains why and what a well-built app does about it.

Split tunnelling and app-specific failures

If only certain apps fail, check whether the VPN has a split-tunnelling list. An app excluded from the tunnel uses the plain network, and on a captive-portal Wi-Fi that means it is stuck while everything through the tunnel works, or the other way round. Banking apps sometimes refuse to work through any VPN and are worth excluding. The split-tunnelling explainer covers how the exclude list behaves.

The tunnel is up but carrying nothing

Occasionally the handshake completes and the app truthfully reports connected, but the network then drops the tunnel's packets. This happens on restrictive Wi-Fi that allows a connection to start and then filters it, and on a server that has just been taken out of service. Nothing loads, by name or by address.

A good app does not take connected on trust. It sends a request through the tunnel to its own server asking what address the request arrived from; a reply proves the tunnel carries traffic and gives the exit IP, and no reply means the tunnel is not really working, whatever the status says. The app should then try another connection method or another server rather than leave you staring at a green tick. How to check your VPN is working goes through this check.

A short sequence to run

  1. Try an address such as 1.1.1.1 in a browser. Any response means the tunnel carries traffic.
  2. If nothing responds and you are on public Wi-Fi, disconnect the VPN and look for a captive portal page.
  3. If addresses work but names do not, set Private DNS to automatic and reconnect the VPN.
  4. If pages load partway and hang, switch between Wi-Fi and mobile data to see whether the network's packet size is the problem.
  5. If one app fails while others work, check the split-tunnelling list.
  6. If none of that helps, connect to a different city.

Culvert VPN verifies every connection by asking its own server what address it saw through the tunnel, shows that exit IP on the connect screen, runs its own resolver through the tunnel, and treats a tunnel that cannot answer as not connected; it is free on Google Play.

Questions people also ask

Why do some sites load and others hang with the VPN on?

That is the signature of an MTU problem. Small pages fit through; large responses need packets that are too big for the tunnel and get dropped. Everything else looks connected because it is.

Why does the VPN show connected but nothing loads on hotel Wi-Fi?

The Wi-Fi has a captive portal you have not accepted yet, and it is holding all traffic until you do. Disconnect the VPN, open a browser to reach the portal page, accept the terms, then reconnect.

Should the app know when the tunnel is not really working?

Yes. A well-built app checks that traffic actually goes through the tunnel by asking its own server what address it saw, and treats a tunnel that cannot answer as not working rather than trusting the connected state.