Technical Analysis of CVE-2024-3661: The TunnelVision Vulnerability
TunnelVision, identified as CVE-2024-3661, is a network-layer vulnerability that allows an attacker with control over a local area network (LAN) to bypass Virtual Private Network (VPN) encapsulation. By leveraging DHCP Option 121 (Classless Static Routes), an attacker can manipulate the routing table of a target host, forcing traffic intended for the VPN tunnel to be routed through the local gateway unencrypted. This flaw resides not within the cryptographic protocols of the VPNs themselves, but in the inherent design of how operating systems prioritize routing instructions received via DHCP over those established by virtual network interfaces.
DHCP Option 121 and the Routing Hierarchy
Dynamic Host Configuration Protocol (DHCP) is used to assign IP addresses and network parameters to hosts. DHCP Option 121, defined in RFC 3442, allows a DHCP server to provide a list of classless static routes to a client. These routes specify that traffic for a particular destination subnet should be sent to a specific gateway rather than the default gateway.
The core of the TunnelVision exploit lies in the "longest prefix match" rule used by IP routing tables. Most VPN clients secure outbound traffic by creating a virtual interface and either modifying the default gateway (0.0.0.0/0) or creating two high-priority routes (0.0.0.0/1 and 128.0.0.0/1) to cover the entire IPv4 address space. However, a route provided via DHCP Option 121 that specifies a more specific subnet (e.g., a /24 or /32) will always take precedence over a /0 or /1 route. An attacker can push a route that covers the entire internet using multiple specific subnets, effectively "declawing" the VPN without the user's knowledge.
The Mechanism of Redirection
When a target device connects to a malicious network, the attacker-controlled DHCP server responds with a standard IP lease and a set of Option 121 instructions. To achieve full traffic interception, the attacker can provide routes for 0.0.0.0/1 and 128.0.0.0/1, pointing to the attacker’s own IP on the local subnet as the gateway. Because these routes match the specificity of common VPN "leak protection" routes but originate from the DHCP server (which many OSs treat as a trusted local configuration source), the OS inserts them into the routing table with a higher priority or as equivalent routes that supersede the VPN's tunnel interface.
# Example of a malicious DHCP configuration (dnsmasq) # Pushing routes for 0.0.0.0/1 and 128.0.0.0/1 to the attacker's gateway (192.168.1.5) dhcp-option=121,0.0.0.0/1,192.168.1.5,128.0.0.0/1,192.168.1.5
Once the routes are applied, the OS attempts to send packets to the attacker's gateway. The attacker then uses a tool like iptables to forward this traffic to the actual internet, acting as a Man-in-the-Middle (MitM). The user's VPN client continues to report a "Connected" status because the VPN's control channel (often UDP/443 or UDP/1194) remains active, and the client may still be sending "heartbeat" packets through the original tunnel, even though the bulk of user data is bypassing it entirely.
Operating System Vulnerability Matrix
The susceptibility to CVE-2024-3661 varies significantly across operating systems due to differences in how their network stacks prioritize DHCP-provided routes against those set by virtual NICs. Organizations maintaining VPNWG standards for secure enterprise connectivity must account for these variations when deploying remote access solutions.
| Operating System | Vulnerability Status | Notes on Implementation |
|---|---|---|
| Windows | Vulnerable | Respects DHCP Option 121; routes are often inserted with metrics that supersede VPN routes. |
| macOS | Vulnerable | The network stack automatically applies Option 121 routes, overriding tunnel interfaces. |
| Linux (Desktop) | Vulnerable | NetworkManager and dhcpcd generally apply Option 121 by default. |
| Android | Partially Vulnerable | Vulnerability depends on the specific Android version and vendor implementation of the DHCP client. |
| iOS / iPadOS | Not Vulnerable | Apple's mobile OS does not implement Option 121 in a way that overrides VPN routing. |
Exploitation Scenario and Data Exfiltration
Consider a user at a public Wi-Fi hotspot. The attacker sets up a rogue access point. When the user connects, the attacker’s DHCP server assigns the user an IP and injects the malicious Option 121 routes. The user activates their VPN, which establishes a tunnel. However, the OS routing table now looks like this:
- Destination: 0.0.0.0/1 -> Gateway: 192.168.1.1 (Attacker) - Priority 10
- Destination: 0.0.0.0/1 -> Gateway: 10.8.0.1 (VPN Tunnel) - Priority 20
Because the metric (or specificity) provided by the DHCP route is preferred, the traffic for any IP in the lower half of the IPv4 space goes to 192.168.1.1. The attacker can then perform packet inspection or strip SSL (if HSTS is not enforced) on the unencrypted traffic. Security professionals using Secably to perform routine vulnerability assessments can simulate this by configuring a test environment with a custom DHCP server to see if their corporate VPN clients correctly flag or block such route injections.
The danger is exacerbated for users relying on GProxy or similar tools for anonymity, as the user assumes their IP address is hidden. In reality, their true local IP is exposed with every packet sent via the rogue gateway, and the ISP (or the attacker) can see all destination metadata and unencrypted content.
Technical Mitigations and Workarounds
Mitigating CVE-2024-3661 is difficult because it targets the fundamental way OSs handle networking. There are several layers of defense, though each has significant drawbacks:
1. Firewall-Based "Kill Switches"
A robust VPN client should implement a kill switch using a host-based firewall (like Windows Filtering Platform or nftables) rather than just relying on routing table entries. The firewall should be configured to drop any packet whose destination interface is not the VPN's virtual interface, regardless of what the routing table says. This prevents "leaking" traffic out of the physical NIC.
2. Disabling DHCP Option 121
On Linux, users can modify their DHCP client configuration to ignore Option 121. This can be done in /etc/dhcp/dhclient.conf by removing classless-static-routes from the request statement. On Windows, there is no native GUI toggle to disable this, requiring registry modifications or group policies that are often impractical for mobile workers.
# Example snippet to ignore Option 121 in dhclient.conf
# Remove 'rfc3442-classless-static-routes' from the request list
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, host-name;
3. Use of IPv6
TunnelVision is currently described primarily as an IPv4 vulnerability because it relies on DHCPv4 Option 121. While DHCPv6 has similar mechanisms, they are not as widely implemented or trusted by OSs for primary routing. Forcing a network to use an IPv6-only tunnel can mitigate the specific IPv4 route injection described in CVE-2024-3661, although this may cause compatibility issues with legacy systems.
4. Network Isolation and Virtualization
Running the VPN and all sensitive traffic within a Virtual Machine (VM) where the host handles the physical connection can isolate the guest OS from the host's DHCP-pushed routes. The guest OS only sees the "internal" network of the VM hypervisor, effectively neutralizing the local network attacker's ability to manipulate the guest's routing table via DHCP.
Impact on Enterprise Security
The discovery of TunnelVision forces a re-evaluation of the "trusted network" model. Even when a VPN is "Always-On," the local network environment remains a high-risk vector. For administrators, the primary takeaway is that routing-based VPN security is insufficient. Security must be enforced at the filtering layer (Layer 3/4 firewall) rather than the routing layer (Layer 3 routing table). Without these protections, an attacker can silently bypass the VPN, rendering the encryption and tunneling features moot for the vast majority of user traffic.
Detection of this attack in the wild is non-trivial. It requires monitoring the local routing table for unexpected changes immediately following a DHCP lease renewal. Standard EDR tools may not flag these changes as malicious, as DHCP route updates are common in enterprise environments for legitimate purposes, such as directing traffic to local printers or file shares. Consequently, the burden of defense falls on VPN vendors to update their clients to use more aggressive firewalling techniques that ignore OS-level routing preferences in favor of strict interface binding.