VPN split tunneling decides which traffic from a remote device goes through the organization’s VPN and which traffic reaches the internet directly. That routing choice can reduce bandwidth pressure and improve performance for cloud services, but it also changes where security inspection, logging, DNS policy, and access controls apply. The risk is not “split tunneling is always unsafe.” The risk is creating two network paths without understanding what controls exist on each one.
Within network and penetration testing, split tunneling is best analyzed as a trust-boundary problem. The endpoint simultaneously has a path to enterprise resources and a path that may bypass enterprise network controls. Whether that is acceptable depends on endpoint security, routing policy, identity controls, DNS behavior, and the sensitivity of the resources reachable through the tunnel.
The topic also fits Network+ because a correct design starts with routing fundamentals: which prefixes are advertised through the tunnel, what becomes the default route, and how name resolution and return paths behave.
Full tunnel and split tunnel move the inspection point
In a full-tunnel design, most or all remote-device traffic is sent through the corporate VPN headend before reaching internal or internet destinations. That centralizes egress inspection and policy but can add latency and consume significant headend and transit capacity. Split tunneling sends selected traffic directly to the internet while keeping enterprise prefixes in the VPN.
VPN architecture and remote-access design should therefore begin with control placement. If web filtering, malware inspection, data-loss controls, or DNS policy exist only at the corporate egress, split traffic may bypass them. If equivalent controls run on the endpoint or in a cloud security service, the security trade-off is different.
The routing table is the implementation of that trust decision. Documentation should identify which prefixes, applications, or destinations use each path and who owns changes.
The dual-path endpoint can become a bridge between trust zones
A common concern is that a compromised remote device has one interface toward an untrusted local network or direct internet path and another path into enterprise resources. Modern operating systems do not automatically forward traffic between those paths, but malware with sufficient privilege can still use the endpoint as a pivot.
Risk reduction therefore depends heavily on endpoint posture: host firewall policy, EDR, patching, privilege control, disk protection, phishing resistance, and device compliance. Treating the VPN as the only security boundary creates false confidence whether split tunneling is enabled or not.
Zero-trust architecture provides a stronger model. Access to enterprise applications should be based on identity, device state, and policy rather than an assumption that all traffic coming from the VPN is trustworthy.
DNS can reveal where the design actually breaks
Split routing often interacts with split DNS. Internal names may need enterprise resolvers while public names can use local or secure-cloud resolvers. If resolution paths are ambiguous, users can see intermittent failures, leak internal naming information, or connect to the wrong destination.
Document which DNS suffixes are resolved where, how the VPN client installs resolver policy, and what happens when the corporate resolver is unavailable. Avoid broad rules that send every DNS query into the tunnel if the design objective was to offload internet traffic; that can retain a hidden dependency on the VPN headend.
DNS logging is also part of visibility. If direct traffic no longer reaches enterprise resolvers, security teams need to know whether endpoint or cloud controls preserve equivalent detection capability.
SaaS offload can improve performance, but exceptions become governance debt
Large collaboration and productivity services can generate substantial traffic. Routing approved SaaS destinations directly to the internet can reduce backhaul and improve user experience. The operational problem begins when exceptions accumulate without ownership. IP ranges change, applications use shared cloud infrastructure, and static prefix lists age.
Prefer provider-supported destination categories, managed client policies, or identity-aware access patterns over manually maintained collections where possible. Split tunneling fundamentals are straightforward; maintaining an accurate exception policy over time is the harder engineering problem.
Each exception should state the reason, destination scope, security controls that still apply, and an owner responsible for review.
Data protection must follow the direct path
If sensitive data can leave through the split path, controls that existed at a centralized internet gateway may no longer see it. That can affect DLP, TLS inspection, file scanning, logging, and regulatory evidence. The design should identify which protections are endpoint-based, cloud-based, application-based, or absent on the direct path.
This does not mean every organization should force every byte through a corporate tunnel. It means the security architecture must preserve the required outcomes. Endpoint DLP, SaaS controls, secure web gateways delivered from the cloud, and strong application authorization can replace some centralized functions when deliberately designed.
Data classification helps decide where full tunnel may still be required. Traffic carrying highly sensitive workloads can follow stricter routing than commodity internet access.
IPv6 and local-network behavior can undermine an IPv4-only policy
A split-tunnel policy that only considers IPv4 may leave IPv6 traffic taking an unexpected path. Likewise, local-subnet access settings can allow a remote device to reach printers, routers, or other local systems while connected to the enterprise. Those details matter because attackers and troubleshooting tools use whatever path exists, not only the one shown in the design diagram.
Test dual-stack behavior explicitly. Confirm route installation, DNS resolution, firewall rules, and corporate-resource reachability over both IP families. Decide whether local LAN access is required and constrain it if the VPN client supports that choice.
Route-leak and overlap scenarios also deserve testing. Home networks commonly use private address space that may collide with enterprise ranges, producing confusing failures or unintended destinations.
Monitoring has to correlate the endpoint and the VPN headend
With full tunneling, network teams can often see a large portion of remote traffic at the headend. Split tunneling distributes evidence across endpoint telemetry, VPN logs, DNS, identity systems, cloud security services, and application logs. Detection engineering must reflect that change.
VPN failure analysis is also easier when the route decision is visible. Support teams should be able to determine whether a failed connection was supposed to use the tunnel, which route was selected, which DNS server answered, and whether endpoint policy blocked the session.
Measure not just VPN uptime but policy outcomes: route installation errors, devices outside compliance, direct traffic that should have been tunneled, and enterprise traffic unexpectedly taking local routes.
Split tunneling is safe only when the control model is explicit
CISA telework guidance has long treated split tunneling as a design that requires care around segmentation and policy decision points. That remains the useful principle. The question is not whether the tunnel is split, but whether traffic reaches the correct destination through a path with appropriate controls that cannot be trivially bypassed.
Teams studying CompTIA networking concepts can frame the design as routing plus security architecture: determine the prefixes, inspect the route table, understand DNS, then map the security services on each path. Penetration tests should include compromised-endpoint scenarios and attempts to exploit differences between tunneled and direct egress.
A well-governed split tunnel can reduce latency and concentrate VPN capacity on traffic that needs it. A poorly governed one becomes an undocumented second perimeter. The difference is explicit routing policy, endpoint assurance, equivalent control coverage, and continuous verification that the implementation still matches the architecture.
Change control matters because split-tunnel lists are security policy expressed as routing. A new SaaS optimization or emergency exception can alter inspection coverage for thousands of endpoints. Treat route-policy changes like firewall changes: peer review them, test them against representative clients, record the business reason, and roll them back if telemetry shows unexpected bypass or reachability.
Performance metrics should include the headend and the direct path. If users report that split tunneling “fixed” latency, confirm which application improved and whether the change shifted a bottleneck to DNS, endpoint inspection, or a cloud security service. Good designs prove both user-experience improvement and preservation of the required security controls.
Testing should include captive portals and untrusted local networks as well. A remote employee may connect from hotels, airports, or home routers that manipulate DNS or intercept traffic. Confirm that the VPN establishes securely, that enterprise routes cannot be redirected by local infrastructure, and that sensitive applications still use strong end-to-end encryption even when portions of the path bypass the corporate network.
The design should also be documented well enough that support, networking, and security teams interpret the same route policy consistently during an incident.
Application owners should participate in route decisions because destination lists alone do not reveal business dependencies. An application may authenticate against one cloud service, download updates from another, and call an API hosted behind a third domain. Splitting only the obvious front-end traffic can create asymmetric performance or inspection. Map the complete transaction path for important applications, then test whether every dependency follows the intended route. This prevents “optimized” traffic from failing because a hidden supporting flow still hairpins through the VPN.
The decision should also include which traffic must never bypass inspection. Management access, privileged applications, DNS, software updates, and SaaS traffic can have different requirements, so split-tunnel policy needs destination ownership and periodic review as business dependencies change.
