How a VPN works, step by step

When you tap connect, a VPN app does four things in order: it asks Android to hand it the phone's network traffic, it agrees on encryption keys with a server, it wraps every packet from every app in encryption and sends it to that server, and the server unwraps the packets and forwards them to the internet under its own address. Replies come back the same way in reverse. Every VPN, on every device, is some version of those four steps.

Step 1: the app takes over the network path

On Android, an app cannot simply intercept other apps' traffic. It has to ask. The first time you connect, the system shows a connection request dialog, and once you approve it Android creates a virtual network interface and routes the phone's packets into it. From that point, when your browser or a messaging app sends data, the packet does not go to the Wi-Fi radio; it goes to the VPN app first.

This is the same mechanism every Android VPN uses, which is why the permission prompt looks identical across apps. It is also why a VPN shows a persistent notification: Android requires it, so that you always know something is holding the network path.

Step 2: the handshake

Before any of your traffic moves, the app and the server need to agree on keys. This exchange is the handshake. The app proves it is a client the server expects, usually with a key or certificate that was issued when the app first set itself up. The server proves it is the real server and not something on the local network pretending to be it. Both sides then derive the secret keys that will encrypt this session and nothing else.

How long this takes depends on the protocol. WireGuard completes its handshake in a single round trip, so on a nearby server the tunnel is ready within tens of milliseconds. Older protocols need several exchanges and take longer, which is one reason modern apps prefer WireGuard.

Step 3: wrapping and sending

Now the tunnel is up, and every packet your phone produces is treated the same way. The original packet, say a request from your browser to a website, is encrypted with the session key and placed inside a new packet addressed to the VPN server. The outer packet is what the Wi-Fi network and your carrier see: a lump of encrypted data going to one address, on one port, over and over.

That wrapping is what people mean by a VPN tunnel. Nothing is physically dug; it is just that every packet's real destination and contents are inside a sealed envelope, and the envelope is addressed to the server.

Step 4: the server unwraps and forwards

The VPN server receives the outer packet, decrypts it with the session key, and finds your original request inside. It then sends that request on to the website, but with one change: the source address is rewritten from your phone's address to the server's own public address. The website answers the server, the server matches the reply to your session, encrypts it and sends it back down the tunnel to your phone.

That public address is the exit IP, and it is why websites see the server's location rather than yours. Because many people share one server at a time, the exit IP identifies the server, not any one person using it.

Where DNS fits in

Before your phone can contact a website it has to look up the site's address, and that DNS lookup is a packet like any other. With the tunnel up, it goes through the tunnel too, and a well-run VPN answers it with a resolver on the server side rather than letting it fall out to the local network's resolver. If the lookup escapes the tunnel, the Wi-Fi owner can see the names of the sites you visit even though the page contents are hidden. That is a DNS leak, and it is the most common way a VPN quietly does less than it appears to.

What happens when the network changes

Phones move. You walk out of Wi-Fi range and onto mobile data, and your phone's address changes. An older VPN protocol treats that as a broken connection and has to redo the handshake from the start. WireGuard and IKEv2 are both built to notice the new address and carry on, so the tunnel survives the switch with at most a brief pause.

What happens when the network fights back

Some Wi-Fi networks, typically in hotels, offices and campuses, filter ports or drop the traffic patterns a VPN produces. The four steps above do not change, but step 3 has to be dressed differently: the app may wrap the tunnel inside TLS on TCP port 443 so it looks like ordinary web traffic, or fall back to a different protocol entirely. A well-built app tries several connection methods in order and keeps the one that works, without asking you to pick.

The parts you never see

Two things happen in the background that make the rest possible. The app keeps the tunnel alive with small periodic packets so that home routers and carrier networks do not forget the connection. And sessions have a lifetime; when one expires the app quietly reconnects. Neither should need your attention, and if a VPN app makes you think about them it is telling you something about its build quality.

Culvert VPN runs these steps with WireGuard first and other methods tried automatically when a network blocks it, shows the exit IP it verified through the tunnel, and is on Google Play.