VPN Split tunnel pros and cons (especially for high bandwidth applications)

[kpinkham]

Looking for feedback on the advantages and disadvantages of VPN split tunneling. What are the security risks in using a split tunnel and how do they weigh against resource usage on the concentrator especially in high bandwidth consumption applications like video and streaming. Found the comments regarding IPV6 in the post below very interesting, thanks.

https://community.isc2.org/t5/Industry-News/Remote-Access-VPN/m-p/4527#M478

[Badfilemagic]

Split tunneling can, of course, reduce the cost of bandwidth for your organization.  Cost is one of the main engineering constraints and can't be discounted, but this is a security board, so you'll get a security answer.

If you split the tunnel on the remote endpoint, you have two (or more) data paths.  You're probably considering "send data for the corp network over the VPN and send everything else to the internet".  That provides you, essentially with a default route to your default gateway and then specific routes for your internal subnets pointed at the virtual tun/tap device which exists for the VPN.

From a security standpoint, you've essentially punched a hole in the perimeter which provides for the following:

1. Excepting other proxies, your ability to control traffic to cloud services that allow file sharing (e.g. dropbox, etc.) is potentially limited, as that traffic will leak outside the VPN tunnel and will not be routed through any edge devices you have in place to control that flow (app-aware firewall (NGFW), IPS, etc.)
2. The endpoint no longer benefits from those same perimeter devices in terms of protection from threats such as drive-by exploits, malware downloads, phishing sites, etc. Endpoint agents mitigate the risk here, but you then lack the defense-in-depth of multiple security layers for that remote endpoint
3. Assuming the endpoint is compromised, while the VPN connection exists the attacker has a foothold into the network. Essentially that compromised laptop becomes a pivot point from the internet into the trusted segment, bypassing the perimeter defenses.

If you're concerned about loads from streaming by VPN users, you probably just generally need to be concerned about loads from streaming.  You're paying for twice the bandwidth for the same stream if you send it over VPN, but maybe your users don't need to be streaming in the first place, depending on your organizational policies.  Again, this isn't to discount the cost constraint, or the load placed on the server. But weakening your security posture on purpose because you're concerned that people might be watching too much Youtube on their work machines when working remotely sounds like an HR issue and not a technical issue.

[dfcooktx]

A quick and brief comparison.

Pros:

Only traffic that needs to come across the VPN crosses and “non-work related” traffic will not consume VPN bandwidth

Latency will not suffer for end users while web surfing

Users get best performance of whatever ISP they are connected to

Cons:

Security should monitor all traffic on a remote client to protect against malware on the internet.

Auditing of all Internet access is not possible in this configuration if you require it from a compliance standpoint.

Users web browsing activity should be protected by encryption of the VPN connection in case they are in a coffee shop, public Wi-Fi or face  man-in-the-middle attacks.

[fwwidgit]

Split tunnelling and the risks around it are an industry debate for as long as I can remember (well since VPN clients have been around anyway).  Whilst a little dated, an article here, describes the debate, and the lack of agreement (although the author does lean in one direction)

Performance aside (and that is a big contributor to the decision), one of the main things I've encountered which tends to influence things is that of home printing.  Bypassing this on a forced tunnel, can be problematic at least.

Debates around malware protection / infection are spurious in my mind, as these will happen anyway, VPN or not.  

To a malicious / disgruntled employee however with a bit of technical knowledge, split tunnelling can be a very good way of enabling exfiltration of data.  (SSH tunnel through the "trusted" company endpoint to an internal corporate service, copy whatever data you want in and out - including rate limiting if you want to stay under the radar).   Quite a challenge to mitigate - although will freely admit that it's probably easier to copy the data from a share whilst in the office, and then on to your home NAS when at home (DLP solutions don't tend to look at network file shares ...)

There are methods to mitigate - and newer technologies such as CASBs may help, although increasing levels of paranoia = more expensive.

My personal opinion though ?  Protect the data - not the device.  Ensure your access controls / monitoring etc over your corporate and customer data is appropriate according to it's level of confidentiality (don't spend too much time protecting stuff people can Google).  At that point, the debate around split tunnelling is largely a moot point !

[dfcooktx]

Remember the main purpose of a VPN is to protect the confidentiality of the data in transmission and to a certain degree it's integrity.  If your primary use case for a remote users connection is to provide a secure transmission of confidential information then you would obviously lean towards not utilizing a split tunnel VPN.

But fwwidget, you are quite right in that deciding to allow or use that configuration is a decision weighing usability and functionality vs security that  may be deciding factor.

If you need to monitor that endpoint more rigorously due to regulatory requirements, such as in the USA with regards to the processing and transmission of ePHI.  Then it's security that weighs in and split tunnel VPN is not a configuration suggested.  

[DHerrmann]

I've always thought that disabling split tunneling is a bit of a Security Theater type of thing. I think any of us can easily argue either side of this, but I think the security gains from split tunneling can also be had by good web filtering and other egress protections.

[4d4m]

Having done a fair bit in this space, here is some info:

The first thing to consider is the application and the user, which is not talked about much here. For example, if you are using a live event type application, such as Teams/Zoom live events, or you are shipping big updates say a full Windows 10 update, you may not have a choice but to use split tunnel to have acceptable performance. Especially in real-time applications - security won't be thanked for a poor/unusable live stream event.

The problem comes when the content not going via your VPN and direct to the internet is not fully protected and/or you cannot monitor or control it. It is hard to separate out say a stream for a live event from other traffic you want more control over. Especially as CDNs are involved and it is not quite clear which traffic is using the CDN and you have no control over that. For example, you may just want that single live stream, but other types of traffic go direct to the internet that you did not intend to, like chat.

The other end of the application is also important, some cloud services have security monitoring and control at the other end, so it may be acceptable to allow traffic not via your VPN because you can pickup the controls at the other end. Make sure your security operations can see the traffic either at your VPN or at the cloud service end.

There is another way. If you checkout what the likes of Microsoft, Palo Alto, Zscaler, etc. are doing the CASB (Cloud Access Security Broker) and especially the SASE (Secure Access Service Edge) space, you may be able to still have a full secured VPN or access to an intermediate point which decides what traffic needs to go where, is secured, and is distributed around the world if need be so more local to the end user.

Hope some of that helps.

[ChrisGrant]

Thanks 4d4m for this response. I've been looking into this as well, for the exact reasons you're stating.

Seems like there needs to be a discussion about the risk of split tunneling to specific destinations, for specific purposes, by exception, not by rule. Most of the articles and traditional guidance on this topic is 10-15 years old. "Thou shalt not split tunnel VPNs!" That guidance was fine when VPNs only had two settings: no split tunneling, and only split the tunnel for specific networks you want to run through the VPN. These days VPN capabilities are more robust and more capable, allowing for split tunneling for Zoom or Office 365, or other SaaS solutions, frankly. There's potentially less reason to push full SSL-enabled web traffic through a VPN to partner organizations where the controls have been evaluated and understood, with contracts to enforce them. Yes, partner compromises happen (ahem Target), so it's highly dependent on the situation, but it seems like we should be taking a risk-based approach and not be just repeating dated dogma.

[vt100]

It really comes down to this:

1. Are the users' PCs managed by your organization?

2. If the answer to [1] is a "Yes", how good is the endpoint managed protection?

3. Does your organization rely on the cloud-based traffic security solutions, (NetScope or alike)?

If your endpoints are not managed, or do not have adequate EDR/AV/Threat prevention , split tunneling will expand your attack surface dramatically.

If the endpoints are managed effectively, you can have split tunneling enabled without undue risks.

[4d4m]

Interesting update for those using Teams...

If you use Microsoft Teams Live Events, the CDN (Content Delivery Network) you need to allow includes websites like pampers and slack, plus many other Azure sites. So if you rely on central website content filtering and split tunnels, you are opening up more than maybe your thought.

Adam