When an operating system establishes a virtual private network connection, network administrators assume that cryptographic primitives dictate overall privacy. Modern ciphers like ChaCha20-Poly1305 and AES-256-GCM provide mathematical protection against eavesdropping on the physical wire. However, encryption algorithms never decide where a packet travels. That decision belongs exclusively to the kernel routing table.

In 2023, security researchers Mathy Vanhoef, Nian Xue, Yashaswi Malla, Zihang Xiao, and Cristina Nita-Rotaru disclosed a fundamental architectural flaw affecting nearly every consumer and enterprise VPN client: TunnelCrack. Documented under CVE-2023-36664 and CVE-2023-35838, TunnelCrack demonstrates how an untrusted local network or rogue Wi-Fi access point manipulates default routing rules to force target traffic outside the encrypted tunnel in plaintext.

Understanding how TunnelCrack operates requires examining the two core attack variants: the LocalNet attack and the ServerIP attack.

+-----------------------------------------------------------------------------+
|                     TUNNELCRACK LOCALNET ROUTE LEAK FLOW                    |
|                                                                             |
|  [Victim Device]                                                            |
|         │                                                                   |
|         ├── Destination: Public Target IP (e.g., 142.250.190.46)            |
|         │                                                                   |
|         ▼                                                                   |
|  [Kernel Routing Table Decision]                                            |
|         │                                                                   |
|         ├─► Route A: Default VPN Tunnel (0.0.0.0/1 via utun0)     Metric 20 |
|         │                                                                   |
|         └─► Route B: LocalNet Rogue Subnet (142.250.0.0/16 wlan0) Scope Link|
|                    (Longest Prefix Match wins / higher specificity)         |
|                                                                             |
|         ▼                                                                   |
|  [Unencrypted Physical Adapter: wlan0] ──────► [Rogue Wi-Fi Gateway]        |
|  (Cleartext Ethernet Frames Leak Outside VPN)   (Attacker Intercepts)       |
+-----------------------------------------------------------------------------+

The LocalNet Attack (CVE-2023-36664): Exploiting Subnet Routing Exceptions

The LocalNet vulnerability exploits a convenience feature implemented by most VPN applications: local network sharing. When users connect to a VPN at home or in an office, they often want to access local resources such as network printers, NAS storage, or smart TVs. To accommodate this, operating systems maintain direct link-scoped routes for the local subnet.

When a device connects to an untrusted Wi-Fi access point, the DHCP server hands out an IP configuration consisting of an assigned IP address, a subnet mask, and a default gateway. Under normal conditions, an RFC 1918 private range is used, such as 192.168.1.0/24. The kernel automatically adds a link-local routing entry:

192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.105

Because this route has scope link, the kernel knows that any packet addressed to 192.168.1.0/24 can be resolved directly via ARP or NDP without passing through an external gateway. To keep local network printing functional, the VPN client leaves this link route untouched or creates an explicit routing exception table.

An attacker controlling a rogue access point weaponizes this behavior by announcing an arbitrary public IP block as the local network. For instance, the rogue DHCP server can assign the victim an IP within 1.0.0.0/8 or 142.250.0.0/16 with a corresponding subnet mask of 255.255.0.0:

# Kernel installs rogue link-scoped route on physical interface
142.250.0.0/16 dev wlan0 proto kernel scope link src 142.250.10.45

When the victim opens a web browser or background service attempting to reach a server inside that IP block, the kernel evaluates its Forwarding Information Base (FIB). Under standard IP routing rules:

  1. The VPN interface typically advertises a default route (0.0.0.0/0) or paired routes (0.0.0.0/1 and 128.0.0.0/1).
  2. The rogue link route has a /16 prefix length, which is significantly more specific than the /1 prefix used by the tunnel.
  3. According to Longest Prefix Match (LPM) principles, the /16 route takes precedence.

As a direct consequence, the kernel forwards the unencrypted IP packet directly out of physical interface wlan0. The encrypted VPN tunnel is completely sidestepped, and the adversary intercepts HTTP requests, DNS queries, and cleartext payloads without triggering any connection alerts.

The ServerIP Attack (CVE-2023-35838): Weaponizing Gateway Routing Rules

While the LocalNet attack abuses subnet declarations, the ServerIP attack exploits the bootstrap requirement of the VPN protocol itself.

To transmit encapsulated packets across the Internet to a remote VPN gateway, the physical network adapter must know how to reach that gateway. If the VPN client routed all outbound traffic through its own virtual interface (utun0 or tun0), encapsulated UDP or TCP packets destined for the VPN server would be re-routed into the tunnel, producing an unrecoverable routing loop.

To prevent this recursion, VPN clients install a dedicated host route (/32 for IPv4 or /128 for IPv6) directed at the physical gateway before activating the virtual interface:

# Direct host route installed to reach VPN gateway via physical router
198.51.100.50/32 via 192.168.1.1 dev wlan0

The ServerIP vulnerability arises when the VPN server's endpoint address is resolved using untrusted DNS servers provided by the local network during connection initialization:

  1. When the victim initiates a VPN connection, the client issues a DNS lookup for the VPN provider's hostname (e.g., gateway.example.com).
  2. An attacker running a rogue DNS server on the local Wi-Fi returns the IP address of a target service they wish to spy on (such as an internal corporate portal or cloud API endpoint).
  3. The VPN client accepts this spoofed resolution and configures a host route directing all traffic for that target IP directly out of wlan0.
  4. Although the VPN handshake with that specific target IP fails, the victim application's regular traffic to that target is now permanently pinned to leak outside the encrypted tunnel.

Even if the VPN client uses a pre-configured IP address for the handshake, an adversary can spoof the DNS records of other public domains to match the known VPN server IP, causing any traffic directed to those destinations to exit unencrypted over the physical interface.

+-----------------------------------------------------------------------------+
|                      LOCALNET VS SERVERIP ATTACK VECTORS                    |
+------------------------+----------------------------------------------------+
| Attack Type            | Primary Exploitation Mechanism                     |
+------------------------+----------------------------------------------------+
| LocalNet               | Large public subnet masks via rogue DHCP           |
| (CVE-2023-36664)       | Longest Prefix Match overrides /1 tunnel routes    |
|                        | Abuses "Allow Local Network Access" features       |
+------------------------+----------------------------------------------------+
| ServerIP               | Spoofed DNS resolution during VPN handshake setup  |
| (CVE-2023-35838)       | Unencrypted host route (/32) routes outside tunnel       |
|                        | Prevents recursion by routing gateway outside VPN  |
+------------------------+----------------------------------------------------+

TunnelCrack vs TunnelVision: Comparing Routing Exploitation Vectors

It is critical to distinguish TunnelCrack from TunnelVision (CVE-2024-3661). While both exploit the operating system routing table to circumvent tunnel encapsulation, their attack mechanisms differ significantly:

  • TunnelVision relies explicitly on DHCP Option 121 (RFC 3442, Classless Static Route Option) to inject arbitrary routing table entries. Operating systems that do not implement Option 121, such as standard Android, are naturally immune to TunnelVision.
  • TunnelCrack requires no optional DHCP parameters. The LocalNet attack operates through standard subnet masks present in RFC 2132 DHCP messages since 1997. Because every networked operating system processes subnet masks, TunnelCrack affected iOS, macOS, Windows, Linux, and Android.

Operating systems evaluate routing tables strictly by prefix length rather than cryptographic context. If a packet matches a /16 or /24 route on a physical Wi-Fi interface, the kernel will never pass that packet to the virtual network adapter.

Longest Prefix Match Hierarchy in Kernel FIB:
┌────────────────────────────────────────────────────────┐
│  Host Route (/32): Specific Target IP      (ServerIP)  │  ◄── Highest Priority
├────────────────────────────────────────────────────────┤
│  Subnet Route (/16, /24): LocalNet Route   (LocalNet)  │  ◄── Overrides Tunnel
├────────────────────────────────────────────────────────┤
│  VPN Split Default (/1): 0.0.0.0/1 & 128.0.0.0/1       │  ◄── Standard Tunnel
├────────────────────────────────────────────────────────┤
│  Default Gateway (/0): 0.0.0.0/0                       │  ◄── Lowest Priority
└────────────────────────────────────────────────────────┘

Architectural Solutions: How Modern VPNs Neutralize Routing Leaks

Securing against TunnelCrack requires moving beyond simple routing table modifications. Modern VPN implementations enforce defense-in-depth through multi-layer kernel firewalls, network namespaces, and strict socket binding.

1. Packet Filter Kill Switch and Firewall Rules

A robust VPN kill switch must not rely on routing table priority alone. Instead, it deploys kernel-level packet filtering rules that drop any outbound packet leaving the physical network interface unless it matches the exact encapsulated transport socket of the VPN tunnel.

On Linux systems utilizing nftables, outbound traffic on the physical adapter is restricted strictly to the verified VPN endpoint:

# Restrict outbound physical interface traffic to encapsulated UDP packets
table inet vpn_filter {
    chain output {
        type filter hook output priority 0; policy drop;

        # Allow loopback and virtual tunnel traffic
        oifname "lo" accept
        oifname "rice0" accept

        # Allow only the encrypted tunnel endpoint on physical adapter
        oifname "wlan0" udp dport 51820 ip daddr 203.0.113.10 accept
    }
}

On Windows, the Windows Filtering Platform (WFP) enforces callout drivers at the transport layer, dropping unencrypted packets before they reach the network interface card. On macOS, packet filter (pf) anchors prevent any interface other than the virtual tunnel from processing non-VPN traffic.

2. Eliminating Local Network Sharing on Public Wi-Fi

Because the LocalNet attack relies on local network exceptions, secure VPN clients actively disable local LAN exceptions when connected to untrusted networks. When local network sharing is turned off:

  • The VPN client removes or overrides the local subnet route.
  • All non-loopback packets, including those destined for private subnets, are routed through the encrypted tunnel.
  • Even if a rogue DHCP server advertises a /8 subnet on wlan0, the firewall explicitly forbids direct delivery.

3. Network Namespaces and SO_BINDTODEVICE

On Linux and Android environments, network namespaces provide absolute isolation. By moving the physical network interface into an isolated namespace and keeping user applications inside the primary namespace where only the VPN tunnel exists, applications physically lack routing entries to the external Wi-Fi network.

Alternatively, processes can bind their network sockets directly to the virtual tunnel interface using SO_BINDTODEVICE:

// Force application socket to bind directly to virtual tunnel interface
setsockopt(sock_fd, SOL_SOCKET, SO_BINDTODEVICE, "rice0", strlen("rice0"));

When a socket is explicitly bound to a network device, the kernel overrides default routing table selection and directs payloads into the designated interface.

Verifying Tunnel Integrity Against Route Manipulation

Users and network administrators can audit whether their VPN configuration resists TunnelCrack vulnerabilities using standard diagnostic tools.

  1. Inspect Active Routing Tables: Before and after establishing a VPN session, query the system routing table to verify that no unexpected link-scoped or /32 host routes exist:
    ip route show table all
  2. Conduct Subnet Probing: Configure a test router to announce a public subnet (such as 198.51.100.0/24) as a local DHCP range. Connect the client device, initiate the VPN tunnel, and verify that traffic destined for 198.51.100.1 is dropped or routed into the tunnel rather than exiting the Wi-Fi adapter.
  3. Audit Local Network Sharing Toggles: Ensure that your VPN client provides an explicit option to disable local network sharing on public hotspots.

In the VPNRice client architecture, the RiceGuard protocol and Core Layer 3 tunnel engine integrate strict interface binding and active firewall rules. By disallowing unverified routing exceptions and isolating transport sockets from DHCP-pushed subnets, network communications remain strictly confined within the encrypted tunnel.

For users seeking comprehensive protection across multi-homed laptops, mobile devices, and desktop workstations, downloading the latest client from the official VPNRice Download page ensures automated protection against both TunnelCrack and TunnelVision route manipulation attacks.