Dynamic Split Tunnel

What Dynamic Split Tunnelling Does

Dynamic split tunnelling is a VPN routing mode that selectively sends some traffic through the encrypted tunnel while allowing other traffic to reach the network directly. In practice, that means the policy decides which destinations, subnets, or applications need the protection of the VPN and which do not, rather than forcing every packet through one path.

The key value is flexibility. Organisations use it to protect corporate traffic without routing everything through the VPN concentrator, which can reduce latency, preserve local access to trusted services, and avoid unnecessary hairpinning. The trade-off is that the routing decision now becomes a security boundary, not just a performance setting.

Where It Fits In Secure Remote Access

Dynamic split tunnelling sits inside remote-access design, not as a standalone security control. It changes how a client decides whether traffic is enterprise-bound or local, which makes it closely related to route selection, policy enforcement, and trusted versus untrusted network paths. That is why secure implementation usually depends on clear rules for what is allowed outside the tunnel and what must remain inside it.

This is also where configuration quality matters. If the policy logic is too broad, sensitive traffic can bypass inspection. If it is too narrow, the VPN can become slow, brittle, or unusable, pushing users toward workarounds. A well-designed approach separates convenience traffic from work traffic without weakening the organisation’s security assumptions.

For a deeper treatment of the routing and leak-prevention issues around split tunnelling, see VPN split tunnelling.

Security Properties And Failure Modes

The main security question is not whether split tunnelling exists, but what happens when traffic is allowed to avoid the VPN. Traffic that bypasses the tunnel may skip corporate inspection, DNS protections, web filtering, or logging. It can also create a second network path on the same endpoint, which complicates trust assumptions and makes policy enforcement harder to reason about.

Misrouting is the common failure mode. A destination that should have been forced through the tunnel may be excluded by IP, subnet, or application logic, creating data leakage or exposing internal resources to less controlled paths. Local LAN access, DNS leaks, and unintended route overlap are all practical examples of how the policy can fail even when the VPN itself is technically connected.

Where organisations need a general control model for path enforcement and segmentation, NIST SP 800-207 Zero Trust Architecture is useful for framing trust decisions, while the route-control perspective in NIST SP 800-53 Rev 5 Security and Privacy Controls helps map those decisions to access control and boundary protection expectations.

Operational Uses And Design Choices

Dynamic split tunnelling is usually chosen when organisations want to balance security with performance or user experience. Common use cases include sending internal application traffic through the VPN while letting low-risk public SaaS or local internet traffic go direct, or steering traffic based on application identity instead of only destination IP. The design choice matters because destination-based rules are easier to explain, but application-based rules can be more precise when the endpoint has multiple traffic classes.

Administrators also need to think about policy consistency across device types, operating systems, and client versions. A routing rule that works on one platform may behave differently on another, especially where DNS handling, route precedence, or local network discovery differs. That is why operational testing should verify not just connectivity, but what traffic actually leaves the endpoint through each path.

When the VPN platform is part of a broader remote-access stack, implementation guidance such as the Palo Alto Prisma Access Configuration Guide can help teams think about split tunnel policy, admin roles, and logging as one connected design problem. For WireGuard-specific routing and leak-prevention behaviour, the WireGuard Security Guide is also relevant.

Risk and Threat Considerations

Dynamic split tunnelling increases exposure when the organisation assumes that all remote traffic is equally protected. If the policy is wrong, traffic can bypass inspection, create DNS or route leaks, or expose internal systems through a less controlled path. The risk is highest when endpoint users move between trusted and untrusted networks, because the same client may be making multiple routing decisions at once.

Failure mechanism: A route, subnet, DNS rule, or application selector sends traffic outside the tunnel when it should have remained inside, or allows a local path to coexist with a trusted work path. That can weaken monitoring and make the endpoint a bridge between security domains.

Impact: Sensitive traffic may leave the organisation’s control, attacker reconnaissance may become easier on the local network, and compromise of the endpoint can provide a more useful pivot point because the split path blurs the boundary the VPN was meant to enforce.

Practitioner Guidance

Governance implication: Treat split tunnelling as a policy decision that needs ownership, review, and change control, not as a default convenience setting. The practical question is which traffic classes are allowed to bypass the tunnel and whether that exception remains defensible over time as apps, networks, and endpoint behaviour change.

What to watch for: Review DNS handling, route precedence, local LAN access, and application exclusions together, because the dangerous failures often come from combinations rather than a single bad rule. If the VPN client cannot explain the routing decision clearly, the policy is usually too fragile to trust.

Practitioner takeaway: The safest dynamic split tunnel is the one with the smallest possible exception set, explicit logging, and periodic validation that real traffic matches the intended policy.

Related resources from NHI Mgmt Group

• What is the difference between static and dynamic credentials?
• How do I migrate from static credentials to dynamic credentials?
• When should organizations transition from static to dynamic credentials?
• How should security teams split identity governance from implementation work?