Attackers can decloak routing-based VPNs

Original Article ↗ Hacker News Discussion ↗

Researchers describe a “TunnelVision” technique that lets an attacker controlling DHCP on a local network silently route VPN traffic outside the encrypted tunnel, using DHCP option 121 to install more specific routes than the VPN’s default gateway. Commenters argue over how serious this is: some see it as a long-known class of “malicious DHCP” issues that properly configured VPN firewalls or Linux network namespaces already mitigate, while others note it undermines a core promise of many consumer VPNs on hostile Wi‑Fi. The exchange also highlights uneven vendor support and mitigations across operating systems, with Android unaffected by design and many commercial VPN clients apparently relying on fragile “kill switch” implementations.

Attack mechanism and behavior

  • Core issue: a malicious DHCP server can use Option 121 (classless static routes) to push more-specific routes (e.g., 0.0.0.0/1, 128.0.0.0/1) that override a VPN’s default route and send traffic over the physical interface instead of the tunnel.
  • Discussion clarifies this is about both route specificity and the interface field: routes learned via DHCP are bound to the non‑VPN interface.
  • Result: traffic that users expect to be tunneled can be transparently decloaked and observed on the local network, while the VPN client still reports “connected”.

Threat model and feasibility

  • Attacker must effectively become the DHCP server on the victim’s L2 network (e.g., public Wi‑Fi, compromised home router).
  • Some point out this is a known class of “malicious DHCP” attacks and that any device using DHCP already implicitly trusts that environment.
  • Others stress that public/untrusted Wi‑Fi is a primary advertised use case for consumer VPNs, so being able to silently neutralize them is significant.

Mitigations and platform behaviors

  • Strong defense on Linux: separate routing domains via network namespaces or VRFs; only the VPN process uses the “real” routing table affected by DHCP.
  • Firewall‑based “kill switches”: block all off‑VPN traffic except to the VPN endpoint; this converts the attack from data leakage to denial‑of‑service on those routes.
  • Debate on a proposed “side-channel”: using blocked vs allowed traffic volumes to infer VPN destinations; several commenters consider this impractical/overstated.
  • Android reportedly doesn’t implement Option 121 and is therefore unaffected, at the cost of some networking features.
  • Other mitigations mentioned: static IP/gateway, disabling Option 121, DHCP snooping on switches, using dedicated VPN routers or travel routers, userspace network stacks.

Severity and VPN ecosystem

  • One camp calls this “nothing new”: any decent VPN with proper leak‑protection firewalling is already safe; clients doing only routing‑table tweaks are “broken by design”.
  • Another camp sees it as a genuine and underappreciated flaw, especially because many commercial VPN clients rely on fragile “kill switches” that react to tunnel state rather than enforcing strict network policy.
  • Some criticize sensational headlines and possible “CVE mining”; others welcome the detailed primer and see value in exposing misconfigurations and weak client designs.