VPN (Virtual Private Network) is the umbrella term for technology that stretches "an encrypted virtual private line only we can access" over a public network. This article goes through tunneling as the underlying mechanism, remote-access vs site-to-site, the PPTP → WireGuard generation shift alongside how to pick today, the implementation pitfalls (DNS / IPv6 / kill switch), the lineage of enterprise VPN-gateway vulnerabilities, and finally the ZTNA / SASE successor model.
The mechanism — tunnels and encapsulation #
The essence of VPN is the simple idea "take the original IP packet, encrypt it, and put it inside another IP packet". This is called tunneling.
# Without VPN — the raw IP packet flows as-is
[ IP 10.0.0.5→10.0.0.20 ][ TCP 443 ][ HTTP / DB / etc ]
# With VPN — the original packet is encrypted and wrapped in an outer packet
[ outer IP public IP → VPN GW ][ UDP 51820 ][ VPN hdr ][ encrypted original packet (IP+TCP+App) ]
▲ only the two endpoints holding the key can read the insideThe key points:
- The "outer" and "inner" can be independent IP spaces. The client gets an internal IP like
10.0.0.5and can talk to internal servers "as if it were on the same LAN" - Intermediate devices (ISP / routers / Wi-Fi APs / censorship gear) on the outer side cannot see the inner packet. All they see is "encrypted traffic from some public IP to the VPN gateway"
- At the VPN gateway, the packet is decrypted and re-injected onto the internal network. From the internal server's perspective it's "a normal connection from an internal IP"
PPTP / IPsec / OpenVPN / WireGuard — all VPN protocols share the same skeleton of "one more layer of IP encapsulation". What differs is the outer packet format (UDP/TCP, GRE/ESP), the VPN header contents (key exchange, tamper detection, ordering), and the cryptographic algorithms.
Try it yourself — follow how the client's traffic goes through the encrypted tunnel at the gateway, reaches the destination, and comes back.
Two forms — remote-access and site-to-site #
VPN splits into two major forms by "what is being connected to what". The mechanism is the same; the operational profile and selection criteria differ greatly.
Remote-access VPN #
A single client (PC / phone) crosses the public Internet to reach a corporate LAN or a VPN provider's POP. Remote work, accessing the office from a hotel, consumer anonymity VPN services — all of this fits here.
Design questions:
- Per-client authentication (passwords, certificates, TOTP, device posture = AV / patch level / disk encryption status)
- Dynamic inner IP allocation (DHCP-like), with DNS / search-domain injection
- Whether to enable split tunneling (only office-bound traffic via VPN; everything else direct) — it saves bandwidth but bypasses the internal DNS and monitoring, which is contentious
- Users normally install a dedicated client (OpenVPN GUI, Cisco AnyConnect, WireGuard app)
Site-to-site VPN #
Routers / firewalls maintain a constant VPN tunnel between each other and make distant LANs look like one. HQ ⇔ branch, HQ ⇔ AWS VPC, HQ ⇔ Azure VNet, DC redundancy — a huge fraction of enterprise networking quietly runs on this.
Design questions:
- Authentication between routers via pre-shared key (PSK) or certificates
- The tunnel is always up; users never see "the VPN"
- IPsec (IKEv2) is the de facto standard. Cisco / Fortinet / Juniper / all cloud providers support it
- Routing (static or BGP) is usually used to exchange the inter-site routes
- Redundancy (Active/Standby tunnels, multiple gateways) often factors into operational requirements
Protocol generations — from PPTP to WireGuard #
The fastest way to understand VPN protocols is to see them as "a set that has gone through generation shifts driven by 30 years of cryptography and operational requirements".
PPTP (1996, Microsoft) — do not use #
Bundled with Windows NT 4.0 / 98, it exploded in adoption. The design of wrapping PPP in a GRE tunnel was groundbreaking at the time. But the authentication (MS-CHAPv2) was shown to be effectively brute-forceable by Moxie Marlinspike in 2012, and the encryption (MPPE) relies on 40/128-bit RC4 — it can no longer meet modern cryptographic requirements. You'll still find it lingering on legacy hardware; the right response is disable on sight.
L2TP/IPsec (1999) — the legacy mainline #
L2TP (RFC 2661) merged Cisco's L2F + Microsoft's PPTP and was wrapped in IPsec ESP for encryption. Because it shipped natively in the OS, it was the corporate VPN mainline in the 2000s. The spec itself has no major flaws, but it's not recommended for new builds: the NAT-traversal (NAT-T) setup is painful, PSK leakage in operations is easy, and the parameter surface is large enough to make vendor interop frequently a dead end.
IKEv2/IPsec — the modern mainline #
A redesigned second version of IPsec's key exchange (IKE). The most widely deployed modern IPsec — Cisco, Microsoft Always On VPN, Apple iOS native VPN.
- MOBIKE preserves the session across Wi-Fi ↔ 4G/5G handovers → strong on mobile
- AEAD via AES-GCM / ChaCha20-Poly1305, with PFS (Forward Secrecy) on by default
- NAT-T built-in by default
- Hardware acceleration is widespread, so it's fast
It is the de facto standard for site-to-site VPN and the main protocol for "Always On VPN" from an iPhone to the corporate network.
OpenVPN (2001) — "if TCP/443 gets through, it works" #
A userspace VPN that carries a custom binary protocol over TLS. Released by James Yonan, its ability to work over TCP or UDP and work over TCP/443 made it the standard pick for getting through airport / hotel / nation-state firewalls. Its cross-platform support and the simplicity of a single .ovpn config file are why consumer VPN services chose it. Because it runs in userspace, it's slower than IKEv2 / WireGuard.
SSL VPN — "works with just a browser" #
VPN carried over HTTPS (TCP/443). The main remote-access offering from enterprise vendors: Cisco AnyConnect / Fortinet SSL VPN / Pulse Connect Secure / Palo Alto GlobalProtect / SonicWall. The combination of "as long as 443/tcp is open, it works" and "log in with a browser, the client downloads itself" made it exploded in popularity. As we'll see later, vulnerabilities in this product family have become a primary intrusion route for modern enterprise breaches.
WireGuard (2018) — the modern default candidate #
Released by Jason A. Donenfeld, mainlined into the Linux kernel 5.6 (2020). Its roughly 4,000 lines of code are extraordinarily small, and its single-fixed-cipher-suite minimalism is poised to replace IPsec / OpenVPN at scale.
- Key exchange: Curve25519 / AEAD: ChaCha20-Poly1305 / hash: Blake2s / KDF: HKDF — no negotiation = a small attack surface
- Single UDP port (default 51820)
- Config is a list of public keys, one line per peer (feels like SSH
authorized_keys) - No concept of connect / disconnect — a stateless peer model that sends only when needed
- Battery-friendly on mobile
Modern consumer VPN services (Mullvad / IVPN / ProtonVPN) commonly center on WireGuard. Tailscale wraps WireGuard in a control plane and lives closer to ZTNA — it is currently the most momentum-rich product in this space.
So which one — choosing by use case #
| Use case | Recommended | Why |
|---|---|---|
| Personal privacy (public Wi-Fi defense / censorship circumvention) | Mullvad, ProtonVPN (WireGuard) | Fast, audited no-log policies, battery-friendly on mobile |
| Enterprise remote access (small/mid) | Tailscale, OpenVPN | Tailscale is easy to deploy and operate; OpenVPN is mature with abundant docs |
| Enterprise remote access (large) | Cloudflare Zero Trust, Zscaler, GlobalProtect | When you need device posture, SAML/SCIM, and WAN integration |
| Site-to-site (HQ ⇔ branch, cloud ⇔ on-prem) | IKEv2/IPsec | Vendor interop and redundancy ecosystem are mature |
| Self-hosted / nomadic devices | Tailscale, self-hosted WireGuard | Simple config; easy NAT traversal |
| Nation-state-scale censorship evasion | OpenVPN over TCP/443, Shadowsocks, V2Ray | Not strictly VPNs, but can hide inside HTTPS |
Aside from legacy-hardware compatibility, neither appears in the table above. Drop them from the candidate list for any new deployment as a rule of thumb.
Operational pitfalls that catch people out #
VPN is a technology prone to the illusion that "connected = safe", and plain traffic leaking through the gaps in the implementation happens in practice all the time.
DNS leaks #
The VPN is up, but DNS queries are still going to the ISP's DNS. The ISP can see exactly which domains were visited.
$ dig +short whoami.akamai.net
10.45.67.89 # OK if this IP belongs to the VPN provider / internal DNS
# If it's in the ISP's range, that's a leakFix: switch the DNS server to the VPN inner-side DNS when the VPN comes up (Push "dhcp-option DNS x.x.x.x"). On Linux, systemd-resolved + DNS-over-TLS can force the whole system's DNS.
IPv6 leaks #
The VPN client tunnels IPv4 only, and IPv6 traffic flows in the clear. Many modern sites are IPv6-ready, so the real-world impact is large.
$ curl -6 ifconfig.me
2401:abcd:... # If your raw IPv6 came back, that's a leakFix: disable IPv6 entirely while the VPN is up, or confirm the client also tunnels IPv6. WireGuard handles IPv6 by default.
No kill switch #
The OS behavior of switching back to the raw connection the instant the VPN disconnects. The user never notices, but communications continue over their real IP. Commercial VPN clients usually have this built in; for self-hosted OpenVPN / WireGuard you implement it yourself with iptables / nftables.
# Add to the [Interface] section
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 REJECTWebRTC leaks #
The browser's WebRTC API lets JavaScript obtain the raw LAN / public IP without going through the VPN. Especially painful for users seeking anonymity.
Check at browserleaks.com/webrtc — if your raw IP is exposed there, it's a leak. Fix: a browser extension that disables WebRTC, or in Firefox about:config set media.peerconnection.enabled = false.
When you use a consumer VPN service, all of your traffic necessarily passes through the provider's gateway. If the provider acts maliciously, even if they can't read the contents, they can still record the "when / to where / how much" metadata. Selection axes: (1) no-log + third-party audits (Mullvad / ProtonVPN have audit history) / (2) jurisdiction (some users avoid Five/Nine/Fourteen Eyes countries) / (3) anonymous payment (cash / Bitcoin) / (4) physical vs RAM-only servers.
The lineage of enterprise VPN-gateway vulnerabilities #
VPN is targeted heavily as the trusted entry point, and SSL VPN appliances in particular have become a primary intrusion route used by nation-state attackers.
| Year | Product / CVE | Detail |
|---|---|---|
| 2018 | Fortinet FortiGate SSL VPN / CVE-2018-13379 | Path traversal → session file theft. About 50,000 sets of credentials leaked; continued abuse through 2021-22 |
| 2019 | Pulse Connect Secure / CVE-2019-11510 | Unauthenticated arbitrary file read. Joint CISA / NSA / FBI warning; massively exploited by Maze ransomware operators and APTs |
| 2019 | Citrix Gateway / ADC ("Shitrix") / CVE-2019-19781 | Directory traversal → unauthenticated RCE, CVSS 9.8 |
| 2020 | SolarWinds Orion | Supply-chain compromise → lateral pivot into internal VPN gateways; many U.S. federal agencies breached. "The perimeter that VPN was supposed to protect" itself became the breach vector |
| 2024 | Palo Alto GlobalProtect / CVE-2024-3400 | Unauthenticated RCE, CVSS 10.0, months of zero-day exploitation |
VPN gateways are permanently exposed to the Internet, so they are top-priority patch targets. Mandatory MFA + client-certificate combination + vendor CVE monitoring is the modern operational floor.
After VPN — ZTNA / SASE #
The classic VPN assumption "inside the corporate LAN = trusted" no longer matches a world of compromised endpoints, contractors, and SaaS-centered work. Starting with Google's BeyondCorp (2014+), Zero Trust Network Access (ZTNA) has spread broadly.
| Perspective | Traditional VPN | ZTNA |
|---|---|---|
| Trust boundary | Once you're in, you can reach everything | Per-application individual authorization |
| Authentication frequency | Once at connection time | Re-evaluated per request |
| Device | User authentication only | Also device posture (patches / EDR / encryption state) |
| Insider threat | Weak (lateral movement allowed) | Strong (lateral movement blocked) |
| Phrasing | "Connect to the VPN" | "Access the app" |
Representative products: Cloudflare Zero Trust / Zscaler Private Access / Tailscale / Twingate / Cisco Duo + AnyConnect. Combine this with WAN-side security (CASB / SWG / FWaaS) delivered as one cloud service and you have SASE (Secure Access Service Edge, Gartner 2019).
Short-term, coexistence is realistic. ZTNA is per-app, but legacy enterprise apps still need transparent L3 routing → so back to VPN. Site-to-site is essentially still only IPsec/WireGuard. Consumer privacy VPNs are a separate category. Long-term, "VPN protocols (WireGuard, IPsec) will live on as the data plane of ZTNA / SASE" — what's happening is the control plane being abstracted away.
Summary #
- VPN evolved from the simple idea "build a pretend private line over the Internet" through several generations driven by cryptography and operational reality
- As a user, what matters is (1) which protocol to pick (WireGuard-centric) / (2) whether to close the gaps where plain traffic escapes (DNS / IPv6 / WebRTC / kill switch)
- As an operator, what matters is (3) keeping the gateway itself up to date (the Fortinet / Pulse / Citrix / Palo Alto lineage makes this obvious)
- "The contents are encrypted" does NOT equal "safe". Only when end-to-end authentication, continuous patching, and device-side checks are all in place does a VPN become a real shield
