What is VPN split tunnelling? How it works, benefits, risks & safety

Key takeaways

• Split tunnelling sends some traffic through the VPN and lets the rest go directly to the internet.
• The gain is capacity and latency. Backhauling all remote traffic through one concentrator is expensive and slow.
• The cost is visibility. Traffic bypassing the tunnel does not pass your inspection and logging controls.
• Safety depends on policy, not on the feature. Define what may bypass, then enforce it centrally.
• Split tunnelling is a remote-access decision. It does not apply to site-to-site connectivity.

Sending every remote worker's traffic through a central VPN concentrator made sense when the applications they needed sat in your data centre. Most of them no longer do, and backhauling everything through one choke point now costs latency and capacity for no real gain.

Split tunnelling is the response to that shift. It lets defined traffic reach the internet directly while everything else stays inside the tunnel, trading some visibility for performance. This guide covers how it works, the genuine security risks, and how enterprises should decide whether to enable it.

What is VPN split tunnelling?

Split tunnelling routes only part of a device's traffic through the VPN, so that traffic bound for internal systems takes the encrypted path while everything else reaches the internet directly.

Without it, a VPN operates in full tunnel mode. Every packet from the device travels to the VPN concentrator first, then out again. That gives complete visibility and control, at the cost of capacity and latency.

Split tunnelling changes the routing decision. Traffic bound for internal systems uses the tunnel. Traffic bound for public services does not.

The trade-off is straightforward and worth stating plainly. You gain performance and reduce concentrator load. You lose inspection of whatever leaves the tunnel.

Full tunnel vs split tunnel VPN

The two configurations trade the same three things against each other: visibility, performance and the capacity you have to provision.

Neither is inherently correct. Full tunnel is the safer default when you cannot rely on the endpoint. Split tunnel is the practical choice when you can.

How VPN split tunnelling works

The VPN client holds a policy defining which traffic is in scope. That policy can name destinations, applications or address ranges.

When an application opens a connection, the client checks the destination against the policy. Matching traffic is encrypted and sent through the tunnel. Everything else uses the device's normal internet path.

Two routing behaviours are common. Inclusive policies tunnel only what is listed and send the rest direct. Exclusive policies tunnel everything except a named list.

Administrators set the policy centrally in enterprise deployments. Users should not be choosing what bypasses inspection.

Types of split tunnelling

Four variants appear in enterprise clients, differing in how precisely they can target traffic:

• Route-based: Traffic is split by destination IP range. Simple to operate, but it cannot distinguish applications sharing a destination.
• Application-based: Named applications use the tunnel while others do not. More precise, though it depends on client support.
• URL or domain-based: Specific domains bypass the tunnel, commonly used for large software-as-a-service platforms.
• Inverse split tunnelling: Everything is tunnelled by default, with named exceptions sent direct. This is the safer starting position for enterprises. Inverse is the pattern most security teams should prefer. Default-deny is easier to defend than default-allow.
  
  

Benefits of split tunnelling

The case for split tunnelling is operational rather than defensive. Four gains account for most of it:

• Lower concentrator load: Only relevant traffic reaches the VPN, which reduces the capacity you must provision.
• Better application performance: Cloud services connect directly rather than making a detour through your data centre.
• Shorter paths for remote users: A worker in another country reaches a nearby cloud region without crossing continents twice.
• Resilience against concentrator failure: A VPN outage stops internal access but leaves cloud applications reachable.

These are operational gains rather than security ones. Split tunnelling makes a VPN cheaper and faster to run. It does not make anything more secure.

Risks and drawbacks of split tunnelling

Every risk here traces back to one cause: traffic you cannot see.

• Loss of visibility: Traffic outside the tunnel does not reach your proxy, DNS filtering or data loss prevention tools.
• Bypassed controls: Policies enforced at the network edge stop applying to whatever leaves directly.
• Endpoint exposure: A device sits on the corporate network and an untrusted local network at once. That bridging position is exactly what attackers look for.
• Weaker logging: Investigating an incident is harder when a portion of the traffic was never recorded.

The bridging risk deserves emphasis. CISA's guidance on network infrastructure puts segmentation and limiting unnecessary lateral communication at the top of its recommendations. Split tunnelling works against both unless the endpoint is controlled.

Is split tunnelling safe?

Split tunnelling is safe when the endpoint carries its own controls and the policy is centrally enforced. It is unsafe when it is used to avoid provisioning enough VPN capacity.

Three conditions make it defensible:

• Endpoint protection is present and monitored: Detection and response on the device replaces the inspection the tunnel used to provide.
• The policy is centrally set and audited: Users cannot add exceptions, and the exception list is reviewed on a cycle.
• Sensitive systems always tunnel: Anything carrying regulated or confidential data stays inside, without exception.

Where those conditions are absent, full tunnel remains the safer configuration.

Should enterprises enable VPN split tunnelling?

The honest answer is that most already have, and the question is how rather than whether.

• Enable it when remote staff mainly use cloud applications and endpoints carry managed detection tooling. The exception list should be short and reviewed.
• Avoid it when regulated data is handled remotely or endpoint tooling is inconsistent. Also avoid it if you cannot audit what bypasses the tunnel.
• Consider the alternative: Many organisations now supplement or replace traditional remote access with Zero Trust Network Access (ZTNA). It authenticates users and devices at the application level rather than extending network-level trust. Where ZTNA is on the roadmap, split tunnelling is a stopgap rather than a destination.

Whatever you choose, the underlying connectivity between sites is a separate decision. Split tunnelling is about remote access only.

How to enable VPN split tunnelling

Configuration belongs in the VPN client rather than the operating system. Most enterprise clients expose it as a policy pushed from a central console.

• Windows: Enterprise clients provide a split tunnelling policy in the management console. The older method of unticking the default gateway in TCP/IPv4 adapter properties still works. It applies per device, though, and cannot be audited centrally.
• iOS: Per-app VPN is the native mechanism. It maps named applications to the tunnel through a device management profile.
• Android: Enterprise clients support per-app VPN through work profiles, with the application list set by policy.

In every case, set the policy centrally. A device-by-device configuration cannot be reviewed, and it drifts.

Best practices for safe split tunnelling

These six practices keep the exception list defensible over time:

• Start from inverse: Tunnel everything by default, then add narrow exceptions.
• Justify each exception in writing: If nobody can explain why a destination bypasses inspection, remove it.
• Require endpoint detection: Devices using split tunnelling need protection the network is no longer providing.
• Keep regulated traffic inside: Financial, health and personal data should never be on the exception list.
• Review the list on a schedule: Exceptions accumulate. Quarterly review keeps the gap from widening.
• Test per platform: Windows, macOS, iOS and Android clients behave differently. Verify rather than assume.

Secure connectivity from Tata Communications

Split tunnelling is a remote-access VPN feature, configured on the endpoint client. It is a different thing from the site-to-site connectivity that joins your offices and data centres.

While split tunnelling is configured on endpoint VPN clients, enterprises still require a secure underlying network connecting offices, clouds, data centres and digital services. Tata Communications Global VPN delivers that private, highly available connectivity layer across a global footprint. It offers any-to-any connectivity across 240+ points of presence, with six classes of service.

For the endpoint side, our guide to network infrastructure security covers the segmentation and access control principles that apply. Once services are live, Tata Communications TC^X lets you track and manage them in one place.

If you are weighing full tunnel against split tunnelling across your sites, it is worth talking it through.
Schedule a conversation with our team.

See how Global VPN differentiates enterprise connectivity. Read The Brief

Discuss your remote access and connectivity requirements. Schedule A Conversation

Benchmark your network maturity against peers in a guided assessment. Take The Network Maturity Survey