The 36th Article About VPN Split Tunneling

Written by David Meltzer

Over the years, I have heard many people talk about the pros and cons of VPN split tunneling. However, I had little interest in the debate until the day my IT team informed me that due to security policy I would no longer be able to use split tunneling. I was distraught. I was angry. Something had to be done.

At first, I thought I could just break out my credentials, including all my experience in the security industry, and declare to the IT team that I approve of split tunneling. As it turns out, all of my experience and expertise amounts to a hill of beans when it comes to overruling IT policy.

I am a scientist, though, and surely logic, reason, and an overwhelming amount of research could convince them. So I set out on a mission to uncover the facts about split tunneling prohibition – why is it the policy of so many IT organizations? Does it make sense? What does the security community think?

There is nothing original I could say about this topic, but what I have done is the most comprehensive meta-analysis on the security world’s view of VPN split tunneling. Will it change my IT team’s mind? Let’s find out…

Introduction to Split Tunneling and Who Cares

In case you aren’t familiar with the concept of split tunneling, let’s start with a brief introduction. A VPN sends all the traffic destined for your corporate network over a secure encrypted tunnel. If split tunneling is disabled, that means that ALL traffic from your computer is going over that tunnel, and traffic destined for the Internet goes out from your computer, across the Internet to the corporate network, and from the corporate network to a destination on the Internet. Then, return traffic comes from that destination through the Internet, then back to the corporate network, and then back through Internet again, before finally reaching you.

When split tunneling is enabled, Internet traffic goes directly from your computer to the Internet and back without involving the VPN at all. Split tunneling also allows you to access other systems on your local network which is impossible if all traffic has go to the corporate network first, although this can be mitigated in some configurations.

The benefits of split tunneling are pretty clear: Faster access to Internet resources and unimpeded access to local network resources. If the VPN is geographically close to you and has much faster Internet pipes than where you are connecting from, then Internet speed may be a non-issue.

But, as home Internet speeds have gotten progressively faster, the ‘penalty’ of going through the corporate VPN has become more pronounced. The latency cost of split tunneling also becomes far more significant when users are connecting from around the world.

I conducted a very quick and small survey of users of an unnamed organization that disables split tunneling and asked the users to perform two bandwidth tests using speedtest.net: Once while connected and once while disconnected from their VPN, in order to judge the impact the VPN had on Internet connectivity. Six responses were received.

The download speeds while connected to the VPN ranged from 4.7Mbps to 9.3Mbps with an average of 6.5Mbps. The download speeds while not connected to the VPN ranged from 15.9Mbps to 55.0Mbps with an average of 26.1Mbps.

So can we all agree disabling split tunneling has a major impact on the use of Internet resources while connected to the VPN, at least for some organizations? Here’s what happens: Users disconnect the VPN to do things on the Internet. Then they reconnect. Then they disconnect. All this disconnecting and reconnecting costs time; it creates frustration; and it hurts productivity.

Meta-Analysis of Split Tunneling Opinions

I conducted a meta-analysis of existing split tunneling opinions in the security community. The methodology used was to conduct a number of Web searches to identify a meaningful set of articles (including blog posts, documentation references, technical notes, and email threads on public lists) written on the topic of split tunneling.

The sample of articles was collected without respect to whether each article was for, against, or neutral on the use of split tunneling. Thirty-five relevant articles were identified, all of which are listed in the reference section at the end of this post.

For each article, I reviewed the content. I classified the articles as either being in favor of disabling split tunneling, in favor of enabling split tunneling, or neutral on the topic. I also created a classification of reasons given for the security benefits of split tunneling in all articles and enumerated how frequently each article promoted those benefits, as well as the arguments against disabling split tunneling and how frequently those arguments were promoted.

Discussion of the Meta-Analysis

I learned a lot by reviewing these 35 articles. The top reason cited for disabling split tunneling is preventing PCs from becoming gateways to the corporate network. The general theme is that an attacker or malware could take over a computer and then directly jump from the computer to the corporate network across the VPN.

In rebuttal, most of the articles in favor of split tunneling point out that malware is going to jump across to the corporate network whether split tunneling is used or not, but those against noted that while that may be true, split tunneling makes it easier.

The second main benefit cited for disabling split tunneling is it keeps gateway security controls in place. In short, this concept is that all the investments that have been made to protect Internet traffic at the egress point of the network – content filters, DLP systems, antivirus gateways, antimalware gateways, etc., are bypassed with split tunneling turned on.

The main rebuttal to this argument is that if you really cared about that, you would need to prevent corporate assets from ever connecting to the Internet (sometimes called Forced Tunneling) without going through the corporate network. If a user is regularly surfing the Web without the VPN and only occasionally uses it, it seems to the detractors that you have done very little to actually protect those systems, and there is little to no value in doing so a mere minority of the time they use the VPN.

On the other side, those in favor of enabling split tunneling most often cited the higher performance network experience for users and reduced bandwidth usage on the corporate network as the biggest benefits. There was no disagreement on that point from the other side. Next was gaining access to local network resources while being connected to VPN. Those against split tunneling often rebutted that there are ways to enable local network access while not fully enabling split tunneling.

The reduced load on the corporate network was the next reason cited in favor of split tunneling. By routing all traffic through the network, several authors pointed out that substantial investments in bandwidth and network infrastructure would be needed to support that traffic.

There was quite a lot of discussion in the articles about the risks of split tunneling in older environments. Those against split tunnels included older articles, and those in favor said things like “Many of the reasons why that mentality exists are the fault of those original VPN technologies from decades ago, and have been resolved for quite some time”, “In many ways, I feel like VPN split tunneling is designed to solve problems from 5-10 years ago”, and “Most network admins developed their opinions regarding split tunneling based on their understanding of how VPN clients work, and in many (most?) cases these opinions were derived from issues that were extant in the early to mid 1990s and with non-Microsoft VPN clients.”

A few articles cited NIST Special Publication 800-53 – Security and Privacy Controls for Federal Information Systems and Organizations. This document, in revision 4, has the clearest guidance possible about the use of split tunneling:

BOUNDARY PROTECTION | PREVENT SPLIT TUNNELING FOR REMOTE DEVICES
The information system, in conjunction with a remote device, prevents the device from simultaneously establishing non-remote connections with the system and communicating via some other connection to resources in external networks.

Supplemental Guidance: This control enhancement is implemented within remote devices(e.g., notebook computers) through configuration settings to disable split tunneling in those devices, and by preventing those configuration settings from being readily configurable by users. This control enhancement is implemented within the information system by the detection of split tunneling (or of configuration settings that allow split tunneling) in the remote device, and by prohibiting the connection if the remote device is using split tunneling. Split tunneling might be desirable by remote users to communicate with local information system resources such as printers/file servers. However, split tunneling would in effect allow unauthorized external connections, making the system more vulnerable to attack and to exfiltration of organizational information. The use of VPNs for remote connections, when adequately provisioned with appropriate security controls, may provide the organization with sufficient assurance that it can effectively treat such connections as non-remote connections from the confidentiality and integrity perspective. VPNs thus provide a means for allowing non-remote communications paths from remote devices. The use of an adequately provisioned VPN does not eliminate the need for preventing split tunneling.

Conclusion

Clearly there are conflicting opinions on this topic. Having read all the opinions, I have a better appreciation now for the viewpoints on both sides of the issue. I started writing this article with a black and white perspective about the topic, but it is clear that IT organizations may be able to do a lot to satisfy users even if they don’t enable split tunneling – addressing bandwidth issues, making network upgrades, and providing means for local network access would delight users but not change the fundamental policy of leaving split tunneling disabled.

For those organizations driven by compliance requirements, such as the specific declaration in the NIST publication, it doesn’t matter if the security risk is real or perceived – the people who must be persuaded are not the IT team, but NIST.

For those driven primarily by security concerns, there are many with strong opinions that “most of these fears have not been confirmed by any scientific evidence”, “The bottom line is that split tunneling should not be considered a security risk”, and “It might turn out that the assumptions you made when deciding against split tunneling weren’t as valid as you thought, and that the perceived risks of split tunneling were overstated to the extent that split tunneling may no longer be an issue”. The logic from these authors makes sense to me and when truly and fully examined, I continue to believe that allowing split tunneling is the right choice for most organizations.

As a final word, I think this quote sums it all up quite well: “As in all things, the final approach that is taken is a trade-off between security requirements and usability for the users (aka the business requirement).”