The 3-second version
Your device encrypts each outgoing packet. The encrypted packets travel to the VPN server. The server decrypts them and forwards them to the public internet. Replies come back the same way in reverse. The websites you visit see the VPN server's IP, not yours. Your ISP sees encrypted noise going to one server, not the actual destinations.
Now the longer version.
Step 1: Connection setup (handshake)
When you tap "connect" in the VPN app, your device and the VPN server perform a cryptographic handshake to agree on a shared session key. This is the only step where they negotiate what encryption to use. The handshake usually takes 50-100ms.
For WireGuard (our default), the handshake uses Curve25519 elliptic-curve Diffie-Hellman, with BLAKE2s for hashing. The output is a shared symmetric key that only your device and the server know. Forward secrecy is built in: each new session generates a new key, so even if a future attacker recovers today's session key, they can't decrypt past sessions.
Both your phone and the server end up holding the same secret value, derived via math that doesn't require sending the value over the wire. The math (ECDH) is what makes this possible. After the handshake, both sides can encrypt and decrypt using this shared key.
Step 2: Packet encryption
Every IP packet leaving your device is intercepted by the VPN app before it reaches your network interface. The app:
- Takes the original packet (e.g., "GET / HTTP/1.1 to example.com").
- Encrypts it using the shared session key + a counter (to prevent replay attacks) — ChaCha20-Poly1305 in WireGuard.
- Wraps the encrypted payload in a new outer packet addressed to the VPN server's public IP, not the original destination.
From your device's perspective, you're now sending a stream of "VPN packets" to a single IP — the VPN server. The original destination is hidden inside the encrypted payload.
Step 3: Tunneling — the wire
The encrypted packets traverse your local network (WiFi or cellular), cross your ISP's infrastructure, and reach the VPN server. Anyone observing this traffic in the middle (your router, your ISP, the cafe WiFi, a passive observer on the coffee shop network) sees:
- Source IP: your device's real IP (your home connection's public IP, or your cellular IP).
- Destination IP: the VPN server.
- Payload: encrypted bytes that look like random noise.
That's it. They can see that you're talking to a VPN server, but not what you're sending or what website you eventually want to reach.
Step 4: Exit at the VPN server
The VPN server receives your encrypted packet, decrypts it using the shared key, and finds the original packet inside. It now needs to forward this packet to the actual destination (example.com).
The server replaces the source IP on the packet with its own IP (this is called Network Address Translation, NAT). It forwards the packet to the public internet. From example.com's perspective, the connection is coming from the VPN server's IP, not from you.
Step 5: Reply path (reverse)
Example.com sends a response. It goes to the VPN server's IP (which is the only address it knows). The VPN server has a NAT table tracking which of its connections belongs to which VPN client. It finds your session, re-encrypts the response using your shared key, and forwards it to your device. Your device decrypts it and hands the original response to your browser.
Your browser sees a normal response to its original request. It has no idea the response was routed through a VPN.
What each party sees
| Observer | Without VPN | With VPN |
|---|---|---|
| Your ISP | Every site you visit + traffic patterns | One encrypted connection to a VPN server |
| Cafe WiFi operator | All your HTTP + DNS queries + destinations | One encrypted stream to one IP |
| The website (e.g. example.com) | Your real IP + ISP + approximate city | VPN server's IP + datacenter location |
| The VPN provider | — | What sites you visit (unless logging is disabled at config level — see our audit) |
| You | Direct internet | Encrypted, slightly slower internet |
What if the tunnel drops?
Networks are unreliable. WiFi handoffs happen, servers restart, cell signal fluctuates. If the VPN tunnel drops mid-session, two things can happen:
- Without a kill switch: your device falls back to sending packets over your regular ISP connection. For a few seconds (until the tunnel reconnects), your real IP and DNS are exposed. This is the leak window most "no-log VPN" marketing doesn't mention.
- With a kill switch (ours, on by default): the OS blocks all non-VPN traffic when the tunnel drops. Apps see "no internet" for ~3-5 seconds while reconnection happens. No leak. Details here.
The role of DNS
DNS (Domain Name System) is how your device converts "example.com" into the IP address it should connect to. A common mistake in VPN implementations: encrypting the actual web traffic but letting DNS queries escape to your ISP's resolver. Your ISP then sees "user looked up youtube.com, facebook.com, hackernews.com" — which is most of what they'd have seen anyway.
ClownVPN pushes DNS through the tunnel by default. Queries go to Cloudflare's 1.1.1.1 via the encrypted tunnel, not to your ISP's resolver. The tool at /tools/dns-leak-test/ lets you verify this.
Server-side architecture (for the curious)
What runs on a VPN server, briefly:
- The VPN daemon itself (WireGuard kernel module + wg-go userspace, or OpenVPN server).
- NAT (Network Address Translation) to map VPN client traffic to the server's public IP.
- A firewall to prevent client-to-client traffic and to isolate the management interface.
- Optional: a logging system. We disable this at the config level — see our audit.
Our servers run on RAM-disk so that even system-level logs don't persist past a reboot. The point is to make logging architecturally hard, not just policy-prohibited.
The math you can skip if you're not curious
The cryptographic primitives ClownVPN uses, with rough security margins:
- ChaCha20-Poly1305 for symmetric encryption. ~256-bit security level. Faster than AES on CPUs without AES hardware acceleration (most older phones).
- Curve25519 for ECDH key exchange. ~128-bit security level. Tiny keys (32 bytes), fast computation.
- BLAKE2s for hashing. Modern, fast, collision-resistant.
- AES-256-GCM on OpenVPN fallback for users with networks that block WireGuard's UDP port.
All of these are peer-reviewed, well-understood, and have held up under cryptanalysis. No surprises here.