SMIP
All articles
vpnnetworkingadvanced

How does a VPN work, technically?

A VPN sounds simple — 'it hides your IP' — but underneath there's encryption, tunneling protocols, key exchange, and routing changes. Here's exactly what happens when you click Connect.

May 6, 20267 min read

You install a VPN app, click Connect, and your IP changes. What actually happened in the seconds between the click and the connection? It's not magic — it's a specific sequence of cryptographic and networking steps. Here's the technical version, in plain English.

The two-line summary

A VPN creates an encrypted tunnel between your device and a server you choose. Then it changes your operating system's routing rules so all (or most) traffic goes through the tunnel.

That's it. Everything else is detail.

Step 1 — The tunneling protocol

A "tunnel" in networking means: take a packet, wrap it inside another packet, send the outer one across the network, unwrap it on the other side. The inner packet — the one you actually wanted to send — never touches the network in raw form.

VPN tunnels use specific protocols. The big ones in 2026:

WireGuard

Modern, fast, ~4,000 lines of code (compared to 600,000+ for OpenVPN). Built into the Linux kernel since 2020 and now standard everywhere. Uses ChaCha20 for encryption, Curve25519 for key exchange, BLAKE2s for hashing. UDP-only, port-flexible. WireGuard is what most quality VPNs use today.

OpenVPN

The previous generation default. Heavier and slower than WireGuard, but extremely battle-tested and configurable. Runs over either UDP (faster) or TCP (more reliable on hostile networks). Still widely deployed for legacy compatibility.

IKEv2/IPsec

Built into iOS and macOS at the OS level, so it's the default for "VPN configurations" on those platforms. Fast and reliable. Often used by enterprises.

Custom protocols

Some VPN providers run modified versions (Mullvad's WireGuard with multihop, NordVPN's NordLynx, Surfshark's WireGuard-based protocol) for specific features.

For most users, the choice is invisible — pick a VPN provider, they pick the protocol.

Step 2 — Authentication and key exchange

Before any data flows, your device and the VPN server have to:

  1. Verify each other's identity. The server presents a certificate signed by the provider's CA. Your client verifies it.
  2. Agree on encryption keys. Using a key-exchange algorithm (like Curve25519 in WireGuard, or various Diffie-Hellman variants in OpenVPN), they jointly compute a shared secret without ever sending it over the wire. Anyone watching the connection sees only the public parts and can't derive the secret.
  3. Authenticate you. With WireGuard, this is the same key pair (your client's public key is on the server's allow-list). With OpenVPN, it's typically a username/password plus the server cert verification.

Once the handshake completes, both sides have:

  • A symmetric encryption key (ChaCha20 for WireGuard).
  • A way to detect tampering (Poly1305 in WireGuard).
  • Knowledge of each other's public IPs and ports.

This handshake takes a fraction of a second. Then traffic can flow.

Step 3 — Routing changes

This is where the magic happens — and where most "why isn't my VPN working" issues come from.

Before VPN: your operating system's routing table says "send all internet traffic out through the network adapter for my Wi-Fi/Ethernet."

After VPN connect: your operating system inserts a new entry that says "send all internet traffic out through the virtual VPN adapter instead." The VPN client created this virtual adapter when you installed it.

When an app (your browser, a game, anything) sends a packet:

  1. The OS looks up the destination in the routing table.
  2. The route says "go through the VPN adapter."
  3. The packet is handed to the VPN client.
  4. The VPN client encrypts it.
  5. The encrypted packet is wrapped inside an outer packet addressed to the VPN server.
  6. The outer packet leaves your device through the original Wi-Fi/Ethernet adapter, addressed to the VPN server's public IP.
  7. Your ISP sees only "encrypted traffic to one IP" — they can't see what's inside.

The VPN server receives the outer packet, decrypts the inner one, and forwards the inner packet to its real destination. From the destination's perspective, the request came from the VPN server's IP — that's why your IP appears different.

Reply packets travel the same path in reverse: the destination replies to the VPN server, the VPN server encrypts and sends back to your client, your client decrypts and hands to the app.

Step 4 — DNS routing

DNS is where most VPNs trip up. Your apps need to resolve hostnames (google.com → an IP) before they can connect. By default, your OS uses the DNS server your network handed out — often your ISP's.

A correctly configured VPN intercepts DNS queries and routes them through the tunnel too, using the VPN provider's DNS servers. This prevents DNS leaks, where your queries bypass the VPN and tell your ISP exactly which sites you're visiting.

The mechanism is identical to the routing trick above: the VPN client adds a DNS rule in your OS that points to a server reachable only through the tunnel. Queries flow encrypted, ISP sees nothing.

Step 5 — Kill switch

What happens if the VPN connection drops mid-session? Without a kill switch, your OS quietly falls back to the original adapter — and your real IP and DNS get exposed for those few seconds before you reconnect. Many VPNs implement a kill switch by:

  • Adding firewall rules that block all traffic except through the VPN adapter.
  • Detecting tunnel failure and pausing all traffic until reconnect.
  • Or, more aggressively, taking the system network down entirely.

Quality VPN clients enable this by default or in one click.

The full picture

Putting it together, here's what happens when you click Connect:

1. Your VPN client opens a UDP socket to the VPN server's public IP.
2. WireGuard / OpenVPN handshake: identity verification + key exchange.
3. A virtual network adapter (utun0 on Linux/macOS, "TAP-Windows" on Windows)
   is brought up with an IP from the VPN's internal range.
4. Routing table updated: 0.0.0.0/0 → virtual adapter.
5. DNS settings updated to point at VPN-internal DNS server.
6. Optional kill-switch firewall rules installed.
7. Your apps' traffic now flows through the tunnel.

When you click Disconnect, all of these are reversed: routing rules removed, DNS reset, virtual adapter brought down, sockets closed.

What VPNs do not do

Worth being clear about the limits:

  • They don't encrypt traffic end-to-end. The VPN tunnel encrypts traffic between your device and the VPN server. Beyond that, the traffic goes out over the regular internet — protected only by whatever encryption the destination uses (usually HTTPS).
  • They don't anonymize. The VPN provider can see all your traffic in plaintext (after they decrypt it from the tunnel). Trust is now placed in them. Most reputable providers don't log; some do.
  • They don't block fingerprinting. Browser fingerprints, accounts you log into, behavior patterns — none of that changes with a VPN.
  • They don't speed up the internet. They add a hop and encryption overhead. They can route around congested links, which sometimes helps; usually they're 10–30% slower than direct.

Why some "VPNs" aren't really VPNs

Marketing terms have blurred. "VPN" in 2026 covers everything from corporate site-to-site tunnels to privacy-focused consumer services to "browser proxies that call themselves VPNs."

Real VPNs (in the technical sense) tunnel all your traffic at the OS routing level. Browser-only services that route just your tabs are technically proxies — narrower, lighter, often labeled as VPNs anyway. Both have uses; just know the difference.

Quick FAQ

Do VPNs slow down my internet? A bit — typically 10–30%. Encryption and the extra hop add latency. Quality providers minimize this.

Can my ISP tell I'm using a VPN? Yes — they can see encrypted traffic to a single IP. They can't see what's inside, but they know a VPN is in use. To hide that fact too, you'd need an obfuscated VPN protocol (some providers offer this) or Tor.

Can a website tell I'm using a VPN? Often, yes. They check the IP against known VPN/datacenter ranges. Some sites block known VPN IPs entirely.

Are free VPNs safe? Mostly no. The economics of running a VPN service mean someone has to pay — and if you're not paying, your traffic data probably is. There are exceptions (Mullvad's free tier, ProtonVPN's limited free tier from a paid company), but in general: paid is much safer.

WireGuard vs OpenVPN — which is better? WireGuard is faster, simpler, and modern. OpenVPN is more configurable and time-tested. For most users, WireGuard wins.

TL;DR

A VPN is an encrypted tunnel plus routing rules. It encrypts traffic between you and a chosen server, then sends all your traffic through that server. The result: your ISP can't see what you're doing, and websites see the server's IP instead of yours.

That's the whole technical story. Now you know what's happening every time you click Connect.