Your operating system displays an active, encrypted virtual private network tunnel. The interface is up, the handshake status is healthy, and your desktop firewall shows a functioning kill switch. Yet every HTTP request, DNS lookup, and plaintext payload you transmit across the local coffee shop Wi-Fi flows directly to an attacker's rogue gateway in clear, unencrypted Ethernet frames.

This decloaking technique is designated as CVE-2024-3661, colloquially named TunnelVision. Discovered by security researchers at Leviathan Security Group, TunnelVision does not rely on zero-day cryptographic exploits or memory corruption. Instead, it weaponizes an administrative feature present in the Dynamic Host Configuration Protocol (DHCP) since 2002: DHCP Option 121 (RFC 3442, The Classless Static Route Option).

By injecting custom routing table entries during network configuration, an adversary sharing your local local area network (LAN) manipulates the fundamental routing rules of your operating system kernel, routing unencrypted traffic outside your VPN tunnel without breaking the tunnel connection itself.

[Target Application / Web Browser]
                 │
                 ▼
      [OS Kernel Routing Table]
      ┌─────────────────────────┐
      │ Route Rule Evaluation   │
      └───────────┬─────────────┘
                  │
      ┌───────────┴───────────────────────────────┐
      │                                           │
[Standard VPN Default Route]       [Injected DHCP Option 121 Routes]
  Prefix: 0.0.0.0/0 (Metric 1)        Prefix: 0.0.0.0/1 + 128.0.0.0/1
  Interface: tun0 (Encrypted)         Interface: wlan0 (Plaintext Physical)
      │                                           │
      │ (Ignored: Shorter Prefix)                 │ (Selected: Longest Prefix Match!)
      │                                           ▼
      ▼                             [Rogue Gateway / Attacker Wiretap]
[Secure VPN Gateway]                 (Full Traffic Inspection & Interception)

The Anatomy of TunnelVision: Longest Prefix Match Exploitation

To understand how TunnelVision circumvents traditional VPN protections, one must inspect the fundamental decision engine governing IP routing: the Longest Prefix Match (LPM) rule.

When an operating system forwards an IP packet, it consults its routing table to determine the outgoing network interface and next-hop gateway. If multiple routing rules match the packet's destination IP address, the kernel selects the rule with the most specific subnet mask (the longest prefix length), completely ignoring routing metrics and interface preferences.

Standard VPN implementations capture network traffic by establishing a default route:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.8.0.1        0.0.0.0         UG    50     0        0 tun0

A default route (0.0.0.0/0) matches all IPv4 addresses on the Internet, but it has a prefix length of zero bits (/0), representing the least specific match possible.

When a device associates with an untrusted Wi-Fi network, it broadcasts a standard DHCP Discover packet. A rogue DHCP server operated by an attacker responds with a DHCP Offer containing Option 121. Under RFC 3442, Option 121 allows the DHCP server to push arbitrary classless static routes directly into the client's routing table.

The attacker pushes two distinct routes covering the entire IPv4 address space:

  1. 0.0.0.0/1 via local rogue gateway 192.168.1.1 (covering 0.0.0.0 through 127.255.255.255)
  2. 128.0.0.0/1 via local rogue gateway 192.168.1.1 (covering 128.0.0.0 through 255.255.255.255)

Because /1 is longer and more specific than /0, every single packet destined for the global Internet matches the attacker's injected routes rather than the VPN tunnel interface. The operating system kernel routes the packets directly across the unencrypted physical interface (wlan0 or eth0), delivering cleartext data straight to the adversary.

+--------------------------+-----------------+-------------------+-----------------------+
| Route Entry              | Prefix Length   | Route Target      | Routing Precedence    |
+--------------------------+-----------------+-------------------+-----------------------+
| Default Route (0.0.0.0/0)| /0 (Broadest)   | tun0 (VPN Tunnel) | Overridden by /1      |
| Option 121 (0.0.0.0/1)   | /1 (Specific)   | wlan0 (Cleartext) | Selected (First Half) |
| Option 121 (128.0.0.0/1) | /1 (Specific)   | wlan0 (Cleartext) | Selected (Second Half)|
| Specific Host (/32)      | /32 (Exact)     | wlan0 (Cleartext) | Absolute Priority     |
+--------------------------+-----------------+-------------------+-----------------------+

Why Traditional Kill Switches Fail Against Option 121

Most commercial VPN client software includes a feature marketed as a "kill switch." However, the majority of legacy kill switches are designed to mitigate tunnel collapse, not routing table poisoning:

  • Tunnel State Monitoring: Many kill switches merely poll the status of the virtual network adapter (tun0 or TAP driver). If the VPN process crashes or the remote tunnel drops, the firewall blocks outbound traffic. Under TunnelVision, the VPN tunnel never collapses. The encrypted connection remains open, ping checks return success, and the status indicator remains green.
  • Default Route Enforcement: Other kill switches insert firewall rules binding traffic to the default gateway. Because the attacker's Option 121 routes operate as local subnet routes rather than replacing 0.0.0.0/0, the kill switch assumes the traffic is legitimate local network discovery (such as printing or local NAS communication) and permits egress.
  • Platform Susceptibility: Windows, Linux, Android, and macOS handle DHCP Option 121 differently. While Android natively ignores Option 121, Windows and most Linux desktop distributions automatically accept and apply RFC 3442 routes by default unless explicitly reconfigured.

Architectural Defenses: Neutralizing Route Injection

Eliminating the threat of TunnelVision requires moving beyond superficial route manipulation and implementing architectural network boundaries.

[Host Applications (Browser, SSH, Mail)]
                 │
                 ▼
     [Linux Network Namespace]  <── (Complete Isolation)
                 │
                 ▼
       [Virtual tun0 / wg0]
                 │ (Encrypted WireGuard Pipeline)
                 ▼
 [Physical Namespace: wlan0 / eth0] ──> [Encrypted Outer Packets Only]

1. Network Namespaces (OS-Level Isolation)

On Linux systems, network namespaces provide absolute containment against routing attacks. By running user applications within a dedicated network namespace that contains only the VPN tunnel interface (wg0 or tun0), the applications possess zero visibility into the physical network interface (wlan0). Even if a rogue DHCP server injects static routes into the physical routing table, applications inside the VPN namespace cannot resolve or route through those paths.

2. Policy-Based Routing (PBR) and Firewall Marks

Modern implementations of WireGuard (wg-quick) implement policy-based routing using firewall packet marks (fwmark):

# Direct all unmarked traffic to custom routing table 51820
ip rule add not fwmark 51820 table 51820
ip rule add table main suppress_prefixlength 0

By utilizing suppress_prefixlength 0 and enforcing strict routing table precedence via packet marks, the operating system overrides arbitrary local route entries, ensuring that packets generated by host applications are forcefully redirected through the cryptographic tunnel table.

3. Explicit DHCP Configuration Hardening

On workstations where network namespaces are unavailable, administrators should configure network managers and DHCP clients to discard Option 121 entirely. In /etc/dhcp/dhclient.conf, removing rfc3442-classless-static-routes from the request declaration prevents the operating system from querying or adopting rogue routes from untrusted gateways.

4. RiceGuard L3 Tunnel Isolation

VPNRice's RiceGuard protocol addresses route poisoning attacks at the kernel driver layer. RiceGuard establishes non-routable firewall filtering policies via kernel-level nftables hooks before the network interface accepts lease negotiation. Non-tunneled egress packets attempting to exit the physical network adapter towards non-local destinations are summarily dropped, ensuring total integrity regardless of malicious DHCP configurations on public access points.

Practical Security Checklist for Public Networks

When connecting to untrusted public networks or corporate guest portals, apply these operational defenses:

  • Audit Active Routing Tables: Before and after connecting to public Wi-Fi, run ip route show on Linux or route print on Windows. Inspect the table for suspicious /1, /8, or /24 static routes pointing to local LAN addresses.
  • Prefer Cellular Hotspots or Trusted Tethering: Where feasible, connect through authenticated cellular mobile hotspots rather than open, unauthenticated public Wi-Fi access points where DHCP rogue servers are easily staged.
  • Verify End-to-End Egress IP: Regularly verify that your public IP address matches your VPN provider's exit node using command-line diagnostic tools (curl https://ipinfo.io), ensuring your traffic is not quietly slipping past the encrypted tunnel interface.