How to prevent IPv6 VPN breakout

Enterprises unaware of the role IPv6 plays on remote users’ devices run the risk that these machines might access banned sites despite using VPNs that are meant to restrict what they access.

This hole stems from the fact that some of these remote-access VPNs are configured to inspect and apply security controls only to IPv4 traffic as it passes through a VPN concentrator without enabling similar protections for IPv6 traffic.

This leaves IPv6 traffic free to access the Internet directly without those controls being applied. Known as IPv6 VPN breakout, the issue is well known yet often remains overlooked.

There are solutions for IPv6 VPN breakout, but the first step is to understand it in order to appreciate its importance.

Why IPv6 VPN breakout is overlooked

Many enterprises do not realize how often IPv6 is being used on devices that access their networks via VPN. Phones, tablets and laptops used for remote access to corporate networks commonly support IPv6 as do broadband and cellular services they might use to access the internet.

As a result, enterprises often don’t recognize IPv6 as a security factor. They configure their VPNs to inspect only IPv4 traffic, which can leave mobile devices free to access IPv6 sites that could prove dangerous to business networks, devices and data.

The way IPv4 protections work is, once the VPN has been established, the VPN concentrator inspects traffic bound for the internet and blocks traffic bound for destinations judged out of bounds by the policies the enterprise has configured. (See Figure 1).

Network World / IDG

Most corporate VPNs enforce what is called no split-tunneling to enhance security by forcing all IPv4 connections to traverse the VPN.  With no split-tunneling, once a VPN connection has been established, remote devices cannot make a separate connection to the internet at large.

This is typically done by advertising an IPv4 default route (0.0.0.0/0.0.0.0) over the VPN tunnel to the VPN client. This IPv4 default route is inserted into the routing table of the VPN client, represented in Figure 1 as the red field on the laptop screen. Therefore, when the end-user has the VPN running, all their connection attempts to IPv4 websites hairpin through the corporate intranet for inspection.

The security issue is that corporations often don’t apply the no split-tunneling settings on the VPN to include the IPv6 default route that is also in the VPN client routing table (::/0), represented in the diagram by the blue field on the laptop screen. That leaves IPv6 traffic with a direct path to the internet, thus bypassing any corporate internet-perimeter security measures.

Enterprises should face the fact that they already have IPv6-capable devices on their networks and in the hands of their mobile workforce so they should take an active approach to removing this security weakness.

How to prevent IPv6 VPN breakout

The recommended approach that yields the best result is to take control of the situation by enabling IPv6 on the VPN and in the corporate perimeter.  Enterprises should start to enable IPv6 connectivity on their Internet perimeter and then establish IPv6 connectivity to their VPNs.  Modern enterprise perimeter firewalls and their VPN software are already capable of using IPv6, it just needs to be enabled and configured. When it is, the traffic flow would look like it’s depicted in Figure 2.

Network World / IDG

A second option is using a VPN client that prevents IPv6 leaks on its own. For example, Cisco’s AnyConnect client paired with Cisco’s ASA security appliance can control how split-tunneling is configured on IPv6-enabled clients. Similarly, Palo Alto Networks GlobalProtect VPN and the Fortinet SSL VPN FortiClient are IPv6 capable. It is just a matter of enabling IPv6 and controlling it with the VPN policies.

Unfortunately, the approach some organizations take is to break the IPv6 connectivity when the VPN tunnel is established. In this case the VPN server advertises the IPv6 default route (::/0) to the VPN client’s routing table directing all IPv6 connections through the VPN tunnel.  However, when the VPN and the corporate internal network are IPv4-only, then all IPv6 connections are dropped. An enterprise shouldn’t advertise this IPv6 default route if they don’t have IPv6 connectivity to the VPN because it would cause application-connectivity problems for all VPN clients trying to access applications that use IPv6. Users who need to access IPv6-enabled sites would initially experience failed connections, then delay as the client engages fast-fallback to IPv4.

A third option would be to enlist the domain name system (DNS) to prevent IPv6 VPN breakout. In this case, the IPv4-only VPN would be left in place, but all DNS address resolutions would be forced down the tunnel. IPv6 DNS queries would be squelched, but IPv4 queries would succeed.

This approach could have downsides by making some IPv6-capable applications perform poorly as the IPv6 DNS resolutions and connection attempts timeout and fallback to IPv4. This also makes troubleshooting application problems more difficult because the IT administrator needs to look for applications that may be using IPv4 and/or IPv6 and try to isolate the problem to DNS, connectivity, VPN policies, and VPN client configuration.

The longer enterprises wait to build out IPv6-capable corporate remote access VPNs, the worse the IPv6 VPN breakout problem gets.  End-user devices will increasingly use IPv6 and less-and-less IPv4 traffic will come back through the corporate VPN.  Enterprises should be aware of the IPv6 VPN breakout problem and work to actively take steps to enable IPv6 on their Internet perimeters and for their remote access VPNs.