How ForestVPN works

The short version

• Your traffic is sealed on your device and comes out of a server we run, the exit. Of ForestVPN's parts, the exit is the only one that sees where your traffic goes.
• Before you connect, your device gets a signed ticket. The ticket says which plan you have, and the service that checks it works separately from the one that holds your account.
• The app watches whether data really flows and switches road by itself when it stops. You only see the result.
• One row ties your device, and any linked account, to each session it pays for, for metering. It is deleted an hour after the session settles, or up to 17 days later for a ticket never used. This page shows it next to everything else.

What a VPN changes, and what it does not

A VPN is a transfer of trust. Without one, you trust your network and your internet provider with a view of where your traffic goes. With one, you trust the VPN instead. So the useful questions are the same for any VPN: where does your traffic end, what do the services in front of it know, and what does the app do on your device? This page answers them in that order, with the specifics behind each answer.

Without a VPN, your Wi-Fi and your internet provider can see which servers your device talks to, and every site you reach sees the address your network gave you. With ForestVPN they see encrypted traffic to our servers instead. That server, the exit, is where your traffic comes out onto the internet.

That moves trust; it does not remove it. The exit sees the sites you visit and the address you connected from, and the sites you visit see the exit's address instead of yours. A VPN does not make you anonymous: it changes who can see your traffic.

What a VPN does not touch is everything that happens after the exit. The sites you sign in to still know the account you sign in with, and a site that tracks you with cookies still does. The tunnel protects the road, not the destination.

What happens when you tap Connect

You tap Connect. Your device asks for permission to use a server, shows a ticket that carries two facts, (which plan's key signed it and which fortnight that key belongs to), gets pointed to a server, and builds an encrypted tunnel to it. Then it checks that data really flows both ways before it says you are protected.

The ticket is the interesting part. Hours earlier, in a separate request, your device asks our sign-in service for tickets. The service signs each one blind: the signature is made over a value it never sees, so the signature on the ticket you present later does not point back to the request that created it. The one exception is the metering row described below, which ties your device to each session it pays for.

Notice what happens before a single byte of yours moves. Permission comes first: the ticket, checked in a fraction of a second. Placement comes second: a signed server list, which your device verifies itself, and a session service that picks the exit. Proof comes last: the app does not say you are protected when the handshake finishes, but when test packets have gone through the tunnel and come back.

Two details are worth knowing. Tickets are refilled on the underlying network, never through an exit, so the sign-in service is never reached through the tunnel it helps to build. And the app can reach our services by several routes and uses the first that answers, so a poor path to one of them need not stop you from connecting.

Inside the tunnel

Everything you send is sealed on your device with keys that only your device and the exit know. If your network changes, the same tunnel carries on.

Read the figure from the outside in. Your network sees only the outer datagram: a packet of encrypted bytes going to one of our servers, whose first bytes are masked and whose size varies. Inside it, the sealed frame can be opened only with keys made in the handshake, which only your device and the exit hold. Inside the frame is your own packet, exactly as your app sent it.

The tunnel protocol is called Quantum. Its handshake is Noise_IKpsk2, unmodified, with X25519, ChaCha20-Poly1305 and BLAKE2s. We left it alone on purpose: the published analysis of that handshake still applies to it. What we added sits around it. Packet sizes and header bytes vary on every connection, and the tunnel copes with roaming and with the path changing under it.

The tunnel belongs to the session, not to the network you happen to be on. When you walk from Wi-Fi onto cellular, the session key stays the same and the packets simply start arriving from a new address, so the same tunnel carries on. We do not promise that nothing drops: a switch can take a moment, and the status screen shows what state you are in.

Your traffic ends on servers we run, not on a cloud function. A cloud service cannot carry a tunnel, so the services that hand out tickets and server lists never carry a packet of yours.

One tunnel, many roads

If one path to the server is slow or stops carrying data, ForestVPN tries another by itself and keeps whichever actually carries data. You do not have to pick.

Why more than one road? Networks differ. Some carry UDP well and some handle it poorly, and a network that is fine for hours can change. A fixed choice is wrong somewhere, so the app measures instead. For each network it has connected from, it keeps a small note on your device, filed under a hashed name, saying whether the backup route was needed there. It only reaches for the backup route on a network where connecting directly has failed, now or within the last day. On Free the backup route comes with a monthly allowance, and Premium includes more.

We call a path a road: a way of carrying the same encrypted packets to the same exit. The app always dials the direct road first, over UDP, and on a healthy network nothing else is contacted. If the direct road stops carrying data, the app also tries the other roads it has, inside the same session: TCP, sometimes an extra server of ours chosen automatically, and the backup route, which carries the same packets as ordinary web traffic through a content delivery network. The backup route is a fallback, not a faster road, and it is metered because it costs more.

Changing road does not change the session: the ticket, the keys and the exit stay the same.

The app decides by data, not by handshakes. A road counts as healthy only while it delivers, and the status screen shows Working only once data is flowing both ways.

More on the connection status and the backup route.

Smart routes

Smart chooses a route that suits your network, keeps measuring it while you use it, and moves to a better one on its own when one appears. A location you choose yourself stays where you put it.

A road is one way to carry your packets to the exit: direct, TCP, through an extra server of ours or the backup route. Smart compares the roads on offer for the place you asked for and moves between them inside the session you already have, with no new ticket and no new handshake.

Three things Smart does not do. It does not move a location you chose yourself. It does not promise a faster connection: it promises that it keeps checking, and that it moves only when another route is better for your network. And it does not need you: there is nothing to turn on and nothing to pick, although the Network-aware routing setting turns these decisions off if you prefer.

Smart routes is on Windows, Linux, the Mac app from our website, the command line and OpenWrt routers today. iPhone, iPad, Apple TV, Android and the Mac App Store version get it with an app update.

Two programs, one signed ticket

Why split the work at all? Because the two jobs need different knowledge. Checking that you have a plan needs to know your device. Choosing and opening a session needs to know a place and an address. If one program did both, it would hold both kinds of knowledge together. So they are two programs, deployed apart. The ticket passes between them at connect, and the data a session used passes back when it settles, so it can be charged: that is the metering row described next.

The part that knows your device and plan and the part that knows your server are separate programs. The session service is deployed without any binding to our account database, and the ticket between them is signed blind. One row ties your device, and any linked account, to each session it pays for, to meter data and to cut off a revoked device. It is deleted an hour after the session settles, or up to 17 days later for a ticket that was never used.

The sign-in service holds your account, your devices and your plan, and sees the address each ticket request comes from. It never learns which exit you were given or anywhere you went. The session service sees the address you connect from, the location you chose and a one-time session key. Its session record deletes itself when the session expires, and your source address is never written into it.

The grid lists what each part is handed at connect time, which is not the same as a promise about what could be worked out by combining records. That is why the metering row is stated in words and drawn in the figure rather than left off.

What we keep, and for how long

There is no column anywhere in our systems for the sites you visit or the names you look up. Which exit a session used is erased when the session ends. Payment is handled by the App Store, Google Play or the processor you choose, and we never see a card number.

The main records and how long each lives, in one picture; the privacy policy lists every one. Route reports, which help us choose better routes for everyone on a network, are aggregates with no device, account, session or exit in them, published only for days with at least 10 devices.

Two more things belong in the same picture. The app contains no analytics SDK, no attribution SDK and no advertising identifier. And if you choose to send a diagnostic report, it shows you its contents first, uploads without your device's identity at a random time in the following hour, never through the connection it describes, and is deleted after 72 hours.

Every record is listed in the privacy policy, and the short version is on the security page.

Your devices, routers and TVs

One account number works on up to ten devices. Devices on your account can reach each other by name, and a computer that stays at home can be an exit for the others. An iPhone can use an exit but cannot be one yet. Routers cover the devices that cannot run an app, and TVs and routers sign in without a keyboard.

If the home exit you are using goes offline, the app moves you to another of your own exits and tells you. If every one of your exits fails, traffic stays blocked and the app asks you to tap.

Routers are for the devices that cannot run an app, such as a games console or a smart TV. Put ForestVPN on the router and everything behind it, or only the devices and apps you choose, goes through the tunnel. The router's processor is the speed limit, so the router page says what we measured and on which hardware. A router links to your account with a code it prints for you, and TVs sign in without a keyboard.

What this design does not do

None of this makes the design airtight, and we would rather say where it stops than let a diagram suggest otherwise. These are the main ones; the privacy policy lists every one.