VPN Split Tunneling

VPN Split Tunneling allows a user to VPN into the corporate network and pass data over the encrypted tunnel to the there while at the same time still talk to local resources and go directly to the internet. The alternative is to always tunnel and send almost everything through the VPN. The idea of always tunnel VPN is sacrosanct to many VPN admins and I believe it’s a requirement under NIST SP 800-53 rev3.

This issue comes up fairly often as a case of usability versus security. I’m not convinced that always tunnel buys you the security you think it does, and given the drawbacks to the user experience, perhaps it doesn’t need to be the default.

When always tunnel is used, you now need the bandwidth to bring in all remote traffic and send it right back out to the internet. Each download has a double penalty. On the other hand, most enterprises don’t have HTTP security at the desktop so this actually has a benefit of url and malware filtering.
If you don’t currently use the personal firewall to enforce the same outbound restrictions as the corporate firewall, always tunnel will cause more blocking while VPN connected. That could be a good thing as people will stay VPNed less often because they want to be able to connect to their ISP POP3 server.

In many scenarios always tunnel will mean the inability to access local resources like printers and file servers. There are often ways to allow the local subnet. But that only solves the home problem. Many VPN users are employees stationed at a customer site. They need (or at least want) to access resources on that network while VPNed in. For some that is exactly what they are trying to stop. The end uses will see always tunnel hurting their ability to work.
In many ways, I feel like VPN split tunneling is designed to solve problems from 5-10 years ago. Split tunneling would prevent the system from being managed by sub7. On the other hand, so would the personal firewall. Todays malware uses command and control that is outbound initiated and designed to hide in plain sight. Its going to connect outbound through your always tunnel VPN and out your firewall, and then get its answer back. If you have an IDS in the right places you might have a chance. If the connection is encrypted, all you can really tell is the computer talked to an IP that might or might not be suspicious.

Perhaps you’d be better off ensuring antivirus is working and up-to-date on all systems that connect via VPN.
If you’re starting a VPN for the first time, you have a chance to implement it with always tunnel with a lot less push back. That might be worth while if you have the bandwidth to support it. It is a much tougher to sell for an existing VPN connection implemented as a split tunnel.


  1. Hi Roger,
    What are your thoughts on running VMware with the host operating system running always tunnel and the guest operating system having local access and access to the Internet?

  2. It would be interesting to hear from someone who has done it.
    My kneejerk reaction when people bring up a guest image as a solution to a problem is ‘how will it scale’. Just who is patching the guest OS.

  3. Hi,

    One thing you’ve missed is secure application sharing. Features like WSAM (windows secure application manager) and JSAM (Java) on Juniper SA allow single applications to be shared via SSL encryption, which negates the need for ‘always tunnel’ and split tunneling (in certain cases). I know that F5 firepass does the exact same thing.

    For example JSAM works by listening on the loopback addresses (on the corresponding client port specified for the application server) for client requests to network application servers (configured on the appliance). It encapsulates the requested data and forwards the encrypted data to the appliance as SSL traffic.

    This is similar to tunelling, but instead of using an ACL type IP-based rule set, connections can be dynamic.

    Also, portal access over SSL VPN can provide access to shares, internal sites etc without installing client software or tunneling into the network.

Comments are closed.