Split Tunnel Insecurities

I really dislike corporate VPNs that don’t allow split tunneling—disconnecting from the VPN to print on a local printer, or access a local network attached drive, puts a real crimp in productivity. In the case of services reachable over both IPv6 and IPv4, particularly if the IPv6 path is preferred, split tunneling can be quite dangerous, as explained in RFC7359. Let’s use the network below to illustrate.

In this network, host A is communicating with server B through a VPN, terminated by the VPN concentrator marked as “VPN.” Assume the host is reachable on both 192.0.2.1 and 2001:fb8:0:1::1. The host, the upstream router, the network in the cloud, and the server are all IPv6 reachable. When the host first connects, it will attempt both the IPv6 and IPv4 connections, and choose to use the IPv6 connection (this is what most current operating systems will do).

The problem is: the VPN connection doesn’t support IPv6 at all—it only supports IPv4. Because IPv6 is preferred, the traffic between the host and the server will take the local IPv6 connection, which is not encrypted—the blue dash/dot line—rather than the encrypted IPv4 tunnel—the red dashed line. The user, host, and server will not realize traffic is being carried without encryption through the (assumed) untrustworthy network in the middle.

There are really only three ways to resolve this problem.

First, the VPN software could be configured to turn off split tunneling. This is a major inconvenience for the user, but it does block the IPv6 connection from being completed, forcing the host and server to communicate over the IPv4 connection.

Second, IPv6 could be turned off on all the host’s interfaces. Disabling IPv6 is, of course, not a happy solution to much of anything, but it does preserve split tunneling on the host, and keep traffic which should be secured inside the VPN tunnel.

Finally, the VPN software should be upgraded to support IPv6. This is the right solution, but it needs the support of the VPN vendor—something that will take more than just a local solution.

The bottom line is you need to be aware of this problem, and push your VPN provider to support IPv6 if they don’t already. This is one of those unintended consequences of having more than one transport running in a network.