VPN (Virtual Private Network) #

A VPN (Virtual Private Network) is the umbrella term for a technology that builds a virtual, encrypted private circuit on top of a public network — usually the Internet — so that only the intended endpoints can use it. "Protect the traffic from eavesdropping and tampering," "reach my office LAN from outside," "glue distant offices into one LAN," "get past censorship and geo-blocks," "stop the ISP from seeing what I browse" — the use cases are different but the underlying idea is the same, and that multi-purpose nature is the defining trait of VPN.

Mechanically, VPN is also the umbrella term for a family of protocols that has rebuilt itself for each era's cryptography and operational requirements around the same simple idea: "stuff one IP packet, encrypted, inside another IP packet." This article goes "grasp the mechanism in one diagram, walk the generations alongside how to pick among them today, then close on the operational landmines and the successor model."

1. The mechanism — Tunneling and encapsulation #

The essence of a VPN is the simple idea "stuff one IP packet, encrypted, inside another." That mechanism is tunneling.

The key consequences:

• The "outer" and "inner" sides have independent IP spaces. The client gets a corporate IP like 10.0.0.5 and talks to the internal server as if they were on the same LAN.
• Outer-side intermediaries — ISP, routers, Wi-Fi APs, censorship boxes — cannot see inside the inner packets. All they see is "encrypted traffic from some public IP to the VPN GW."
• The VPN GW decrypts, exposes the original packet, and forwards it onto the internal network. The internal server thinks "an ordinary connection from a corporate IP."

This is the skeleton common to every VPN protocol — PPTP, IPsec, OpenVPN, WireGuard alike. What differs is just "the outer packet's format (UDP or TCP, GRE or ESP)," "what's in the VPN header (key exchange, integrity, ordering)," and "the cipher algorithms."

2. The two topologies — Remote access and Site-to-Site #

VPN splits into two topologies based on what's connecting to what. The mechanism is the same; the operational implications are very different.

2.1 Remote Access VPN #

A single client (PC / phone) comes in over the public Internet to reach a corporate LAN or a VPN provider's POP. Remote work, accessing the office from a trip, and consumer "anonymity" VPN services all live here.

Design questions:

• Per-client authentication (passwords, certificates, TOTP, device posture = checking AV, patches, disk encryption)
• Dynamic inner-IP assignment (DHCP-like) and DNS / search-domain injection
• Split tunneling (only corporate-bound traffic via the VPN, the rest direct) — saves bandwidth but bypasses corporate DNS and monitoring, so opinions split
• Dedicated client software is the norm (OpenVPN GUI, Cisco AnyConnect, the WireGuard apps, …)

2.2 Site-to-Site VPN #

Routers / firewalls themselves keep a permanent VPN tunnel up between sites, making distant LANs look like one. Headquarters ⇔ branch, headquarters ⇔ AWS VPC, headquarters ⇔ Azure VNet, inter-DC redundancy — there is a lot of this running invisibly inside corporate networks.

Design questions:

• Inter-router auth via pre-shared keys (PSK) or certificates
• Tunnels stay up continuously; users don't see the VPN
• IPsec (IKEv2) is effectively the standard — supported by Cisco / Fortinet / Juniper / cloud providers alike
• Routing (static or BGP) is used to exchange paths between sites
• Redundancy (active/standby tunnels, multiple GWs) becomes part of operational requirements

3. The protocol generations and how to pick today #

The fastest way to understand VPN protocols is as a set that has turned over with three decades of crypto and operational change. Here they are in a single arc — why each appeared, why the next replaced it.

3.1 PPTP (1996, Microsoft) — Don't use this #

The first major protocol that brought VPN within reach of typical enterprises and consumers, bundled with Windows NT 4.0 / 98. It exploded. The design — PPP wrapped in GRE — was novel at the time.

But its authentication (MS-CHAPv2) was broken by Moxie Marlinspike's effective brute force in 2012, and its encryption (MPPE) leans on 40-/128-bit RC4 that doesn't meet modern crypto requirements. It still lingers on legacy gear; disable it on sight.

3.2 L2TP/IPsec (1999) — The legacy mainstream #

The merger of Cisco's L2F and Microsoft's PPTP (RFC 2661) into L2TP, paired with IPsec ESP for encryption. With OS-level support, this was the corporate VPN mainstream of the 2000s.

The protocol itself is fine, but NAT traversal (NAT-T) is fiddly to configure, PSKs leak through operations, and the parameter surface is huge enough that interop fails frequently — so it's not recommended for new deployments. The Snowden documents also implied that NSA had decryption capability against certain L2TP/IPsec parameter combinations.

3.3 IKEv2/IPsec — The modern standard for site-to-site and mobile #

A rebuilt second-generation IKE (Internet Key Exchange) for IPsec. The most widely deployed modern IPsec in commercial products: Cisco, Microsoft Always On VPN, Apple iOS' built-in VPN.

Why IKEv2 stays relevant:

• MOBIKE keeps the session alive across Wi-Fi ↔ 4G/5G handoffs → strong on mobile
• AES-GCM / ChaCha20-Poly1305 AEAD plus PFS (Forward Secrecy) by default
• NAT-T baked in
• Hardware acceleration is widely available, making it fast

It's the de facto standard for Site-to-Site VPN, and it's also the primary "Always-On VPN from your iPhone to the office."

3.4 OpenVPN (2001) — "Works wherever TCP/443 reaches" #

A userspace VPN that runs a custom binary protocol on top of TLS. James Yonan released it; the fact that it works on either TCP or UDP, and on TCP/443 in particular, made it the canonical "punches through airport, hotel, and national firewalls" choice.

Cross-platform (Linux/macOS/Windows/iOS/Android), with a configuration that lives in a single .ovpn file, it became widespread among small / mid enterprise VPNs and consumer VPN services. Being in user space, it's slower than IKEv2 / WireGuard.

3.5 SSL VPN (late 2000s) — "Works from a browser" #

A VPN that runs over HTTPS (TCP/443). Cisco AnyConnect / Fortinet SSL VPN / Pulse Connect Secure / Palo Alto GlobalProtect / SonicWall — the dominant form of corporate remote access.

The combination of "works as long as 443/tcp is open" and "log in via a browser → the client downloads automatically" drove explosive enterprise adoption. But — as the next section spells out — vulnerabilities in this category have become a primary breach vector for modern enterprises, which has changed the operational weight of running these.

3.6 WireGuard (2018) — The modern default #

Released by Jason A. Donenfeld and mainlined into the Linux kernel in 5.6 (2020). Two characteristics — a ~4,000-line codebase and a single fixed cipher suite — give it the momentum to displace IPsec / OpenVPN at scale.

Design highlights:

• Key exchange Curve25519 / AEAD ChaCha20-Poly1305 / hash Blake2s / KDF HKDF — no negotiation, no choice = small attack surface
• Single UDP port (default 51820)
• Configuration is one public key per peer, in the spirit of SSH authorized_keys
• No connection / disconnection concept — stateless "peers" that send only when needed
• Low battery drain on mobile

Modern consumer VPN services (Mullvad / IVPN / ProtonVPN, …) typically build on WireGuard. Tailscale wraps WireGuard with a managed control plane and is currently the most momentum-laden product in the space, sliding toward a ZTNA-flavored offering.

3.7 So which one — concrete picks by use case #

There's essentially no reason to pick PPTP or L2TP/IPsec for a new deployment. Outside of legacy-device interop, neither appears in the table above.

4. Operational landmines #

VPN is a technology that easily lulls people into "connected = safe", and raw traffic sneaking out through implementation gaps happens a lot in practice. The classic holes and how to check for them:

4.1 DNS leak #

The VPN is up but DNS queries still go to the ISP's resolver. The ISP can read "which domains you visited" wide open.

Check: with the VPN connected, run the following. If the returned IP is the VPN provider / your corporate DNS, you're fine. If it's in the ISP's range, you have a leak.

dig +short whoami.akamai.net

Mitigation: switch DNS to a server inside the VPN on connect (Push "dhcp-option DNS x.x.x.x", etc.). On Linux, system-d-resolved + DNS-over-TLS lets you enforce DNS system-wide.

4.2 IPv6 leak #

The VPN client tunnels only IPv4, and IPv6 traffic exits raw. Many sites today are IPv6-capable, so the practical exposure is large.

Check: curl -6 ifconfig.me returning your raw public IPv6 = you have a leak.

Mitigation: fully disable IPv6 while connected, or make sure the client tunnels IPv6 too. WireGuard handles IPv6 by default.

4.3 No kill switch #

The behavior where, the moment the VPN drops, the OS silently switches to the raw circuit. The user doesn't notice and traffic continues with the real IP exposed. Commercial VPN clients ship a kill switch by default; on a self-hosted OpenVPN/WireGuard you wire one up yourself with iptables / nftables.

A WireGuard kill-switch fragment:

PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) \
                -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) \
                -m addrtype ! --dst-type LOCAL -j REJECT

4.4 WebRTC leak #

Browser WebRTC APIs can let JavaScript read the raw LAN IP / public IP even past the VPN. Especially serious for users using a VPN for anonymity.

Check: browserleaks.com/webrtc — a raw IP appearing means a leak.

Mitigation: extensions that disable WebRTC, or media.peerconnection.enabled = false in about:config (Firefox).

4.5 Can you trust your VPN provider? #

When you use a consumer VPN service (NordVPN, ExpressVPN, Mullvad, ProtonVPN, …), all your traffic must traverse their gateway. Even if they can't see content, a malicious provider can collect "when, where, how much" metadata.

Selection criteria:

• No-Log policy + third-party audits on the record (Mullvad and ProtonVPN have audit history)
• Jurisdiction (do they design around avoiding Five / Nine / Fourteen Eyes participation?)
• Anonymous payment (cash / Bitcoin to decouple from your identity)
• Physical vs RAM-only servers (is data wiped on reboot by design?)

5. The lineage of enterprise VPN-gateway vulnerabilities #

VPNs are the front door of trust and an attractive target. SSL VPN-class vendor products in particular have become a primary intrusion path for nation-state actors. Running a VPN without knowing any of this lineage is close to defenseless.

Implication: a VPN gateway is always exposed to the Internet, so it's a top-priority patch target. MFA mandatory + client-certificate combination + vendor CVE monitoring is now the floor for operations.

6. Beyond VPN — ZTNA / SASE #

The classic VPN assumption — "inside the LAN ⇒ trusted" — stopped fitting an environment of compromised endpoints, contractors, and SaaS-centric work. Starting with Google's BeyondCorp (2014–), Zero Trust Network Access (ZTNA) has caught on.

Representative products: Cloudflare Zero Trust / Zscaler Private Access / Tailscale / Twingate / Cisco Duo + AnyConnect. Layering the WAN-side security stack (CASB / SWG / FWaaS) onto this as a unified cloud offering is SASE (Secure Access Service Edge, Gartner 2019).

So does VPN go away completely? In the short term, coexistence is realistic:

• ZTNA assumes per-application access, but legacy line-of-business apps (custom internal protocols, old ERP) still need straight-through L3 routing → VPN
• Site-to-site is essentially still IPsec/WireGuard
• Consumer privacy VPN is a different category from corporate ZTNA

In the medium-to-long term the realistic outlook is that "VPN protocols (WireGuard, IPsec) live on as the data plane underneath ZTNA / SASE." What's happening is not "VPN as a protocol disappears" but "the control plane around it is being abstracted, while VPN remains the underlying tool that digs the tunnel."

VPN began with the simple idea of "virtually leasing a private line over the Internet," and has continued through protocol generations (PPTP → L2TP/IPsec → OpenVPN → SSL VPN → WireGuard) and operational-model generations (perimeter defense → zero trust), tracking the evolution of cryptography and the working environment.

What matters for the user is "which one to pick" (section 3) and "which gaps let raw traffic out" (section 4); for the operator, "keeping the gateway itself current" (section 5). "Encrypted contents" is not the same as "safe." Only when end-to-end authentication, continuous patching, and device-side checks all line up does the VPN become a real shield.