How a VPN actually works, and what it doesn't hide.

"I use a VPN, so I'm anonymous online" is one of the most common misunderstandings in consumer security, and it survives because the first half of the sentence is true enough to make the second half feel true too. A VPN really does change what your local network and your ISP can see. It really does change the IP address a website sees when you connect. What it does not do is erase you from the transaction — it just moves the point where trust gets placed, from your ISP to whichever company runs the VPN server your traffic now flows through. Understanding how a VPN actually works, mechanically, is the fastest way to stop treating it as a privacy cloaking device and start treating it as what it is: an encrypted tunnel with a very specific, very limited job.

What a VPN actually does

A Virtual Private Network creates an encrypted tunnel between your device and a server operated by the VPN provider (or, in a corporate setting, by your employer). Every packet your device would normally send straight onto the internet gets wrapped instead — encrypted, then re-addressed to travel to the VPN server first. The server decrypts each packet, forwards it on to its real destination as if it originated from the server itself, and does the same in reverse for anything that comes back. Your device behaves, from the outside, as if it lives wherever that server lives.

This single mechanic — encrypt locally, decrypt and re-emit at the far end — is the entire trick. Everything a VPN can or cannot protect you from follows directly from where that far end sits and who controls it.

What a VPN hides from your local network and ISP

Before your traffic reaches the VPN server, it has to cross your own network and your ISP's infrastructure. Without a VPN, both can see the destination and, for anything not already using TLS, the content of what you send. With a VPN active, everything leaving your device is already encrypted before it hits your router or your ISP's equipment, so:

• Your ISP sees an encrypted tunnel to one IP address — the VPN server — and cannot see which sites or services you're actually reaching inside it, or what data is flowing.
• Anyone on your local network — a coffee-shop Wi-Fi operator, a malicious peer on the same access point, a landlord running the router — sees the same thing: encrypted tunnel traffic, nothing readable inside it.
• DNS queries that would normally leak your browsing destinations to your ISP's resolver are routed through the tunnel too (when the VPN client is configured correctly), so the ISP loses that visibility as well.

This is a genuine, meaningful privacy improvement on untrusted networks — public Wi-Fi being the clearest case. It is also the part most VPN marketing focuses on, because it's the part that's true without qualification.

What a VPN hides from the destination — and what it doesn't

On the other side of the tunnel, the website or service you're connecting to sees the VPN server's IP address, not yours. That's a real change: your geographic location (as inferred from IP), your ISP, and your home or office network's identity are all replaced by the VPN server's. This is why VPNs are useful for reaching geo-restricted content and for keeping your home IP address out of logs you don't control.

What it does not do is make the connection between you and that account anonymous. Consider what still travels with you inside the tunnel:

• Cookies set by a site persist across IP changes. If you log into the same account before and after enabling a VPN, the site can trivially link both sessions to the same identity regardless of which IP either came from.
• Browser fingerprinting — the combination of screen size, installed fonts, timezone, canvas rendering, and dozens of other quiet signals — can re-identify a browser across sessions with unsettling accuracy, entirely independent of IP address.
• Login-based tracking is the biggest one: the moment you sign into an email provider, a social network, or any account tied to your real identity, that service knows exactly who you are. A VPN changes your network address; it says nothing about the credentials you just typed into a form.

A VPN is encryption and address substitution. It is not an identity-management tool, and treating it as one is where the myth breaks down in practice.

The tunnel, mechanically: encapsulation

The technical term for what a VPN does to each packet is encapsulation: your original packet — with its real source and destination addresses — is encrypted in full and then wrapped inside a new, outer packet addressed only to the VPN server. Only the VPN server holds the key to unwrap it and see the original packet underneath.

Original packet (before the tunnel):
  src: 192.168.1.42       dst: 93.184.216.34:443

Encapsulated packet (what actually travels your ISP's network):
  src: 192.168.1.42       dst: 203.0.113.9:51820   <- your device to the VPN server
  payload: [ everything above, fully encrypted ]

After the VPN server decrypts and forwards it onward:
  src: 203.0.113.9        dst: 93.184.216.34:443   <- now it looks like it's from the VPN server

Everything on the wire between your device and the VPN server carries only the outer, encrypted envelope. Nobody watching that segment — not your router, not your ISP, not someone on the same café Wi-Fi — can read the original source or destination, only that a tunnel exists and roughly how much data is moving through it.

Tunneling protocols compared: WireGuard, OpenVPN, IPsec

"VPN" is a category, not a single technology. The tunnel itself is built with one of a handful of protocols, and the choice affects speed, auditability, and where the VPN is typically deployed:

None of these protocols changes what a VPN fundamentally can and cannot see or hide — that's determined by the tunnel's endpoints, not the encryption scheme connecting them. The protocol choice is about performance, compatibility, and how easy the implementation is to audit, not about privacy guarantees.

Split tunneling: routing only some traffic through the VPN

By default, most VPN clients operate in "full tunnel" mode: every packet your device sends, regardless of destination, gets routed through the encrypted tunnel. Split tunneling changes that, letting you specify which traffic goes through the VPN and which travels the normal route directly. A common configuration sends only traffic destined for a specific application, a specific set of destination IPs, or a specific corporate subnet through the tunnel, while everything else — general web browsing, streaming, other apps — exits directly through your regular internet connection.

This matters for both use cases in this article. On a consumer VPN, split tunneling avoids forcing bandwidth-heavy local traffic through a tunnel that would otherwise detour it through a distant server and back. On a corporate remote-access VPN, split tunneling is often deliberately restricted or disabled entirely, because IT departments want all traffic — not just traffic to internal systems — inspected by corporate security controls. A poorly configured split tunnel is also a real security gap: if only "interesting" traffic is protected while the rest travels in the clear on an untrusted network, you've reintroduced exactly the exposure a VPN is meant to close for that unprotected slice.

Consumer VPN vs corporate VPN

The word "VPN" covers two fairly different deployments that people often conflate:

Consumer VPN

A single device connects out to a commercial provider's server, which then forwards traffic on to the open internet. The goal is almost always privacy from the local network/ISP and, secondarily, changing apparent location. Every consideration in this article about provider trust applies directly here — the provider's server is doing exactly the job your ISP used to do.

Corporate remote-access VPN

An employee's laptop connects into the company's private network rather than out to the open internet. Once connected, the device can reach internal file shares, internal tools, and internal-only websites as if it were physically on the office LAN. This is a client-to-site tunnel, commonly built on IPsec/IKEv2 or OpenVPN, and it's about extending a private network's boundary to a remote device, not about anonymizing that device's traffic to the wider internet.

Site-to-site VPN

No individual client at all — instead, a permanent, always-on tunnel links two entire networks, such as a branch office and headquarters, or an on-premises data center and a cloud environment. Both ends are typically firewalls or dedicated VPN gateways, most often speaking IPsec, and every device on either network can reach the other transparently once the tunnel is established. This is infrastructure, configured once by network administrators, rather than something an individual user turns on and off.

What the VPN provider can see — why trust matters as much as encryption

This is the part consumer VPN marketing tends to leave out. The VPN server is not a black box that traffic passes through unseen — it is the exact point where your traffic becomes readable again, decrypted and forwarded on in whatever form it was in before the tunnel wrapped it. Whoever operates that server occupies the same structural position your ISP used to occupy, with the same theoretical ability to observe destinations, volumes, and — for any traffic that isn't independently protected by its own TLS — content.

A reputable provider mitigates this with a genuinely enforced no-logging policy, ideally backed by an independent third-party audit rather than a claim on a marketing page. But the technical capability to see your traffic exists at that server regardless of the policy layered on top of it — policy is a promise, not a physical constraint. This is why choosing a VPN provider is, in practical terms, a decision about who you're willing to trust with the visibility your ISP used to have, not just a comparison of encryption algorithms. Free VPN services in particular deserve scrutiny here: running server infrastructure costs money, and a provider not charging you directly is monetizing the arrangement somehow.

Checking your own VPN for leaks

Because a misconfigured VPN client can silently fail to protect the exact things it claims to, it's worth verifying rather than assuming. Two checks catch the most common failures:

# 1. Confirm your public IP actually changed
$ curl -s https://ifconfig.me
203.0.113.9        # should be the VPN server's IP, not your ISP's

# 2. Confirm DNS queries are going through the tunnel too
$ nslookup breachfolio.com
Server:  10.8.0.1   # should be a VPN-assigned resolver, not your ISP's DNS

If the first command returns your real ISP-assigned address, the VPN client isn't actually routing your traffic through the tunnel — check that the client shows as "connected," not just "connecting." If the second command shows a DNS server outside the VPN's own address range, you have a DNS leak: your browsing destinations are still being resolved by your ISP even though the rest of your traffic is encrypted, which defeats a meaningful part of what the tunnel is for. Dedicated DNS leak test sites automate both checks from a browser if you'd rather not use a terminal.

The takeaway

A VPN does exactly two things well: it encrypts your traffic against your local network and ISP, and it substitutes your IP address with the VPN server's when talking to the outside world. Both are real, useful, and worth having on any untrusted network. What it does not do is anonymize you — the provider can see what your ISP used to see, cookies and fingerprinting follow you across IP changes, and logging into any account you own re-identifies you instantly, VPN or not. Pick a tunneling protocol for its performance and compatibility characteristics, and pick a provider the way you'd pick anyone else you're handing your traffic to: based on trust, not just on the strength of the padlock.

Frequently asked questions