What a VPN Tunnel Is and How Your Traffic Travels
Short answer
A VPN tunnel is encapsulation: your normal network packets are encrypted and placed inside new packets addressed to the VPN server, which unwraps them and forwards the originals on your behalf. Anyone watching the path sees only encrypted traffic between you and one server. The extra wrapper adds overhead, which is why a tunnel is always slightly slower than no tunnel.
On this page
The word “tunnel” does a lot of work in VPN marketing, usually illustrated with a glowing pipe through which your data travels safely. The mechanism is both more boring and more useful to understand: a tunnel is one set of network packets carried inside another set of network packets.
Once that clicks, most VPN faults stop being mysterious. Slow speeds, pages that load halfway, printers that disappear and sites that refuse to work all trace back to something specific about the wrapping.
Encapsulation, concretely
A normal packet leaving your laptop has a header saying “from 192.168.1.40, to the address of the website” and a payload containing the request.
When a VPN is running, that packet does not go to your router. It goes to a virtual network adapter the client installed, which looks to the operating system like another network card. The VPN software then:
- Encrypts the entire original packet, header included.
- Puts the encrypted blob inside a new packet addressed to the VPN server.
- Hands that new packet to your real adapter, which sends it out normally.
Your router, your internet provider and every router along the way see only the outer packet: traffic from your home to one server, contents unreadable. The original destination is inside the encrypted payload, invisible to them.
At the VPN server, the process reverses. It strips the wrapper, decrypts the original packet, and sends it to the actual destination using its own IP address as the source. Replies come back to the server, which wraps them for the return trip.
What the routing table does
The piece that makes this work automatically is your device’s routing table — the list the operating system consults to decide which adapter a packet should use.
When the VPN connects, the client typically installs a route saying “send everything to the virtual adapter”, which overrides the normal default route to your router. Two routes are left intact:
- A specific route to the VPN server’s own address, via your real adapter. Without this the tunnel’s own packets would try to go through the tunnel, and nothing would work.
- Usually a route to your local subnet, so your printer still responds.
This is why “connected but no internet” after a VPN crash is so common. The client died without removing its route, so the operating system is still sending everything to a virtual adapter that no longer leads anywhere. The fix is to restart the client cleanly or reboot, not to reinstall anything, and the general diagnosis in Wi-Fi connected but no internet applies here too.
Why tunnels are slower
Three costs, which stack:
| Cost | Typical effect | Why |
|---|---|---|
| Encryption and decryption | Small on modern hardware | CPUs have AES instructions built in |
| Encapsulation overhead | A few percent of throughput | Every packet carries an extra header |
| Longer path | Anything from 5ms to 200ms+ | Traffic detours via the server |
The third dominates. A server in your own city adds a few milliseconds and almost no measurable throughput loss. A server on another continent adds the round trip twice over, because every request and every reply makes the detour.
The encryption cost is usually overstated. Modern processors, including phone ones, handle AES in dedicated hardware. Why a VPN slows your connection goes through the whole chain in more detail.
The MTU problem
This one causes a specific, recognisable symptom: some sites load instantly, others hang forever at a blank page, and small requests work while large ones do not.
Every link has a maximum packet size, typically 1500 bytes on ethernet. Wrapping a packet adds 40–80 bytes depending on protocol, so a full-size original packet no longer fits inside the wrapper. The network has to fragment it, and when the path mishandles fragmentation or blocks the signalling that negotiates size, large packets vanish silently.
The fix is to lower the MTU in the VPN client’s advanced settings. Try 1400, then 1380 if that does not do it. Connections carrying mostly small packets (chat, DNS) keep working throughout, which is exactly why the failure looks so selective.
Full tunnel versus split tunnel
By default a client sends everything through the tunnel — a full tunnel. Every connection, including the ones that gain nothing from it, takes the detour.
A split tunnel routes only some applications or destinations through, and lets the rest use your normal connection. It is faster for the excluded traffic and keeps local services working, at the cost of a more complicated mental model of what is and is not protected. Split tunnelling in detail covers when it is worth the complexity.
How the two ends agree on keys
The encryption has to start somewhere, and the handshake is where most of the differences between protocols actually live.
Before any traffic flows, the two ends authenticate each other and agree on keys for this session. WireGuard does this with a fixed pair of public keys, one on each side, and completes the exchange in a single round trip. That is why a WireGuard tunnel appears almost instantly and resumes without ceremony after your address changes.
OpenVPN and IKEv2 use certificates and a longer negotiation, which takes several round trips and is why those clients visibly spend a few seconds connecting. The upside is flexibility: certificates can be revoked centrally, which matters to an organisation managing hundreds of users and not at all to you.
Both arrangements then rotate keys periodically during the session, so a key recovered later does not decrypt earlier traffic. This property is the one piece of the encryption story that is genuinely worth knowing, and it is also the one the marketing never mentions, presumably because “military-grade” is easier to put on a banner.
What the tunnel does not hide
The outer packet is not invisible. Your internet provider cannot read the contents, but it can see:
- That you are connected to a specific IP address, continuously.
- How much data you send and receive, and when.
- The traffic pattern, which distinguishes a video stream from a file download reasonably well even when encrypted.
Networks that want to block VPNs rely on exactly this. A long-lived, high-volume encrypted connection to a known datacentre address is not subtle. It is why protocol obfuscation exists, and why OpenVPN over TCP port 443 still has a use in 2026 despite being slower than everything else.
Realistic expectations
A healthy tunnel on a nearby server costs you a few percent of throughput and a handful of milliseconds. You should not be able to feel it during normal browsing.
If you can, something specific is wrong rather than the tunnel being inherently slow — usually server distance, an MTU mismatch, or a protocol falling back to TCP because UDP is blocked on the network you are on. Each of those has a fix. What has no fix is the detour itself: a server 8,000km away will always add the time light takes to get there and back, and no provider has found a way around physics.