Bypassing VPN Tunnels: How Routing Table Manipulation Leaks Your Traffic

TLDR: Researchers at Black Hat 2023 demonstrated two techniques, LocalNet and ServerIP, that force VPN clients to route traffic outside of their encrypted tunnels. By manipulating routing tables or spoofing DNS responses, an attacker can intercept sensitive data even when a user believes they are protected. This research highlights a critical design flaw in how many VPN clients integrate with host operating systems, leaving users vulnerable on untrusted networks.

VPNs are the industry standard for securing traffic on untrusted networks, but they are not the impenetrable black boxes many users assume. The core assumption behind a VPN is that once the tunnel is established, all traffic is encapsulated and encrypted. Research presented at Black Hat 2023 by Nian Xue, Yashaswi Malla, Zihang Xia, Christina Popper, and Mathy Vanhoef shatters this assumption by showing that the host operating system’s routing table is often the weakest link in the chain.

The Mechanics of the Leak

The research identifies two primary attack vectors: LocalNet and ServerIP. Both techniques rely on the fact that VPN clients must interact with the host OS to manage traffic flow. When a VPN client connects, it modifies the system routing table to ensure that the default route points to the virtual tunnel interface, typically tun0. However, to maintain local functionality like printing or casting to a local device, VPN clients often add specific exceptions to this routing table.

The LocalNet attack exploits these exceptions. If an attacker creates a malicious Wi-Fi access point, they can advertise a local network range that overlaps with the target's expected local environment. Because the VPN client prioritizes these specific routing rules over the default tunnel route, the client sends traffic destined for the attacker's network directly over the physical interface, bypassing the VPN tunnel entirely.

The ServerIP attack is even more surgical. It targets the VPN client's connection process. Before a secure tunnel is fully established, the client must resolve the VPN server's IP address. By spoofing the DNS response for the VPN server, an attacker can redirect the client to a controlled IP address. Once the client attempts to connect to this spoofed address, the attacker can manipulate the routing table to ensure that traffic intended for the real VPN server is instead intercepted or dropped.

Technical Implementation and Observations

During the demonstration, the researchers used hostapd to create a rogue access point and conntrack to manage connection states. The attack flow is straightforward for anyone familiar with standard network manipulation:

1. Set up a rogue Wi-Fi network with a known SSID.
2. Configure the access point to advertise a local network range that the victim's VPN client will treat as a trusted exception.
3. When the victim connects, the VPN client automatically adds a route for this range to the physical interface.
4. Inject traffic or intercept requests that fall within that range.

The researchers observed that many VPN clients fail to properly isolate traffic when these routing rules are applied. In the case of the ServerIP attack, the client is tricked into believing the attacker's machine is the legitimate VPN gateway. Even when HTTPS is used, the initial handshake often leaks the destination domain via the Server Name Indication (SNI) field, which is sent in plaintext. An attacker running Wireshark can easily capture these SNI fields to identify exactly which sites the victim is visiting, regardless of the encryption that follows.

Real-World Impact for Pentesters

For those of us conducting red team engagements or bug bounty research, these findings are highly actionable. If you are testing a client that uses a VPN, do not assume the tunnel is absolute. During a physical assessment or a Wi-Fi-based engagement, you can test for these vulnerabilities by monitoring the routing table changes when the VPN is toggled.

If you see routes being added for local subnets that you control, you have a direct path to intercepting traffic. This is particularly effective against users who rely on "always-on" VPN configurations, as they are often the most susceptible to these routing-based leaks. The impact is significant: you can perform man-in-the-middle attacks, capture credentials, or simply map the user's internal network activity without ever needing to break the underlying encryption protocol.

Defensive Considerations

Defending against these attacks requires a shift in how VPN clients handle routing. The most effective defense is for the VPN client to implement strict traffic filtering based on the process that generated the traffic, rather than relying solely on destination IP addresses. By using features like fwmark on Linux, developers can ensure that only traffic originating from the VPN process is allowed to bypass the tunnel, while all other traffic is dropped if it attempts to leave via the physical interface.

For end users and administrators, the recommendation is to ensure that VPN clients are configured to block all non-tunnel traffic, especially when connected to public or untrusted Wi-Fi. While this can occasionally break local network features, it is the only way to guarantee that no traffic leaks outside the encrypted path.

VPN security is often treated as a solved problem, but this research proves that the integration between software and the underlying network stack remains a fertile ground for exploitation. As we continue to rely on these tools, we must demand that vendors prioritize secure routing configurations over the convenience of local network access. If you are building or testing these systems, start by auditing the routing table and verifying that your traffic is actually going where you think it is.