VPN not connecting: find the stage that failed

When ForestVPN will not connect, the attempt stopped at one specific step, and the app says which. Most advice for this problem is a flat list of generic fixes: switch server, switch protocol, reinstall. Those work by luck. This page follows the order the connection happens, and the message in the app decides where you start.

Which stage did the connection stop at?

Every message has a short code. cp. codes are about ForestVPN's service, net. codes are the tunnel's own verdict, and ne. codes are the device starting the tunnel; each code has its own help page. Look at the words on the screen, then find them in one of the five tables below: one for each of the four stages and one for the device branch. The wording, codes and actions come from ForestVPN's per-message help pages, which each table row links, as they stood on the date in the method box at the end.

A connection passes through four stages, in order, and the next section walks through them. If the device will not let the app build a tunnel at all, you never get that far. That is the device branch, a fifth place to fail.

What does the app do between tapping Connect and Working?

The app talks to ForestVPN's service, the service has the exit server install the session, and then the app does the handshake with that server. A failure belongs to whichever step did not finish.

First, ForestVPN's service. It hands the app a ticket: a short-lived credential for one session, signed over a value the signer never sees, so the ticket presented later cannot be traced back to the request that minted it (how the number works). Second, the exit server, the machine where your traffic leaves the tunnel for the internet. The service has it install a session for that ticket; if the server accepts the request but never confirms the install, the app says so (cp.install_not_acked below). Third, the handshake, the first exchange of keys, which your device does with that same exit server.

ForestVPN uses the standard Noise_IKpsk2 handshake, the handshake pattern WireGuard uses, and does not alter it (how it compares with WireGuard). So there is no protocol setting to flip when it fails. What failed is the path, the ticket or the device.

One more thing: no ForestVPN state means "connected" on its own. The app shows Working only when data flows both ways, so a spinner that never reaches Working is a stage that did not finish.

What does Can't reach ForestVPN mean?

It means the first stage failed: the app asked ForestVPN's service for something and nothing answered, so it never got a ticket. Look at the network between the device and ForestVPN's service first; the tunnel does not exist yet.

The plain one is cp.unreachable. Check the device is online, open any web address, and give the app a moment: it retries with growing pauses. A hotspot that holds traffic until you finish its sign-in page produces exactly this, so complete that page first.

Narrower is cp.dns_blocked. The app turns server names into addresses with a DNS lookup, the same step a browser uses. When this network refuses or hides that lookup for ForestVPN's names, nothing else can start. The catalog's advice is a different network, and it says plainly that a backup route does not help with this one.

What do Session expired, Not authorized and Out of date mean?

They mean ForestVPN's service answered but the app got no session, because something about the ticket or the location went wrong. The first table covers the ticket, the second the install. These two stages have the most messages and the friendliest fixes, since most mean "ask again".

Group them by what you do next. The ticket messages (cp.ticket_invalid, cp.ticket_expired, cp.ticket_in_use) are all fixed the same way: tap Connect again and the app mints a new ticket. cp.unauthorized is the same move, with one extra step the app takes for you, registering the device again if it has to. That message can show up, for example after a restore from a backup, when the device's identity and the service's record no longer match.

The two update messages are different. cp.epoch_unknown and cp.client_too_old do not clear on retry. ForestVPN rotates its signing keys and retires old builds, so an old build gets refused until it is updated. Update first, then connect.

Three of these belong to the location, not to you; they get their own section below.

Why is the server not answering the connection attempts?

Because something between you and the exit server drops the handshake packets, after the ticket worked and the server installed your session. The app is sending handshake attempts and no reply comes back. The app words it as "We're sending connection attempts and the server isn't answering", code net.blocked_at_handshake.

Something between you and the server drops the first packets, so the attempts go out and nothing returns. The help page lists three reasons: a sign-in page on a hotspot that you have not completed, a firewall, and a network that does not carry this connection. The action is the same for all of them: turn the app off and on, which opens a fresh attempt. If it repeats on the same network, switch to another one, such as mobile data.

This is the message where the usual advice is wrong. Choosing another location is not the fix, and the catalog says so in as many words.

Rule out "No network" first: net.underlay_down means the device has no working route, so nothing further out can be judged. It carries on by itself when the network returns.

What does Couldn't start the tunnel mean?

It means the device would not let the app build the tunnel, and this branch has nothing to do with the network. The operating system, or ForestVPN's own helper on the computer, refused, so no tunnel packet was sent. If you see "Couldn't start the tunnel" on a good network, it is this branch.

Two things can sit behind ne.no_tun_fd, per its help page: the system was busy, or it was still installing an app update over a running tunnel. Try again. A rejected setting (ne.settings_rejected) may mean another app, such as a second VPN that is still on, or a system policy holds the network settings.

ne.permission_denied is the one that does not take retries. It appears when the app is started from a session the system does not count as interactive, such as an SSH login or a service account. Run it from the desktop you are logged in to. On Linux, run it locally with sudo.

The adapter and service messages exist only on Windows and Linux, where a virtual adapter and a background service do the work. On a phone you will not see them.

If three tries do not clear a "Couldn't..." message, stop retrying and use Report a problem in the app, as the ne.no_tun_fd help page says: try again, up to three times, then report it.

Should I switch location or restart the connection?

Only when the location itself cannot take a session. cp.node_unavailable and cp.no_candidate are the two messages built for that: the server in that location is busy, under maintenance, or unable to take a connection. Most locations have one server, so when it refuses, the whole location is out until it recovers. Pick another, or try again in a few minutes. cp.install_not_acked is the near neighbour: the server accepted the request and never confirmed, and the catalog offers a retry or another location.

It is not the fix for net.blocked_at_handshake, where the action is to turn the app off and on. It does not help for any ne.* message, since the failure is on your device before any tunnel packet is sent. And it does not help for cp.dns_blocked, where the name lookup fails for every location on that network.

Short version: switch location when the message names the location, restart the connection when the server is silent, change network when the lookup or the path fails, and leave the location alone when the device will not start.

What if the day's Free connections are used?

Nothing is broken. cp.quota_exceeded says "Daily connection limit reached", and on the Free plan each connect uses one of your connections for the day. They come back one at a time through the day, and the app names the time the next one returns. Connections are limited per day so the service stays fair for everyone. This is separate from the data allowance, which is a different counter: see VPN data limit reached for which limit stopped you, and the data allowance page.

On a paid plan the same code reads "Too many connections", meaning many connects in a short period, and the wait is a few minutes.

What if the handshake works and then pages fail?

Once the handshake succeeds, a connection can still stop carrying traffic or carry it badly, and the app then names the problem with one of these messages: net.blocked_after_handshake, net.liveness_failed, net.mtu_blackhole, net.exit_unreachable and net.degraded. They are laid out, with the one action each, in VPN connected but no internet. One of them, the stall where small pages load and large ones hang, is the old path MTU problem, and it has its own section there.

If the tunnel never finished, check the kill switch. It stops traffic leaving outside the tunnel when the tunnel drops, so a tunnel that never finished can feel like no internet at all. That is the intended behaviour, though no kill switch covers every edge case.

A lost sign-in number is covered on the account number page, and the devices page covers moving between devices.

How this catalog was read