What is Split Tunneling with Virtual Private Networks?

The quick definition: Split tunneling allows you to choose what traffic ends up being sent through your VPN, and which traffic is allowed to head to external destinations without encryption.

The "split tunnel" refers to a VPN tunnel – split tunneling only works if you already have a VPN tunnel set up on your Cisco Adaptive Security Appliance (or ASA). By applying a split tunneling policy to your ASA, you can train the VPN that only traffic destined for your internal network should go through the tunnel and all other traffic can go free, unencrypted and not through the tunnel.

A Quick Overview of Split Tunneling [VIDEO]

In this video, Keith Barker covers split-tunneling with VPNs. Keith explains what split tunneling is, when and why you'd want to use it, how to set it up on an ASA, and how to verify that it's working properly — all in service to keeping a VPN running fast.

What is a VPN?

A VPN, or virtual private network, is – as the name suggests – a virtual network that extends a private network across a public one. That means that even though data is flowing over public nodes, the packets are encrypted and users on the network are able to operate as though they are on a local private network.

Companies and organizations use VPNs to allow users access to internal resources no matter where those users are located or what connection to the internal servers they have.

What Does a VPN Provide?

VPN tunnels are great for remote access users. To visualize the benefits of a VPN, let's imagine a remote user named Bob and the internal network he's trying to reach. We'll call it 10.0.0.

Say Bob wants to access resources on the internal network, but his access to the network comes from the Internet. How can we get Bob securely connected to the internal resources securely?

Bob has a client on his machine that establishes a VPN tunnel to a VPN Gateway — like an Adaptive Security Appliance — and once he's connected to the ASA, he has access to the internal resources.

What Are the Benefits of a VPN?

The benefit of a VPN tunnel is threefold: authentication, data integrity and confidentiality.

We have authentication because we know that we've only set up the tunnel for people whom we trust. We have data integrity because we know the data can't get manipulated in transit. And because it's end-to-end encrypted, we have confidentiality: we know each packet is protected. Anybody eavesdropping on the internet won't be able to make sense of the packets that we're sending across.

And when all those benefits work together, Bob still has full access to his internal resources.

What Are the Downsides to Using a VPN?

One of the default consequences of using a full tunnel is that all packets sent by Bob are going to go through that tunnel. So, if Bob's going to a server that's located on the internal network, that's perfect. The traffic transits the tunnel, hits the ASA, the ASA decrypts the traffic, and then passes that traffic over to the server.

But what if Bob's trying to find his way to a website on the Internet? Maybe he's trying to get to CBTNuggets.com.

What happens then? By default, all the traffic that's intended for external, internet resources would have to transit the tunnel. If Network Address Translation (NAT) has been properly set up on the ASA and it's been trained to redirect that external traffic, it can send those packets properly. But that entire process involves a lot of overhead.

If our security policy allows it, we can implement a split tunneling policy, and it's really simple.

Here's what we do: with our VPN tunnel established, we train the VPN to recognize which traffic is destined for our internal network. We instruct it that only that traffic should transit the tunnel. Then we instruct it that all other traffic can go free, unencrypted without passing through the tunnel.

The whole concept of split tunneling is that you only tunnel some of your traffic based on destination and let everything else that's not meant for that destination go free and clear.

Why Would We Want to Set Up Split Tunneling?

At this point, you might be wondering why if you've got a perfectly good VPN keeping all your network traffic anonymous and confidential, you'd ever want to split that tunnel and send some of your packets in the clear. Why exactly would we set up split tunneling?

Why would we instruct a VPN client to only send traffic for our 10.0.0 network over the tunnel and send everything else in the free and clear?

One key reason is the overhead on the ASA running that tunnel. For example, let's say our user, Bob, is streaming a sporting event. Hypothetically, he would head out to the website that's hosting the event and getting a live or near- live stream from that web server.

If he does that through the tunnel, every packet that makes its way to Bob from the remote server has to follow the exact same path: it starts out in the internet, makes it to the ASA, gets encrypted by the ASA, and gets sent to Bob via the tunnel – all so that Bob can get his non-internal video stream.

Now imagine hundreds, even thousands, of clients doing that. If that's the case, the overhead and bandwidth utilization on that outside interface may just be too great to allow full tunneling.

So the primary reason to set up split tunneling is to lessen the overhead on the ASA itself.

Before Setting Up a VPN Split Tunnel Policy

Before implementing a split tunneling policy, we should think about what a client's traffic would look like. Before Bob connects to his VPN, he'd be able to go to the internet like he normally would. He can navigate to the websites he's used to connecting to.

Once Bob connects to the VPN and gets authenticated, he can see, visit and access internal resources – maybe a server on the inside network, 10.0.0.5 for example.

But at the default level, with his VPN running, Bob would no longer have access to external resources. It simply won't work because the NAT and the hairpin turn on the outside interface of the ASA isn't set up for that yet. To fix that, we can implement a split tunneling policy.

One thing you could do to investigate what the traffic is doing is from the user's perspective is to go to the details of the VPN client. Once there, go to Route Details: it will indicate that there's a full tunnel policy. If you've done nothing else with the VPN, it would simply indicate that all traffic is going through 0.0.0.0/0.

So now that we've seen what it looks like when it's not implemented, let's get into the nitty-gritty on how to go about setting a split tunneling policy.

How to Set Up a VPN Split Tunnel Policy

First of all, close and disconnect the VPN session you're working with. Then, head to ASDM so that we can implement the policy for this group that says we want to implement split tunneling policy.

Inside ASDM, go to the group that the particular user (Bob, in our example) is associated with and modify the properties of that group. On the left sidebar, expand the Advanced heading and select the Split Tunneling heading. From there, you can instruct the ASA that you want to implement a split tunneling policy.

Do that by selecting "Tunnel Network List Below," and then either create or point to a standard access list that points just to the networks that you want the tunneling to happen for. For example, a very simple default standard access list default could point to 10.0.0.0/24. If our internal network is the 10.0.0 network, this will capture all the traffic to those resources. Click okay to apply that change.

To check your work, head back to the client and launch the VPN client once again. Once in, with the tunnel established, all our internal resources should be accessible through the tunnel. And with the tunnel split, we should also be able to visit external resources through the Internet.

How to Verify a VPN Split Tunneling Policy

Now that we've written the split tunneling policy, it's important to verify that it's doing exactly what we expect, and not breaking in unexpected ways. If you head into the VPN client details again, the secured routes should indicate that the tunnel is securing only traffic headed to – for our example – the 10.0.0.0/24. It's important that not all traffic is being secured.

In effect, if these steps have all gone properly, you've implemented a split tunneling policy for the group that this user is a member of.

Another way to verify the results of your work is to use the Command Line Interface or the ASDM to verify the details of our existing connections for the VPN. In this case, use the show command "show vpn-sessiondb anyconnect".

This command will output a wealth of data. You'll see the user who is connected, the user's IP address, and more. Importantly, it can show you the group policy which governs the user's connection and which connection profile the user entered on.

Remember, it's on the group itself where we implemented the split tunneling policy for that user to tunnel traffic just to the 10.0.0.0 network over the VPN tunnel and everything else is free to go as it normally would out of his interface card to his default router and off to the internet.

Final Thoughts

With this information in hand, you should be equipped with everything you need to secure and encrypt internet-based traffic to your internal networks, but allow all other traffic to remain unencrypted and reduce the overhead and bandwidth utilization on your ASA.