Attackers can decloak routing-based VPNs

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.