TunnelVision: De-cloaking VPN Traffic via DHCP Option 121 (CVE-2024-3661)

CVE-2024-3661: Mechanism of the TunnelVision Vulnerability

CVE-2024-3661, identified as TunnelVision, is a fundamental design flaw in how various operating systems handle DHCP Option 121 (Classless Static Routes) in the presence of an active VPN connection. The vulnerability allows an attacker on the same local area network (LAN) to act as a rogue DHCP server and push specific routing table entries to a victim's machine. These entries force traffic destined for any IP address to bypass the VPN tunnel, effectively "de-cloaking" the user's activity. This attack succeeds regardless of the VPN protocol used—be it OpenVPN, WireGuard, or IPsec—because it exploits the underlying IP routing logic of the host operating system rather than a flaw in the encryption or the VPN software itself.

The Role of DHCP Option 121

DHCP Option 121 was introduced to allow DHCP servers to provide more complex routing information than just a single default gateway. While the standard default gateway (Option 3) sets the 0.0.0.0/0 route, Option 121 allows the definition of specific CIDR blocks and their associated next-hop gateways. In a typical TunnelVision attack, the rogue DHCP server provides the victim with a series of highly specific routes, such as 1.0.0.0/1 and 128.0.0.0/1, or even more granular /24 or /32 prefixes.

According to standard IP routing rules, the most specific prefix always takes precedence. Most VPNs function by creating a virtual network interface and adding a default route (0.0.0.0/0) with a lower metric than the physical interface's default gateway. However, a route pushed via Option 121 that covers a specific range (e.g., 8.8.8.8/32) is considered more specific than the VPN's 0.0.0.0/0. Consequently, the operating system routes traffic for that specific IP through the local physical gateway instead of the VPN's virtual interface, leading to data leakage onto the local network where the attacker is listening.

Technical Implementation of the Attack

An attacker executing a TunnelVision attack must be positioned on the same network segment as the victim to respond to DHCP Discover or Request packets. The attacker configures a DHCP server to offer an IP address and, crucially, the Option 121 field. Below is a conceptual representation of how an attacker might configure an ISC DHCP server to leak all traffic by splitting the internet into two /1 segments:

# Example isc-dhcp-server configuration for CVE-2024-3661
subnet 192.168.1.0 netmask 255.255.255.0 {
  range 192.168.1.100 192.168.1.200;
  option routers 192.168.1.1;
  # Option 121: format is <mask>, <destination>, <gateway>
  # Pushing 0.0.0.0/1 and 128.0.0.0/1 to the attacker's IP (192.168.1.5)
  option classless-static-routes 1, 0, 192, 168, 1, 5, 1, 128, 192, 168, 1, 5;
}

When the victim connects to the network, the OS consumes these routes. If the victim then initiates a VPN connection, the VPN client will install its own routes. However, unless the VPN client specifically looks for and clears Option 121 routes, the OS routing table will prioritize the /1 routes over the VPN's /0 route. Researchers and administrators often use VPNWG to audit these configurations and ensure that tunnel persistence is not compromised by such underlying OS routing behaviors.

Comparison of OS Vulnerability and Response

The impact of CVE-2024-3661 varies across operating systems due to differences in how their respective DHCP clients and networking stacks prioritize Option 121. The following table summarizes the behavior of major platforms when encountering rogue Option 121 routes during an active VPN session:

Side-Channel Leaks and Kill Switch Failure

One of the most critical aspects of TunnelVision is its ability to bypass "kill switches." Most VPN kill switches are implemented as firewall rules (e.g., using iptables or nftables on Linux, or Windows Filtering Platform on Windows) that block any traffic not originating from the VPN interface. However, the TunnelVision attack manipulates the routing table *before* the traffic reaches the firewall's filtering logic in a way that the OS believes the local gateway is the correct and intended path.

In many implementations, the kill switch only triggers if the VPN interface goes down. Since the VPN tunnel remains "up" and connected, the kill switch remains inactive, while the OS routing table silently directs the traffic out of the physical interface. This creates a side-channel where the user believes they are protected, but their traffic is transparent to the LAN attacker. For those conducting reconnaissance or infrastructure audits, tools like Zondex can be used to identify exposed services on a network that might be leaking data due to such misconfigurations, providing a broader view of the attack surface.

Advanced Exploitation: Traffic Redirection and Interception

Beyond simple de-cloaking, an attacker can use this vulnerability to perform sophisticated Man-in-the-Middle (MitM) attacks. By setting the gateway in Option 121 to the attacker's own IP address, they can capture all outgoing traffic using tools like tcpdump or Wireshark. If the traffic is unencrypted (HTTP, DNS, SMTP), the attacker has full visibility. If the traffic is encrypted (HTTPS), the attacker can still perform traffic analysis, observe SNI headers to see which websites are being visited, or attempt to downgrade the connection.

# Capturing leaked traffic on the attacker's machine
# Interface eth0 is the local LAN interface
tcpdump -i eth0 -n "not port 67 and not port 68"

The attacker can also selectively leak traffic. For instance, they might only push a route for a specific target, such as a company's internal authentication server or a known secure proxy. In scenarios where researchers use GProxy to anonymize their research activities, a TunnelVision attack could potentially reveal the researcher's true source IP to the destination server if the routing table is successfully manipulated to bypass the proxy's tunnel.

Mitigation and Defensive Strategies

Mitigating CVE-2024-3661 is challenging because it exploits a core function of the DHCP protocol and standard IP routing. However, several layers of defense can be implemented:

• Network Namespaces (Linux): Running the VPN and the applications requiring protection in a separate network namespace can prevent the host's DHCP-obtained routes from affecting the application's traffic.
• DHCP Snooping: On managed corporate networks, enabling DHCP snooping on switches can prevent rogue DHCP servers from operating on the LAN.
• Static IP Configuration: Users can bypass DHCP entirely by configuring static IP addresses and manual routes, although this is often impractical in mobile or public Wi-Fi environments.
• Firewall Hardening: Configuring the firewall to strictly allow outgoing traffic ONLY through the VPN's subnet or virtual interface, regardless of what the routing table suggests, can mitigate the leak. On Linux, this can be achieved with owner or cgroup matching in iptables.
• VPN Client Updates: Some VPN providers have begun implementing "route monitoring" that detects if new, more specific routes are added to the system routing table and alerts the user or attempts to override them.

The "Most Specific Route" Problem in Modern Networking

The core of this vulnerability highlights a long-standing architectural issue in networking: the lack of an authentication mechanism for DHCP-provided routing instructions. While modern OS features have improved security in many areas, the fundamental trust placed in the local network's DHCP server remains a significant pivot point for attackers. TunnelVision demonstrates that as long as the OS prioritizes specificity over interface "trust" levels, the integrity of a VPN tunnel can never be guaranteed solely by the VPN software itself. It requires a holistic approach involving both the OS networking stack and the firewall configuration to ensure that local network instructions cannot override the security policy established by the encrypted tunnel.