Split-Include Tunneling

How split-include tunnelling works

Split-include tunnelling is a routing choice, not a different encryption protocol. The VPN client builds a policy that sends only selected destinations or networks into the tunnel, while everything else exits through the normal internet path. That makes the routing decision central to what is protected, what is visible to the VPN, and what traffic remains outside its control.

This mode is often used when organisations want private access to a defined set of internal systems without forcing all internet traffic through the VPN. It can reduce bandwidth use and improve performance, but it also creates two network paths with different trust boundaries. The design therefore depends on accurate routing rules and a clear understanding of which destinations must be protected.

Why organisations use split-include routing

The main appeal of split-include tunnelling is scope control. Only the traffic that actually needs enterprise reachability is sent through the VPN, which can lower latency for local services and avoid overloading the remote tunnel. For remote workers, it can also preserve access to nearby internet resources, printing, conferencing, or SaaS services that do not need corporate routing.

That convenience is also the reason it must be designed carefully. The organisation is choosing not to inspect or mediate some traffic through the VPN, so the tunnel is no longer the single path for the user’s session. If the routing set is incomplete or too broad, users may lose access they need or, conversely, send sensitive traffic outside the protected path.

Exposure points and common failure modes

Split-include tunnelling is vulnerable to routing mistakes, DNS leakage, and local network exposure. If a sensitive destination is omitted from the include list, the traffic may use the local path instead of the encrypted tunnel. If DNS resolution is not aligned with the routing policy, name lookups can reveal internal service intent or direct the client to the wrong path. The result is often a mismatch between the security intent and the actual packet flow.

The other recurring issue is that the VPN can only control what it can see. Traffic sent outside the tunnel may bypass enterprise filtering, logging, and inspection, which reduces central visibility. VPN split tunnelling guidance is especially useful here because the practical risks are usually tied to route design, DNS behaviour, and unintended local access rather than the tunnel itself.

Security implications and safer deployment choices

When organisations allow split-include routing, they should treat the route list as a security control surface. The safest pattern is to define the smallest practical set of destinations that truly need private routing, and to review those routes whenever applications, cloud endpoints, or network ranges change. If the include set is too broad, the VPN becomes a performance bottleneck; if it is too narrow, the policy can expose traffic that was meant to stay private.

For remote access programs, split-include should be paired with strong endpoint control and clear monitoring expectations. A VPN Security Guide is a useful companion because appliance hardening, logging, patching, and tunnel policy all affect whether split routing is defensible in practice. The same principle appears in NIST Cybersecurity Framework 2.0, where secure communications, asset visibility, and protective controls all depend on accurate scoping of trust boundaries.

In more sensitive environments, many teams prefer forced tunnelling or zero-trust access patterns instead of broad split routing, especially when they need consistent inspection and policy enforcement for user traffic.

Related resources from NHI Mgmt Group

• Tunneling
• 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?