Split-Exclude Tunneling

What Split-Exclude Tunneling Does

Split-exclude tunneling is a VPN routing mode that keeps most traffic inside the encrypted tunnel while intentionally sending selected destinations outside it. The design is usually used to preserve access to nearby networks or local services, but it also creates a deliberate exception to the VPN trust boundary.

Why Organisations Use It

Administrators choose split-exclude tunneling when a full tunnel would break access to printers, local infrastructure, or internal resources that are reachable only on the local network. It can also reduce unnecessary backhaul for traffic that does not need inspection through the VPN concentrator, especially in remote-working environments.

The trade-off is policy complexity: every excluded route becomes a decision about which traffic bypasses the corporate security path. That makes destination scoping, change control, and user device posture more important than in a simple full-tunnel design.

Security Implications of Excluded Routes

Excluded routes change where trust is enforced. Traffic that leaves the VPN is no longer protected by the same inspection, logging, and network access controls that apply inside the tunnel, so the exception must be narrow and deliberate. NHIMG’s VPN split tunnelling guide expands on the leak and pivot risks created by route exclusions.

That matters because split-exclude tunneling can unintentionally expose DNS lookups, internal service discovery, or adjacent network access to less controlled paths. The result is not just reduced confidentiality, but a weaker assumption about who can reach what from the endpoint and how quickly an attacker could pivot if the device is compromised.

How Split-Exclude Tunneling Is Managed Safely

Safe use starts with precise routing policy. Teams should define the smallest possible exclusion set, document why each destination must bypass the tunnel, and regularly review whether the exception is still needed. A broad “allow local access” exception is usually harder to defend than a tightly specified route list.

Operationally, this is best treated as a network control problem, not a convenience setting. Monitor for unexpected destinations in the exclusion list, validate that DNS and name resolution follow the intended path, and confirm that endpoint hardening still protects traffic that is intentionally outside the tunnel. NHIMG’s VPN Security Guide provides broader context on VPN hardening and routing-related risk.

For a defence-in-depth lens, NIST’s NIST SP 800-207 Zero Trust Architecture is useful because it treats network location as an unreliable signal and favours explicit verification and least privilege over implicit trust in any path.

Risk and Threat Considerations

Split-exclude tunneling can create a split trust boundary, where one part of an endpoint’s traffic is protected and another part is directly exposed to the local or upstream network. That increases the chance of data leakage, route abuse, and inconsistent security enforcement if the exclusions are too broad or poorly understood.

Failure mechanism: An attacker who controls the endpoint, local network, or an adjacent route can exploit the bypass path to intercept traffic, redirect name resolution, or move laterally through services that were excluded from the VPN.

Impact: The organisation can lose visibility and control over traffic that was assumed to be protected, which can lead to credential exposure, service reachability abuse, or a successful pivot around VPN-enforced inspection and segmentation.

Practitioner Guidance

What to watch for: Treat every excluded destination as a live exception with an owner and a reason. If the exception exists only to solve a temporary connectivity problem, it should be revisited, because routing exceptions tend to persist long after the original need has passed.

Governance implication: Split-exclude tunneling works best when network, security, and endpoint teams agree on which traffic may bypass the tunnel and how that decision is reviewed. The key question is not whether the feature is useful, but whether each exception remains justified under current risk and access requirements.

Related resources from NHI Mgmt Group

• How do security teams know whether split tunneling is still undermining CUI protection?
• When should organisations prioritise forced tunneling over split tunneling for remote users?
• What are common mistakes with VPN Split Tunneling?
• What is an example of VPN Split Tunneling in practice?