/ THREATS — TUNNELVISION (VPN BYPASS) · CRITICAL

TunnelVision (VPN Bypass)

Your VPN says connected. Your traffic is leaking past it.

/ WHAT IT IS

What it is

TunnelVision — published as CVE-2024-3661 — is a way for someone on your network to route your traffic around your VPN instead of through it. The VPN app still shows a green “connected,” but chosen traffic never enters the encrypted tunnel at all.

It abuses a completely normal feature. When your device joins a network, the DHCP server that hands out your IP address can also hand out routes — using an option called option 121 (classless static routes). Your operating system simply obeys them. A rogue DHCP server on the network sends routes that are more specific than the VPN’s catch-all route, with the next hop pointed at the attacker.

There’s no exploit and nothing to “hack” — the OS is doing exactly what DHCP told it to. That’s what makes it so quiet: your VPN is up, your pages load, and your traffic is leaking past it.

/ THE ATTACK

How attackers do it

The attacker stands up a rogue DHCP server on the local network and races the real one. When your device asks for a lease, the rogue reply includes option 121 routes such as 0.0.0.0/1 and 128.0.0.0/1 — two halves of the whole internet, each more specific than the VPN’s 0.0.0.0/0, with the next hop set to the attacker’s machine. Traffic for those ranges follows the more-specific route, straight past the tunnel.

# Conceptual — a rogue DHCP server offers a lease that quietly ships extra routes.
# DHCP option 121 = "classless static routes." Next hop = the attacker's IP.
#   dest 0.0.0.0/1   via <attacker>     # lower half of the internet
#   dest 128.0.0.0/1 via <attacker>     # upper half
# Both are more specific than the VPN's 0.0.0.0/0, so the OS prefers them.

Because it rides on DHCP, it also slips past naive rogue-DHCP checks that only look at the server’s hardware address — the attacker can spoof the gateway’s MAC in the reply. It’s the DHCP-layer cousin of a rogue DHCP server and a route straight into a man-in-the-middle position.

/ DETECTION

How we detect it

A VPN can’t detect this from the inside — the traffic never reaches it. WifiThreatWatch watches the layer the attack actually changes: your operating system’s routing table. We read it and flag any route whose next hop is a device on your local network that is not one of your legitimate default-route gateways. Nothing on a normal home network routes your traffic through a random neighbor.

You can see the same table on Windows:

# List IPv4 routes that have a real next hop (not on-link 0.0.0.0).
Get-NetRoute -AddressFamily IPv4 |
  Where-Object { $_.NextHop -ne "0.0.0.0" } |
  Format-Table DestinationPrefix, NextHop, RouteMetric

# Healthy: the only NextHop is your router (e.g. 192.168.1.1).
# TunnelVision: extra routes (often 0.0.0.0/1 and 128.0.0.0/1) via a
# LAN address that ISN'T your router — that's traffic leaving the tunnel.

It’s false-positive-safe because we exclude every real default gateway — so a VPN’s own housekeeping route to its server (which goes via your gateway) never looks suspicious — and we account for machines with more than one network connection.

FREE FOREVERFree in every WifiThreatWatch install.
[ route_guard.py — Get-NetRoute IPv4 non-gateway next-hop watch ]
/ RESPONSE

How we stop it

The moment a route points your traffic through a non-gateway neighbor, you get a clear alert — named for the destination and the device your traffic is being sent to, so you know exactly what leaked and where. On a network you don’t control, the right move is to stop trusting it: treat it as hostile and disconnect.

WifiThreatWatch’s response tools let you cut over to a clean path — an encrypted, self-hosted VPN tunnel that isn’t at the mercy of the network’s DHCP — so “connected” actually means protected.

See the full Active Defense flow →

WITH SUBSCRIPTIONActive Defense + VPN response. Requires subscription (or the free 10-minute trial).

See it in action.
Download WifiThreatWatch.