VPN connected but no internet: what to check

When a VPN says it is connected and nothing loads, the tunnel can be up and carrying nothing, or carrying only part of what you ask for. Your traffic passes through a ForestVPN exit server, the server where it leaves the tunnel for the internet, so a fault can sit on your side, on the path, or at that server. ForestVPN's app tells you which, in a short message, and each message has its own fix.

Go in order. Start with your symptom or the app's message, not with guesses.

Does a connected light mean data is flowing?

No, and that is the whole reason this symptom exists. A handshake is two ends agreeing on keys; it says nothing about whether the packets that follow get through.

For this reason no ForestVPN state means "connected" on its own. The app reaches one of eight verdicts from the tunnel's own counters (the exit reports ExitUnreachable over the path in question), and Working appears only when data flows both ways. Idle, Degraded, BlockedAtHandshake, BlockedAfterHandshake, MtuBlackhole, ExitUnreachable and UnderlayDown are the other seven. The one you are probably seeing is not Working.

Plenty of apps stay green on less. So if yours shows a plain "connected" while the browser spins, you have learned nothing about the path yet.

Which message are you looking at?

Find your symptom or the app's wording in this table, then jump to its section. The wording, the code and the action come from the ForestVPN connection states and the per-message help pages as they stood on the date in the method box below; troubleshooting covers what shows up before a state does.

Is the device online at all?

If the app says "No network", the problem sits before the tunnel. net.underlay_down means the device has no working route, so ForestVPN cannot judge anything further out, and it carries on by itself once the network returns (details).

What if the app keeps trying and gets no answer?

Here the device has a route, so this is not "No network". net.blocked_at_handshake means the app keeps sending connection attempts and the server does not answer (details).

Rule out one mechanism first. Many public hotspots hold traffic back until you finish a sign-in page, the so-called captive portal. Until that page is dealt with, the first packets of a new tunnel are dropped, so the attempts go out and nothing comes back. A firewall in the path can do the same. Open any plain web address in the browser, finish the sign-in page if one appears, then turn the app off and on. If it repeats, try a different network such as mobile data. If the app offers another location, or moves to one by itself, let it.

Why do small pages load while big ones stall?

Because some path between you and the exit server drops large packets without telling anyone. That is net.mtu_blackhole, and the app words it as "Small packets pass, large ones don't." See the details.

The mechanism is old and well documented. A tunnel wraps every packet in an outer header, so the largest packet it can carry inside is smaller than what the link allows. Path MTU discovery relies on routers sending back a "too big" notice; when a router in the path drops that notice, the sender never learns to shrink its packets, and anything large silently disappears. RFC 4821 describes a way to probe for the limit without depending on that notice.

You will recognise it: the page frame loads, images hang, a download starts and freezes, a login works but the next screen never arrives.

The fix is not a new location. The help page for this message says that choosing another location is not the fix (how the app handles it). Try a different network, such as mobile data instead of Wi-Fi. On computers the app may lower its packet size by itself where that is allowed, and it never raises it. Phones and TV only diagnose.

What if it says connected, then nothing is carried?

Turn the app off and on. net.blocked_after_handshake means the start completed and then the network stopped carrying traffic (details).

The help page names three causes: a network change mid-session, a device in the path that lets the first packets through and drops the rest, or a fault on the server. Restarting the connection opens a fresh flow. If the same network repeats it, switch networks.

A close relative is net.liveness_failed: the counters look fine, but a test packet the app sent itself got no answer (details). Same first move, turn it off and on.

If the app offers another location, or moves to one by itself, let it.

When does choosing another location help?

net.exit_unreachable is the message where a new location is the direct fix: your side works and the exit server cannot get out to the internet (details). For the net.blocked_at_handshake and net.blocked_after_handshake messages the app may offer another location itself, and net.mtu_blackhole is the one where a new location never helps.

The softer version is net.degraded. Traffic gets through, with more loss or delay than expected (details). Pick another location; if every location is slow, the network you are on is the common factor, so try mobile data.

Could a local setting be the cause?

Sometimes. Each is worth a minute once the message points at your side.

• DNS. If a site loads by its numeric address but not by name, the name lookup is failing. Check the DNS server your system uses, and try another.
• Kill switch. A kill switch stops traffic leaving outside the tunnel when the tunnel drops, so a stalled tunnel feels like no internet. That is the intended behaviour, with the usual caveat that no kill switch covers every edge case.
• Split tunneling. On Android you pick apps; on Windows and Linux you pick IP ranges; iPhone, iPad and Mac have no split tunneling beyond a local-network carve-out. When only some apps or ranges go through the tunnel, the ones inside stall while the excluded ones keep working, so a stalled tunnel can look like one broken app. Check whether the failing app is inside the tunnel.
• A local firewall rule. Security software on the same computer may refuse the app's traffic. Allow the app, then reconnect.

What if a Free connection simply ended?

Then nothing is broken. The message session.quota_exceeded says "This session used its whole allowance", and the session closed because the allowance for that Free connection was used (details). Connect again if your plan lets you.

How this catalog was read