How a VPN tunnel works under the hood

Until you understand what happens inside the tunnel, every protocol is a black box to you and every breakage is "magic." Let's get the mechanics down once and properly, so from here on you're reading configs, not incantations.

This material covers the engineering of your own network infrastructure and is educational in nature. Complying with the laws of your own jurisdiction is on you.

What "connect to the VPN" means

When a client taps "connect," nothing mystical happens. Their device brings up an encrypted connection to your node and from that moment sends all (or part of) its internet traffic not directly, but inside that connection. The node unwraps the traffic and lets it out onto the internet under its own name.

The core idea is swapping the point of entry into the internet. To the site the client is reaching, the request arrives not from the client's home ISP but from your node in Germany. And to the client's ISP, only the encrypted stream to the node is visible — it can't read what's inside.

That's the whole VPN at the level of the idea. The rest is detail — and it's the detail that decides whether the tunnel survives inspection or not.

Encapsulation: a packet inside a packet

Ordinary internet traffic is packets: each has a sender address, a recipient address, and a payload. When the tunnel is on, encapsulation happens: the client's original packet (say, "I want to open example.com") gets wrapped whole inside a new packet addressed to your node.

Picture it as a letter in one envelope tucked inside another. Everyone along the way sees the outer envelope — it only says "to node such-and-such." The inner envelope, with the real recipient's address, is opened only at the node. The ISP along the path sees the outer envelope and has no idea what's inside.

It's precisely this "envelope inside an envelope" that makes VPN traffic statistically different from ordinary web browsing — and it's these differences that smart inspection catches. But more on that separately.

Encryption: why you can't peek inside

Sealing the outer envelope isn't enough — it has to be made unreadable. That's what encryption is for. Modern protocols bring up a cryptographic channel between client and node: both sides agree on a shared secret (the handshake), after which all the contents are encrypted so an eavesdropper along the way sees only noise.

The subtle part is that the fact of the handshake is visible. Inspection can't read the contents, but it can look at how the connection setup appears — which protocol, which TLS parameters, which domain the client is supposedly reaching (the SNI). If the handshake looks like a rare, clunky VPN client rather than an ordinary browser, that's a flag. So the whole modern fight isn't about "encrypt harder," it's about making the handshake indistinguishable from ordinary HTTPS.

The exit point: where traffic becomes ordinary again

At the node the traffic is decrypted, unwrapped from the outer envelope, and goes out onto the internet as a normal request — from the node's IP. That's the exit point (exit).

Several consequences that matter to an operator follow from this:

• What the destination site sees is the node's IP and its geolocation. A client in Russia exiting through a German node looks German to the site.
• Responsibility for the exit traffic formally falls on the node's owner — someone else's traffic flows through it. That's why exit nodes aren't kept on your main infrastructure or anywhere it would create problems.
• The reputation of the node's IP is an asset. If someone made noise through that address, or it landed on blacklists, some sites will start showing the client a CAPTCHA or throttling access.

Full vs. split tunnel

There are two modes, and it's not a trivial detail — it's the cause of half of all client tickets.

• Full tunnel — all of the client's traffic goes through the node. Simple, but the client's "VPN shows" on every site, and domestic services (marketplaces, banks) that throttle access from foreign IPs stop opening.
• Split tunnel — some traffic goes through the node, some directly. The rule is usually simple: local and domestic resources bypass the tunnel, everything else goes through the node. The client both circumvents blocks and keeps their bank and marketplace working.

The split route is defined by routing rules — a big topic of its own, but you need to know it exists right away: a well-built service almost always hands the client a split tunnel, otherwise it catches a flood of "the marketplace won't open" complaints.

Putting the picture together

So, one cycle of the tunnel's work:

1. The client brings up an encrypted connection to the node (a handshake that tries to look like ordinary HTTPS).
2. Their traffic is encapsulated — wrapped in an outer envelope addressed to the node.
3. Along the way the ISP sees only the outer envelope and noise inside.
4. The node decrypts, unwraps, and releases the traffic onto the internet from its own IP.
5. Routing rules decide what goes through the node and what goes directly.

Next in this section — an overview of protocols: these are different ways of doing steps 1 and 2 such that the "ISP sees the envelope" step doesn't end in a block. You now know the mechanics, so it'll read as engineering rather than magic.