Client VPN is Broken

Well, my new “about me” will have to wait…I want to talk about something I have been noodling on for a while.

 

Client VPN is broken.

 

In today’s world, consumer class internet is increasing in bandwidth at amazing (and alarming) rates, while maintaining some semblance of reasonable cost.  Meanwhile, businesses are still paying through the nose for lower bandwidth, because of the requirement for higher SLAs.

Given their already limited internet bandwidth, most businesses are hesitant to leverage full-tunnel VPN connectivity, especially given users’ desire to leverage high-bandwidth, internet-based applications on their company devices (Netflix, for example) while traveling.

However, businesses also want to protect their company assets by passing traffic through a (next-generation) firewall, to look for threats, malware, and inappropriate use, and can best do this by leveraging an always-on VPN.

This dichotomy in use cases inevitably leads to one of these strategies for client VPN:

1. Split-Tunnel, where only company traffic heads down the company VPN, and all other traffic goes out the local internet, or;

2. On-Demand VPN, which can be disabled by the user at any time.

The biggest problem with both of these methods?  User traffic is partially exposed, either by manual disabling of the VPN, or by their internet traffic heading out to the internet unfiltered by the company firewall.

Now, some IT admins may say, “Why does it matter?  We are protecting the access to the internal resources; if they get owned, we will find out when that tries to access an internal resource.”  My response?

That's a bold strategy, cotton...

Not all malware in today’s world executes immediately…either the user may not execute the exploited file until they are back on the company network, or the malware may have the ability to detect they are connected to a VPN, and wait until that VPN is offline.  Unless there is some sort of posture and network access control, like Cisco ISE, or “big iron” firewalls and/or IPSs separating the data center from the user network, the compromised machine may now have complete access to internal resources, leading to potential damage, either through destruction of resources, or exfiltration of data.

Clearly, (our way of thinking about) Client VPN is broken.  But how do we fix it?  I have an idea, which still allows for full-tunnel protection of traffic, but reduces the burden on the company’s limited bandwidth…but that will have to wait until a future blog post.

How do you approach Client VPN connectivity?  How do you balance client connectivity with security?

Leave a Reply

Name *
Email *
Website

17 − 3 =