Types of VPN Split Tunneling: Split-Include, Inverse Split Tunneling, and How to Choose

Most teams have a working understanding of VPN split tunneling — how it works, why it improves performance, and the security trade-offs it introduces. The next question is where most explainers stop short: split tunneling isn’t one approach.

There are several distinct ways to implement it, each with a different default posture and a different fit by team and risk profile.

This post compares the two approaches, walks through how to choose between them, and shows how each one is configured in CloudConnexa.

Quick refresher: What is VPN split tunneling?

VPN split tunneling is a network configuration that lets a device send some traffic through an encrypted VPN tunnel while sending other traffic directly over the public internet. It’s how administrators avoid the all-or-nothing trade-off of a full-tunnel VPN — keeping protection on the traffic that needs it without paying a latency and bandwidth tax on the rest. For a deeper foundation on benefits, risks, and use cases, see our Split Tunneling VPN Explained post.

Split tunneling breaks that all-or-nothing rule. Administrators define which destinations require the tunnel and which don’t, and the VPN client routes each packet accordingly.

Why set up VPN split tunneling?

Admins reach for split tunneling for several reasons:

• Performance. Latency-sensitive applications and other real-time tools perform better over a direct local path. Streaming and large downloads avoid saturating the VPN concentrator.
• Bandwidth and cost. Backhauling all internet traffic through a central VPN gateway consumes corporate bandwidth and inflates infrastructure cost. Split tunneling pushes only the traffic that needs protection through the tunnel.
• Local network access. A full-tunnel VPN can break access to local resources — printers, networked drives, smart-home devices. Split tunneling preserves local LAN reachability while keeping corporate traffic encrypted.
• Hybrid work. Distributed teams often need simultaneous access to corporate resources and local intranet services. Split tunneling makes that possible without users toggling the VPN on and off throughout the day.
• User experience and compliance. When a VPN feels slow or breaks common workflows, users disable it. Reducing that friction increases the share of time users actually keep the VPN on.

Two approaches to VPN split tunneling

Split-include

Only traffic destined for an admin-defined list of corporate networks and resources flows through the VPN tunnel. All other traffic — general web browsing, consumer apps, streaming — uses the device’s regular internet connection.

This is the default-permissive model. It minimizes VPN backhaul and delivers the best performance for everyday traffic. It’s the right fit when users need protected access to a defined set of corporate resources but don’t require corporate-controlled security on their general internet usage.

Split-exclude

The mirror image: all traffic flows through the VPN tunnel by default, with specific destinations excluded to route locally instead.

Split-exclude is the default-secure model. It preserves the VPN’s role as the primary egress for security inspection (DNS filtering, threat detection, logging) while letting latency-sensitive or high-bandwidth destinations skip the tunnel. It’s what you reach for when corporate policy needs to apply to all traffic but a small number of destinations perform poorly when backhauled.

How to choose the right approach

The right approach depends on two questions:

• What’s the default risk posture for this team? Default-secure means split-exclude tunneling. Default-permissive means split-include.
• Does corporate policy need to apply to general internet traffic? If yes — for DLP, threat inspection, or content filtering — split-exclude tunneling. If no, split-include is simpler and faster.

In practice, mature deployments segment tunneling policy by team risk profile. A finance team handling regulated data runs split-exclude with a tight exclusion list — everything inspected by default, with a handful of latency-sensitive destinations carved out. An engineering team runs split-include, since most of their traffic (package registries, cloud consoles, dev tools) doesn't need corporate inspection.

When a VPN supports more than one approach and scopes the choice to user groups rather than the whole organization, admins can write policy around real-world risk profiles instead of being forced into a one-size-fits-all setting.

How to configure split tunneling in CloudConnexa

CloudConnexa lets IT admins apply either of the split tunneling approaches above on a per–User Group basis, so different teams, roles, and risk profiles can each get the policy that fits them. The configuration lives in the Admin Portal’s Internet Access settings.

Each User Group has three Internet Access modes:

• Split Tunnel On — CloudConnexa’s split-include configuration. Only traffic to defined corporate networks flows through the tunnel; everything else uses the device’s regular internet connection.
• Split Tunnel Off — CloudConnexa’s full-tunnel configuration. All traffic flows through the tunnel by default. Combine it with Tunnel Bypass — admin-defined subnet exclusions that route locally instead — to get split-exclude tunneling.
• Restricted Internet Access — the strictest configuration. Only corporate destinations and named Tunnel Bypass exclusions are reachable; general internet access is blocked. A fit for high-risk roles or compliance-driven workloads.

Because Internet Access and Tunnel Bypass are scoped to the User Group, the same CloudConnexa deployment can run a default-permissive split-include policy for engineering, a default-secure split-exlude tunnel for finance, and a Restricted Internet Access policy for contractors — without compromising on either security or performance.

Setting it up

In the Admin Portal, go to Access → Internet, edit the User Group, and choose an Internet Access mode — Split Tunnel On, Split Tunnel Off, or Restricted Internet. For Split Tunnel Off or Restricted Internet, click Manage Exceptions to add destinations to Tunnel Bypass, then click Update Tunnel Bypass to save. For a fuller walkthrough of split tunneling configuration, including bandwidth management strategies and endpoint security considerations, see our tutorial on how to steer traffic in CloudConnexa.

Risks to plan around

Split tunneling, regardless of approach, comes with trade-offs admins should design around:

• Traffic outside the tunnel isn’t covered by VPN encryption — ISPs and intermediate networks can see it.
• Business security policies (antivirus inspection, content filtering, DLP) only apply to tunneled traffic.
• A compromised endpoint can still exfiltrate data over the non-tunneled path.
• Firewall and DNS rules need to be consistent on both sides of the split.

These risks apply across every vendor’s split tunneling implementation. The advantage of User Group–scoped control is that you can apply the strictest policies to the highest-risk users without paying the performance cost across the whole organization.

Try CloudConnexa

CloudConnexa takes the guesswork out of split tunneling. Configure split tunneling the way your business actually works — secure-by-default for the teams that need it, performance-first for the teams that don’t. Sign up for CloudConnexa