Background

Virtual Private Network (VPN) protocols were developed to allow local area networks (LANs) to interconnect securely over the open Internet, and to allow remote workers to connect securely to their organizations' LANs. And so it was sufficient to control connection paths through routing. When a VPN provides the only route to a remote private network, routing errors don't matter very much. Misrouted packets just get dropped.

But users of VPN services aren't connecting to remote private networks. They're connecting through them, it's true, but ultimately they're connecting to sites on the open Internet. When VPNs connect, they generally take priority as the best route to the Internet. But the direct route through the physical adapter still exists, and it takes over if the VPN connection fails.

IPv6 is worse, for at least two reasons. First, the IPv6 address space is gigantic, so each device can have numerous routable IPv6 addresses that are globally unique. The default formalism for generating an IPv6 address combines a LAN-specific prefix with the device's MAC address. However, as a limited privacy measure, Windows, OSX, Debian and some other Linux distros do not route those fixed MAC-based IPv6 addresses outside LAN. Rather, they generate temporary IPv6 addresses that can be routed globally, and which change periodically whenever devices get new DHCP leases from their LAN routers.

Even so, all temporary IPv6 addresses of all devices on a given LAN have the same prefix, given by the address range assigned by the ISP. And so, at best, these temporary IPv6 addresses provide less privacy than traditional IPv4 addresses do. Devices change their IPv6 addresses, but each IPv6 address is device-specific. Worse, some ISPs are issuing small address ranges, or even individual IPv6 addresses. In those cases, there is virtually no uncertainty about address allocation to devices.

Second, VPNs typically hide ISP-assigned IPv4 addresses through routing and network address translation (NAT). But if a device has IPv6 connectivity, IPv6 traffic ignores all that. Indeed, until recently, OpenVPN could not even route IPv6 traffic, and most VPN services have not enabled IPv6 routing. And so IPv6 traffic is typically unaffected by VPNs. Furthermore, it's not enough for VPNs to just tunnel IPv6. Unless a VPN has provided a new IPv6 address, the address prefix identifies the user's ISP to webites and intervening Internet routers.

Also, unless a VPN server specifies a new DNS server, applications will continue using the default DNS servers. If those DNS servers are operated by (or even associated with) a user's ISP, queries to them can unmask the user, by correlating VPN entry traffic (seen by the ISP) and exit traffic (seen by the DNS server). The DNS server also sees which sites the user is accessing.

It's best either to use the VPN's DNS servers, or to specify trusted third-party DNS servers, and to reach them only through the VPN tunnel. It's also best to use firewall rules that pass traffic on the physical network interface only with the VPN server(s), and which restrict all other traffic to the VPN tunnel interface.

Unless the VPN has assigned a new IPv6 address, it's best to disable IPv6 on network adapters, and to use firewall rules that drop all IPv6 packets on all interfaces. Finally, unless other devices on the LAN need IPv6 connectivity, it's also prudent to disable and block IPv6 in the LAN router.

Over four years ago, Appelbaum and associates covered most of these issues in vpwns: Virtual Pwned Networks. And it's been over a year since Perta and associates reported in A Glance through the VPN Looking Glass: IPv6 Leakage and DNS Hijacking in Commercial VPN clients that about two thirds of the VPN clients that they tested leaked IPv6. By now, one would think that VPN clients prevented these sorts of leaks. Sadly, most do not.

IVPN provided funding and technical support for this work. But mirimir is responsible for all content.