💥 08-06: VPN Attacks and Weaknesses¶

📌 A VPN Is Not a Magic Shield¶

VPNs are a powerful tool, but they only guarantee one specific thing: that data is protected while it travels between the two tunnel endpoints. Every other security property — what happens before the data enters the tunnel, after it leaves the tunnel, or if the tunnel itself is misconfigured — depends on getting a lot of other details right. This lesson walks through the most common ways VPNs fail in practice.

🔓 Weak or Misconfigured Encryption¶

A VPN is only as strong as the cryptography actually configured on it. Common failure modes:

Outdated protocols/ciphers — older VPN configurations sometimes still allow weak ciphers (e.g., older block cipher modes, short key lengths) for backward compatibility. If a VPN negotiates down to a weak cipher, an attacker capturing the traffic may eventually be able to break the encryption.
Static or reused keys — if the same key protects traffic indefinitely instead of periodically rotating (recall Security Associations expiring and renegotiating — see 08-02: IPsec Fundamentals), a single key compromise exposes a much larger amount of historical or future traffic.
Weak authentication — if the VPN relies on a weak pre-shared key (a short or guessable shared password) instead of strong certificate-based or public-key authentication, an attacker who guesses or brute-forces that key can impersonate a legitimate peer and potentially join or intercept the tunnel.

💡 The lesson here isn't "IPsec/OpenVPN/WireGuard are broken" — the protocols themselves, correctly configured with modern algorithms, are strong. The failures almost always come from configuration choices: legacy compatibility settings, weak shared secrets, or simply never updating a configuration written years ago.

🌊 DNS Leaks¶

As introduced in 08-05: Split Tunneling & Configuration, a DNS leak happens when a client's DNS queries are sent to a DNS server outside the VPN tunnel (e.g., the local ISP's resolver) even while its actual application traffic goes through the tunnel.

Why this matters: DNS queries reveal exactly which hostnames a client is trying to reach — even if an observer can't read the encrypted payload of the tunneled traffic itself, they can see a plaintext list of every domain the client visited, just from watching the leaking DNS traffic. This can defeat the entire purpose of using a VPN for privacy, and in a corporate context it can also let an outside observer infer which internal systems exist, just from watching for internal hostname lookups that leak out.

💡 DNS leaks typically happen because the operating system's default network configuration keeps using whatever DNS server it was assigned before the VPN connected, and the VPN client software failed to override it. Testing for DNS leaks (there are many public "DNS leak test" tools) is a standard VPN configuration sanity check.

🌐 IP Leaks¶

An IP leak happens when some of a client's traffic escapes the tunnel and goes out over its normal network connection, revealing the client's real IP address to the destination, even though the intent was for all traffic to appear to originate from (or be protected by) the VPN.

Common causes:

Tunnel drops without a kill switch — if the VPN connection briefly fails and there's no kill switch (see 08-05: Split Tunneling & Configuration) to block traffic in the meantime, the OS may silently fall back to the regular network connection, leaking real traffic (and the real IP address) during the gap.
IPv6 leaks — a VPN configured to protect only IPv4 traffic can be bypassed entirely if the client also has IPv6 connectivity; traffic that prefers IPv6 may go out directly, unprotected, even while IPv4 traffic correctly uses the tunnel.
WebRTC and similar browser features — certain browser APIs can reveal a device's real local/public IP address directly to a website via side channels, independent of whatever the browser's main HTTP traffic is doing.

🌉 Split-Tunnel Bridging Risk¶

Covered in depth in 08-05: Split Tunneling & Configuration: when split tunneling is enabled, a client device simultaneously holds a trusted, authenticated connection into the private network and an unrestricted connection to the untrusted public Internet. A compromise via the untrusted side (malware from a website, phishing, or a malicious download) gives an attacker a foothold on a device that already has legitimate access into the private network — no attack on the VPN's cryptography required at all. This is one of the most practically significant "VPN" risks precisely because it doesn't involve breaking the VPN itself.

🖥️ VPN Endpoint Compromise¶

The VPN protects data in transit, between two endpoints — it does nothing to protect the endpoints themselves. If either end of the tunnel is compromised, the VPN's protections become irrelevant, because the attacker can simply read the data before it's encrypted or after it's decrypted.

Compromised client device — malware on a laptop with an active VPN connection can read, modify, or exfiltrate data completely independent of the tunnel's encryption, because it operates above the point where encryption happens (it sees the plaintext, same as the legitimate applications do).
Compromised VPN server/gateway — if an attacker gains control of the VPN gateway itself, they sit at a point where all tunneled traffic passes through in decrypted form (the gateway has to decrypt it to route it onward). A compromised gateway is one of the highest-value targets in an entire network, since it potentially exposes every client's traffic.
Stolen credentials/keys — if a client certificate, private key, or pre-shared key is stolen (via phishing, malware, or a poorly secured backup), an attacker can authenticate as a legitimate peer and either join the VPN directly or, in weaker configurations, potentially decrypt captured traffic.

💡 This is the same principle that shows up everywhere in security: encryption protects data in transit or at rest, not the endpoints that hold the plaintext. A VPN is a transit control, not an endpoint control.

🧭 Putting the Risks in Perspective¶

Weakness	What Fails	Where the Real Problem Is
Weak/misconfigured encryption	Confidentiality of tunneled data	Configuration choices, not the protocol design
DNS leak	Privacy of which sites are visited	DNS not routed through the tunnel
IP leak	Client's real address exposed	Tunnel drop, IPv6 gap, or browser side-channel
Split-tunnel bridging	Trust boundary between networks	Simultaneous trusted + untrusted connectivity on one device
Endpoint compromise	Everything — data is plaintext at the endpoint	The VPN was never meant to protect this layer

🛡️ A Reminder About Scope¶

A VPN answers exactly one question well: "Is my data protected while it crosses this network path?" It does not answer, and was never designed to answer:

Is the device I'm using free of malware? (Endpoint security's job)
Is the person authenticating actually who they claim to be, beyond just "holds the right key/certificate"? (Identity and access management's job — strong authentication, MFA)
Is the internal network segmented so a single compromised device can't reach everything? (Network segmentation and firewall policy's job — see 05-01: Firewall Concepts & History)
Is the traffic itself free of malicious content once it's decrypted at the other end? (Application-layer security, intrusion detection, etc.)

A VPN is one important layer in a defense-in-depth strategy — it protects data in transit — but it doesn't replace endpoint security, strong authentication, network segmentation, or any of the other controls covered throughout this course. Treating "we have a VPN" as equivalent to "our remote access is secure" is one of the most common and consequential misconceptions in network security.

📌 Key Takeaways¶

A VPN protects data in transit between tunnel endpoints — it has no visibility into or control over what happens before encryption or after decryption.
Weak/misconfigured encryption (outdated ciphers, static keys, weak pre-shared keys) can undermine a VPN even though the underlying protocol is sound.
DNS leaks expose which hostnames a client visits, even when the actual traffic payload stays encrypted, if DNS queries aren't routed through the tunnel.
IP leaks (from tunnel drops without a kill switch, IPv6 gaps, or browser side-channels) can expose a client's real address despite an active VPN.
Split tunneling creates a bridge between trusted and untrusted networks on the same device — a major practical risk that doesn't require breaking the VPN's cryptography at all.
Endpoint compromise (client or server) defeats the VPN entirely, because the attacker operates at a point where data exists in plaintext.
A VPN is a transit-security control, not a substitute for endpoint security, strong authentication, network segmentation, or the rest of a layered security strategy.