Do this one weird trick to make VPN better for your employees

Photo by Dan Meyers on Unsplash

Most of our large, enterprise companies force their corporate-owned laptops to connect via VPN back to the mothership to access internal resources. However, they force all traffic (Netflix, WebEx, Office 365, etc.) to go through the VPN connection, usually so the traffic flows can be seen by their security perimeter.

But, with everyone and their brother, sister, cousin and pet working remotely, this means that all Internet traffic has to route back through the corporate Internet connections. That’s one reason why things may appear to be “slow” — your work traffic is using the same pipe that your coworker listening to Spotify is.

Here’s a picture!

Allow trusted services to be accessed directly but keep corporate control over everything else.

How can I “fix” this?

You can’t, but you can exclude specific traffic from being sent through your VPN tunnel. For instance, if your company uses Office 365 for email, there’s no reason that you can’t allow Office 365 traffic to go directly to the Office 365 data centers, instead of coming though your VPN. To do this, there’s a three-step process.

1. Use Netflow (or other data tool) to determine what apps are using the most bandwidth on your VPN. (optional — if you don’t do this, just make an educated guess)
2. Lookup the firewall settings for each app online.
3. Enable split-tunneling, either via IP range or DNS.

Step 1: Netflow/Dashboard Analysis

I pulled my sample data from our Meraki Dashboard. But, you could easily setup Netflow on your VPN concentrator and get a report of what your users are doing.

Looking at this report, we’re using a few things:

• Office 365: No brainer there, since our email/OneDrive/Sharepoint is all hosted at Microsoft.
• WebEx: As a Cisco Collab partner, we use WebEx all day, every day.
• Spotify: We like our tunes, no need to apologize for that.

One thing is NOT on this list that should be:

• Windows Updates: If you get your Windows Updates directly from Microsoft, this is one of the most impacting traffic flows you can exclude from your VPN.

If you don’t have this view of your traffic, I recommend setting up Netflow with Ntop. Free, easy, and you can start receiving actionable data within hours.

Ok, so now we know what we want to exclude: Office 365, WebEx, Spotify and Windows Updates.

A note about security: If your organization does “something” to these traffic flows that is required for security, compliance or policy, you may not want to bypass that particular application. This is all about trade-off: performance vs. a single chokepoint for traffic flow.

Step 2: Lookup firewall settings for each app.

Every mainstream application vendor provides some sort of firewall documentation for their application. Let’s start with Office 365, since that’s the beast of the bunch. We’ll start with OneDrive.

Office 365 URLs and IP address ranges

In this document, OneDrive is listed in the same category as SharePoint Online.

From here, the key information is under the Addresses column. We will collect the IP addresses and use them to create/update/modify an access-list called vpn-split. This isn’t specific to any particular firewall (although this looks Cisco-ish), but it’s applicable to practically any manufacturer.

access-list vpn-split standard remark SharePoint Online and OneDrive
access-list vpn-split standard permit 13.107.136.0/22
access-list vpn-split standard permit 40.108.128.0/17
access-list vpn-split standard permit 52.104.0.0/14
access-list vpn-split standard 104.146.128.0/17
access-list vpn-split standard 150.171.40.0/22
access-list vpn-split standard deny any

There’s another way to handle the split tunneling: via DNS. On a Cisco ASA, you define the list of domains that you want to be exlcuded from the tunnel, like so:

anyconnect-custom-data dynamic-split-exclude-domains spol_service_domains acme.sharepoint.com acme-my.sharepoint.com 

Why pick IPs over DNS and vice versa? As you can see, it’s WAY easier to specify a list of domains then it is to manage IP addresses. However, you get the tightest control over managing the IP addresses.

Here are the links for each of the other applications:

• Cisco WebEx: straightforward with both IP addresses and domain names clearly published.
• Spotify: This one is tougher. Spotify doesn’t publish a list of IP addresses, so there are three ways. One is trial and error (start a stream, capture the IP, lather/rinse/repeat), the second is DNS split tunneling (see the example above), and the third is an ASN lookup.
• Windows Updates: Once again, another tough one. Microsoft publishes a list of Windows Update DNS domains, however they don’t publish IP addresses other than every IP address range that Microsoft owns.

Step 3: Test & Activate Split Tunneling

We’ve compiled our list of applications, built our domain lists and/or IP ranges, now we’re ready to test. I highly recommend creating a VPN profile specifically for testing these flows since you don’t want to interrupt normal traffic, especially these days.

From here, it’s simple — enable an application for split tunneling, and run through the checklist:

• Do I see the intended traffic going directly to the Internet?
• Does my application work as expected?
• Is my other traffic still properly tunneled?

One it passes the test, enable the split-tunneling on your production tunnels and boom: less traffic going through your headend!

Next steps?

If you need assistance with traffic analytics, tunnel policy development or application validation, please reach out! We’re happy to help. Depending on the applications, there are some that will be easy to send out directly, and some that require some gymnastics.