What is a VPN tunnel?
A VPN tunnel is the encrypted path your traffic takes between your device and the VPN server. Your ordinary packets are wrapped inside new ones addressed to the server, so anything carrying them sees only the outer wrapper — the real destination is inside, and encrypted.
What "wrapping" actually means
Every packet you send has a header saying where it is going. Normally that says the address of the site you are visiting, and every router along the way reads it.
A tunnel takes that whole packet — header included — encrypts it, and puts it inside a new packet whose header says only to the VPN server. That is encapsulation, and it is what makes a tunnel a tunnel.
| The outer header, readable by every hop | The payload | |
|---|---|---|
| Without a tunnel | to: example.com | your data, in the open |
| Inside a tunnel | to: vpn-server | encrypted, and containing to: example.com plus your data |
At the server the outer wrapper is stripped, the inner packet is decrypted, and it goes on to example.com as an ordinary request — now appearing to come from the server. The reply makes the same trip in reverse.
So the networks between you and the server learn three things: that you are connected to a VPN, how much data you are moving, and when. They do not learn where it is going. That is a meaningful amount of metadata to still be leaking, and it is worth knowing you are leaking it.
Tunnelling and encryption are separate jobs
Worth separating, because they get used interchangeably and are not the same thing.
Tunnelling is an addressing trick. It lets a packet destined for one place travel inside a packet destined for another. GRE tunnels do this with no encryption whatsoever, and are used constantly inside corporate networks for routing reasons that have nothing to do with privacy.
Encryption is what makes the inner packet unreadable. Without it, a tunnel changes where traffic goes and hides nothing.
Modern VPN protocols do both, and which protocol you use decides how. The distinction matters when reading older documentation, where "VPN tunnel" sometimes means the addressing alone.
What escapes
A tunnel is only as good as what is routed into it, and two things routinely are not. Both happen while the app reports a healthy connection, which is what makes them worth testing rather than assuming.
DNS
Before your device connects to a site it asks a resolver for the address. If that query goes to your internet provider's resolver rather than through the tunnel, your provider gets a list of every domain you visit — the exact thing the tunnel was supposed to prevent, leaking through a side channel while the tunnel itself works perfectly. The DNS leak test shows which resolvers are actually answering for you.
WebRTC
Browsers implement a peer-to-peer API for video calls, and part of how it works is discovering your real address so two browsers can connect directly. It operates below the level your proxy settings reach, so in some configurations a web page can simply ask for your real address and be given it. Worth checking, particularly on Chrome and Firefox.
The third case is not a leak but a gap: if the tunnel drops, everything reverts to the bare network instantly and silently. That is what a kill switch prevents, by dropping the network with it — covered in detail here.
Why large transfers stall when small ones work
A specific and genuinely confusing symptom, worth knowing because the cause is not obvious. Pages load, small requests succeed, and then a large download or an upload hangs indefinitely.
The cause is usually packet size. Every network has a maximum packet size — typically 1500 bytes on Ethernet. Encapsulation adds bytes to each packet, so a full-size packet entering the tunnel comes out over the limit and must be fragmented or dropped. When the mechanism that is meant to negotiate this is blocked, packets are silently discarded, and only large transfers produce packets big enough to hit the ceiling.
The fix is lowering the tunnel's packet size, which most clients do automatically and some expose as an MTU setting. If you are debugging exactly this symptom, that setting is where to look.
Related questions
Is a VPN tunnel the same as encryption?
Related but not the same. Tunnelling is the wrapping — putting your packet inside another packet addressed to the VPN server. Encryption is what makes the inner packet unreadable. You can tunnel without encrypting, and some protocols historically did, which is why GRE and plain L2TP tunnels offer no confidentiality at all. A modern VPN does both, and the useful shorthand is that tunnelling handles the addressing while encryption handles the privacy.
Can traffic escape the tunnel?
Yes, and it is common enough to be worth testing rather than assuming. The two routine leaks are DNS queries going to your normal resolver instead of through the tunnel, which exposes every domain you visit, and WebRTC in your browser revealing your real address through an API that ignores proxy settings entirely. Both happen while the VPN app still says "connected", which is exactly what makes them worth checking.
What is split tunnelling?
Deliberately sending only some traffic through the tunnel and letting the rest go directly. Useful when you want your browser protected but your work video calls on the direct route, or when a banking app refuses to work from a VPN address. The cost is that anything outside the tunnel is exactly as exposed as it would be with no VPN, so it is a decision to make per application rather than a setting to leave on.
Why does tunnelling slow things down?
Three reasons that stack. Your traffic physically travels further, which sets a floor on latency that no software can beat. Wrapping each packet adds overhead, so slightly fewer of your bytes fit in each one. And if the tunnel’s packet size is misconfigured, packets get fragmented or dropped and have to be resent — which is the cause of the specific symptom where small requests work fine and large transfers stall.