Skip to content ↓ | Skip to navigation ↓

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.

Download Bandwidth Connected to VPN

Download Bandwidth NOT on VPN

6.5Mbps

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.

Number of Articles

FAVORS DISABLING

FAVORS ENABLING

NEUTRAL

35

11

13

11

 

Security Benefits Cited For Disabling Split Tunneling Number of Articles
Prevents PC from becoming gateway to corporate 11
Gateway security controls enforced 7
Simultaneous access to corporate and Internet is bad 4
Prevents IP routing through client to corporate 2
Requirement of NIST SP 800-53r3 2
Windows Internet connection sharing risk 1

 

Arguments For Enabling Split Tunneling Number of Articles
Conserves bandwidth / Higher performance 12
Local network access 8
Less load on corporate network 7
Separation of corporate and private traffic 3

 

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).

 

Related Articles:

 

Resources:

picCheck out Tripwire SecureScan™, a free, cloud-based vulnerability management service  for up to 100 Internet Protocol (IP) addresses on internal networks. This new tool makes vulnerability management easily accessible to small and medium-sized businesses that may not have the resources for enterprise-grade security technology.

 

picThe Executive’s Guide to the Top 20 Critical Security Controls

Tripwire has compiled an e-book, titled The Executive’s Guide to the Top 20 Critical Security Controls: Key Takeaways and Improvement Opportunities, which is available for download [registration form required].

 

Title image courtesy of ShutterStock


References:

http://en.wikipedia.org/wiki/Split_tunneling

http://www.isaserver.org/articles-tutorials/configuration-security/2004fixipsectunnel.html

http://www.isaserver.org/articles-tutorials/configuration-security/VPN_Client_Security_Issues.html

http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/70917-asa-split-tunnel-vpn-client.html

http://www.dslreports.com/faq/15549

http://www.infosecisland.com/blogview/22859-Making-Sense-of-Split-Tunneling-.html

http://searchsecurity.techtarget.com/answer/Do-split-tunneling-features-make-a-VPN-vulnerable

http://blogs.technet.com/b/tomshinder/archive/2010/03/02/why-split-tunneling-is-not-a-security-issue-with-directaccess.aspx

http://www.juniper.net/techpubs/en_US/sa8.0/topics/task/configuration/secure-access-nc-split-tunnel-policies-defining.html

http://shadabahmed.com/blog/2013/08/11/split-tunneling-vpn-routing-table

http://www.insinuator.net/2010/11/the-case-foragainst-split-tunneling/

http://www.infosecblog.org/2010/05/vpn-split-tunneling/

http://isc.sans.edu/diary/Cyber+Security+Awareness+Month+-+Day+19+-+Remote+User+VPN+Tunnels+-+to+Split+or+not+to+Split%3F/9766

http://home.comcast.net/~uploader/vpn/Tutorials/Split%20Tunneling%20Concerns.pdf

http://vpnhaus.ncp-e.com/2013/01/03/making-sense-of-split-tunneling-part-1/

http://vpnhaus.ncp-e.com/2013/01/10/making-sense-of-split-tunneling-part-2/

http://support.vpnsecure.me/articles/frequently-asked-questions/openvpn-split-tunneling

http://seclists.org/educause/2012/q1/520

http://www.networksa.org/?p=385

http://blog.nhcomputerlearning.com/2009/09/09/avoid-using-split-tunneling-in-your-vpn-connections/

http://www.windowsnetworking.com/kbase/WindowsTips/Windows7/AdminTips/Network/ReduceWastedBandwidthonaVPNwithSplitTunneling.html

http://www.ciscopress.com/articles/article.asp?p=1218144&seqNum=3

http://www.digitalinternals.com/204/20130922/juniper-vpn-network-connect-split-tunneling-patch/

http://bilherd.mercury-cg.com/archives/44

http://blog.xtremeloaded.com/2013/07/09/what-you-should-know-about-vpn-split-tunneling/

http://vpncreative.net/blog/2012/07/23/understanding-split-tunneling-and-its-benefits/

http://www.miqrogroove.com/blog/2010/split-tunnel-vpn/

http://vpnhaus.ncp-e.com/2010/01/13/split-tunneling/

http://www.ivonetworks.com/news/2011/05/why-split-tunneling-with-directaccess-is-not-only-for-thrillseekers/

http://socpuppet.blogspot.com/2013/09/forticlient-split-tunnel-fortigate.html

http://blogs.technet.com/b/tomshinder/archive/2010/03/30/more-on-directaccess-split-tunneling-and-force-tunneling.aspx

http://blog.jeremyscott.org/?p=79

http://searchsecurity.techtarget.com/answer/Evidence-of-the-risks-of-split-tunneling

http://www.securitymanagement.com/library/000696.html

http://searchenterprisewan.techtarget.com/tip/Know-your-split-tunnel-gotchas

http://csrc.nist.gov/publications/nistpubs/800-77/sp800-77.pdf

Hacking Point of Sale
  • Clay

    This article had some great information but misses the point that the security in depth principle should not be thrown out the window simply because a user took an asset to their home network. Enforcing a VPN policy of no split tunneling allows for user mobility but maintains universal controls such as content filtering to protect end user computing platforms from malware as an example of a single control although there are others as well. While such network layer controls are not 100% effective they are one link in a chain of controls that reduce the likelihood of compromise and we all know that host based anti-malware solutions are by no means a silver bullet. This being said, I believe the author's intent was to (misguidedly) convince the reader of the lack of security threats from split tunneling. I would propose asking a better question. Specifically, what is the level of security commensurate to the data potentially at risk as a result of allowing split-tunneling and the resulting malware? If the benefits of improved Internet access speeds outweigh the risk to the data…then move forward but with the facts regarding potential exposure.

    • I appreciate the comment- that's one more vote for the DISABLE split tunneling side!

      I completly agree with you that the best question to ask (and the final word in the article I think alludes to the same thing) is what is best balancing the security value of disabling it against the business value of enabling it. I don't think I implied in the article there is no security benefit at all to be had by disabling split tunneling, but there are valid arguments and counter-arguments on both sides of this debate.

      The content filtering example you used IS valid – it is the second main benefit cited by those on your side of the debate. However those on the opposite side of the debate from you would argue that for remote users who are going to only use the VPN for an hour here and a few minutes there, believing that you get any better security from content filtering for 5% of the time and leaving that same system unfiltered for 95% of the time its not connected to the VPN is misguided. It would be akin to saying if I have a web filter for my company but I only turn it on from 9am-10am every morning – is that 1 hour a day better than 0 hours a day of filtering? Yes – but not much.

  • Clay

    Dave, you are correct that "Gateway Security Controls" is listed in the table above. However, not all readers may understand the correlation between the technical controls provided by disabling split-tunneling and the reference you have provided (unfortunately) and it could be misleading. Regarding an on-demand client based VPN (Vs. always on) and the transient protections, I definitely agree that this is of limited value if not enabled in an always-on manner. This too is a nuance that must be considered holistically in the context of a corporate data governance strategy and level of risk. Concluding that in general there is not much value from disabling split tunneling is simply inaccurate and based on a set of circumstances that may be true in your own case but not necessarily the same for all. Each organization must evaluate the unique aspects of their situation and be aware of all the facts before making a decision. As security professionals it is important that we educate in a manner that clear, fact based, and not tainted by our own personal motivations.

  • Julius

    Split tunneling extend the attack surface thus increases risks . Full stop. Free to use it or not, but it DOES make a difference in terms of Security as it places controls mainly on endpoint security rather than on more layers of infrastructure. Layers are less, security is hence decreased: as simple as that. GdL, CISSP #119159, CISM #1117240, CRISC #1106799.

    • I agree with your statement. I don't think anyone would argue using split tunneling is LESS risk than not – only that the difference in risk may be so small for some organizations that the benefits of it outweigh that risk. You make a good point about infrastructure vs. endpoint – depending on exactly what controls an organization has on those 2 areas will heavily influence what that risk-level actually is. e.g. if there is advanced malware detection on network but nothing on endpoint, you can clearly see the value of traffic passing through the network, whereas if there is malware detection on endpoints already that has comparable effectiveness then you may not be losing anything in that case. Of course if 95% of the time these devices aren't connected to the VPN anyhow that's a big problem relying on infrastructure controls – bigger than the issue of split tunneling.

      • Mikael

        This is of course only true if you use on demand VPN. If you instead at login, or even better, pre-login connect to the VPN you can enforce the security gateway set of rules a 100%. If you for example use a firewall to block the use of Dropbox, what good is it if you can use Dropbox as soon as you're not connected to the corporate Lan?

  • Eric

    I see/hear this same type of story over and over again. The fact is IA has zero interest in useability, efficiency, or productivity of users/workers. Though they will never admit it, it seems like IA personnel go out of their way to crush any kind of happiness we mere mortals might hope for. All they care about is controlling assets. You are wasting your time trying to convince them of anything else. Unfortunately, they are they ones deciding policy. Therefore, we are screwed.

  • Well, my institution has gone the other way – split tunneling is forced on. Weirdly, when I put in the VPN access request, I specifically stated that one of the reasons I wanted it was so that I could have an institutional IP and journals, etc. would recognise my access rights without having to log in repeatedly, and so that the ridiculously low 30 minute timeout for the library credentials wouldn't mean I'd have to log in again.

    But they gave me the AnyConnect client, which I hate because it randomly defocuses full screen windows when it's running in the background, and split tunnelling is on. Which means that I can only really connect to the university network, and my main reason for using it was invalid to begin with. So no one actually read my request, and my problem still isn't solved.

    Hoo-rah.

  • I have been using split tunneling feature with PureVPN but did not know how it worked. Great article!