Skip to main content

Guide to Optimising Network Traffic for Cloud Services

This guide describes how agencies can reduce remote workers’ dependence on their agency networks and improve performance by reconfiguring their VPN from forced tunnel to inverse split tunnel architecture.

Purpose

This document provides technical advice for agencies, IT Security Managers and network engineers managing network capacity for remote workers. 

It’s intended for agencies that already have remote workers with VPN access from agency-managed devices who may be experiencing problems with reliability or performance when accessing cloud services.

Context

Agencies can experience performance and reliability issues that affect remote workers.

This can occur as a result of heavy use of cloud productivity applications being routed through an organisation’s corporate network by users connecting over the organisation’s Virtual Private Network (VPN).

High-volume personal traffic, such as music or video streaming, can also create additional load on your network.

Requiring all network traffic from remote users to traverse your agency network also creates a single point of failure. This can block remote workers from accessing cloud applications that they could otherwise continue using.

Inverse split tunnelling

In most cases there is little security benefit from routing public cloud traffic through internal networks and proxies. VPNs can be configured to allow defined network traffic directly between user devices and approved cloud services without increasing risk to your information or organisation. 

Examples of high traffic public cloud services that should be considered for inverse split tunnelling include:

  • productivity applications — such as Microsoft Office 365, Microsoft Teams, Zoom and Skype for Business
  • music or video streaming services — such as YouTube and NetFlix.

Assumptions

This guide assumes that you already have:

  • a functioning VPN capability
  • secure end-user devices with a VPN client, host-based firewall and up-to-date anti-virus, and
  • the ability to remotely manage end-user devices and push policy and configuration updates.

Optimising network traffic

VPN Forced tunnelling

The most common configuration of VPN deployments is forced tunnelling. This is where all network traffic from your end-user devices must route back to your agency network through the VPN. Connections to cloud services are then routed back to the Internet.

This is often done in order to monitor and control network activity from the end-user device. This architecture is recommended for organisations that have not yet begun using cloud based productivity or business applications. Where an organisation makes extensive use of cloud services this architecture can impose unnecessary reliability and performance degradation.

Diagram 1: Forced-tunnel VPN

A forced tunnel VPN diagram describing the flow of network connections in a forced-tunnel architecture

See a larger version of the Forced-tunnel VPN diagram (PNG 40KB)

Read the detailed description of diagram

This diagram describes the flow of network connections in a forced-tunnel architecture.

On the left is a laptop representing an end-user device, and a cluster of computers representing a cloud service. The end-user device and cloud service a represented as being located on the Internet.

On the right is a box representing the boundary of an agency internal network. This box contains a firewall, and computers representing a VPN concentrator, a proxy server and multiple on-premise business applications.

Lines are drawn representing a series of network connections. The first connection is from the end-user device, passing through the Internet and agency firewall, terminating at the VPN concentrator. This line is labelled encrypted VPN.

Two unlabelled connections start at the VPN concentrator connecting to the proxy server and on-premise business applications. The last line, labelled Encrypted TLS, starts at the proxy server and passes through the firewall and across the Internet to the cloud service.

This architecture has several limitations:

  • Your organisation’s network becomes a point-of-failure for staff accessing cloud services. If there is an issue with Internet access through your network, people working remotely will be unable to access cloud services.
  • The bandwidth or packet forwarding capacity of your organisation’s Internet connection may cause performance issues.
  • Remote users may find that some cloud services do not function correctly with traffic forced through a VPN.

Inverse split tunnelling

Inverse split tunnelling is a VPN configuration where network traffic from the end-user device (EUD) to approved cloud services is allowed directly and does not traverse the VPN or your corporate network.

We do not recommend full split tunnelling. This allows all Internet traffic to bypass the VPN and could allow an attacker on the Internet to access your agency’s internal resources through the end-user device.

Diagram 2: Inverse split-tunnel VPN

A diagram of a Inverse split tunnel VPN diagram describing the flow of network connections in an inverse split tunnel architecture.

See a larger version of the Inverse split-tunnel VPN diagram (PNG 40KB)

Read detailed description of diagram

This diagram describes the flow of network connections in an inverse split tunnel architecture.

On the left is a laptop representing an end-user device, and a cluster of computers representing a cloud service. The end-user device and cloud service are represented as being located on the Internet.

On the right is a box representing the boundary of an agency internal network. This box contains a firewall, and computers representing a VPN concentrator, a proxy server and multiple on-premise business applications.

Lines are drawn representing a series of network connections. The first connection is from the end-user device, passing through the Internet and agency firewall, terminating at the VPN concentrator. This line is labelled encrypted VPN.

A second connection starts at the VPN concentrator and terminates at the On-premise Business Applications. A third and final connection, labelled Encrypted TLS, starts from the end-user device, connecting to the cloud service, passing only through the Internet cloud.

There are several aspects to inverse split tunnel configuration:

  1. Network routing tables
  2. VPN Policy configuration
  3. Firewall configuration
  4. Type of network traffic 

Depending on your VPN product you may need to configure any or all of these.

New Zealand Information Security Manual (NZISM) requirements

The NZISM defines split tunnelling as:

Functionality that allows personnel to access both a public network and a VPN connection at the same time, such as an agency system and the Internet.

The ISM requires that split tunnelling must be disabled when using a VPN from a mobile device, including laptops and workstations used out of the office.

The rationale is that a split tunnel can allow access to an agency’s systems from another network. This risk is addressed by the use of the inverse split tunnel and strong end-user device controls including host-based firewalling.

Diagram 3: Inverse split-tunnel Trust Domains

A diagram describing the trust domains of the inverse split-tunnel architecture.

See a larger version of the Inverse split-tunnel Trust Domains diagram (PNG 47KB)

Read the detailed description of diagram

This diagram describes the trust domains of the inverse split-tunnel architecture.

There are 4 boxes, each representing a trust domain. Three of the boxes are labelled Trusted. These contain the end-user device, cloud service and the agency internal network. The fourth box is labelled Untrusted and represents the public Internet, containing a generic web server.

Two lines representing network connections are drawn from the end user device, 1 connecting to the Trusted Cloud Service and the other to the VPN concentrator inside the agency internal network. Both lines are labelled Encrypted.

Two connections are drawn from the VPN Concentrator to the Proxy server and On-premise Business Applications within the agency internal network. A final connection is drawn from the Proxy server to the generic Web Server in the Untrusted Internet domain.

Importantly, no connections are represented from the end user device directly to any device in the Untrusted domain.

In this architecture the end-user device only connects to trusted environments and does not connect to, nor accept connections from, devices on the untrusted public network.

See also:

These guides can be used for any cloud service, not just Microsoft options.

Securing end-user devices

Host-based firewall

The VPN client or other host-based firewall on the end-user device must be configured to drop all connection attempts from the Internet. If you have end-user devices that do need to accept connections from the Internet, then the host-based firewall must be configured to only allow the minimum necessary access and to drop all other traffic.

See also:

Securing access to cloud services

You may have configured the cloud services you use to only allow connections from your own networks. You’ll need to configure cloud services to accept access from any Internet IP address. To mitigate the risk of unauthorised parties gaining access to your information in the cloud we strongly recommend the following additional controls.

Single Sign-On (SSO)

We strongly recommend that agencies which have an existing federated identity capability use this for managing users’ access to cloud applications. This ensures that the cloud service does not require separate management of user accounts, and may allow users to access cloud services without logging in if they have already logged in to the agency directory from their device.

Multiple factor authentication (MFA)

We strongly recommend configuring cloud services to require multiple factor authentication for all access. This reduces the likelihood of an attacker guessing or gaining access to your information in cloud services.

Logging and reporting

You’ll need to maintain visibility of who is accessing your information in the cloud. You should review access logs periodically and enable centralised logging where possible.

Configuring cloud services

Microsoft Office 365

Single sign-on

If your agency is already using Office 365 it’s likely that single sign-on is already configured.

Configuring single sign-on varies depending on how your Office 365 deployment has been designed so we can’t provide guidance for this.

Multi factor Authentication

Guidance for configuring MFA for Microsoft Office 365 

How to set-up multi factor authentication

VPN Configuration

Microsoft have provided guidance for configuring split tunnel access to Office 365 at the link below. They have also included step-by-step configuration guides from key VPN vendors.

How to quickly optimise Office 365 traffic for remote staff

Zoom

Single Sign-On (SSO)

Zoom provide configuration guides for enabling SSO with a wide range of directory solutions including Azure Active Directory, ADFS, Okta and GSuite / Google Apps.

Zoom configuration guide for Single Sign-On

VPN Configuration

Configure you VPN policy and routing to allow direct connections to the domains and IP addresses listed in the support document linked below.

Network Firewall or Proxy Server Settings for Zoom

See also:

NCSC UK — Software-as-a-Service security principles

Did you find what you are looking for?

Your feedback will help us improve this website.

Thanks, do you want to tell us more?

Do not enter personal information. All fields are optional.