Split tunnelling sends only some of a remote device's traffic through the VPN and lets the rest go straight to the internet or the local network, which saves bandwidth but takes that traffic outside your inspection and creates a bridge between an untrusted network and your internal one. Whether that is acceptable depends on what bypasses the tunnel, how the exceptions are defined, who can change them and what protects the device and data outside the tunnel. This guide explains the split tunnelling models, the specific risks, how standards bodies treat it, how to configure exceptions safely on Windows and other clients, and what to monitor. It is for network, endpoint and security architects running remote access. Protocol choice and appliance hardening are covered in the VPN Protocols Compared and the VPN Appliance Security Guide.
Key takeaways
- Full tunnel is the default position. The NCSC advises a full-device, forced VPN and avoiding split tunnelling, and NIST SP 800-53 SC-7(7) says to prevent split tunnelling unless it is securely provisioned.
- Narrow exceptions are the safe compromise. Forced tunnelling with a short list of IP-based exclusions for trusted, high-volume services (Microsoft's approach for Microsoft 365) keeps most of the benefit with little exposure.
- Never let users control the routes. SC-7(7) guidance describes a securely provisioned split tunnel as locked to managed, named environments or pre-approved addresses without user control.
- The tunnel can leak even when configured correctly. CVE-2024-3661 showed that DHCP option 121 can push routes that force route-based VPN clients to send traffic over the physical interface.
- Bypassed traffic still needs protection. Anything outside the tunnel needs endpoint, DNS and identity controls of its own, or a cloud security service to inspect it.
The tunnelling models
| Model | What uses the tunnel | Typical reason | Main risk |
|---|---|---|---|
| Full (forced) tunnel | All traffic, including internet | Central inspection and monitoring | Bandwidth and latency; capacity during surges |
| Forced tunnel with exclusions (inverse split) | Everything except a defined list of destinations | Offload trusted SaaS media and bulk traffic | Exclusion list too broad or stale |
| Split tunnel with inclusion list | Only routes to corporate networks | Simplicity, minimal VPN load | All internet traffic uninspected; device bridges two networks |
| Local LAN access allowed | Corporate traffic, but local subnet reachable | Home printers, casting | Exposure to other devices on hotel, home or public networks |
| Per-app VPN | Only traffic from selected applications | Mobile devices, BYOD | Unlisted apps bypass monitoring |
NIST defines split tunnelling in SC-7(7) as letting a remote device keep a connection to organisational systems while also communicating with resources in an external network, which it notes "can facilitate unauthorized external connections" and exfiltration. The NCSC adds that most native smartphone and tablet VPN clients rarely support split tunnelling, while Windows can through custom routing rules.
What actually goes wrong
| Risk | How it happens | ATT&CK v20 | Mitigation |
|---|---|---|---|
| Pivot from an untrusted network | A compromised device on the local network, or malware reached through the direct internet path, uses the VPN-connected device to reach internal systems | T1090 Proxy, T1133 External Remote Services | Block local LAN access, host firewall, EDR |
| Uninspected exfiltration | Data leaves through the direct path where no proxy or DLP sees it | T1048 Exfiltration Over Alternative Protocol | Forced tunnel for internet, or an SSE client, endpoint DLP |
| Interception on local networks | Traffic outside the tunnel on public Wi-Fi is exposed to local attackers | T1557 Adversary-in-the-Middle, T1040 Network Sniffing | TLS everywhere, forced tunnel on untrusted networks |
| Route manipulation leak | A rogue DHCP server pushes classless static routes (option 121) that override the VPN's routes (CVE-2024-3661) | T1557 | Client updates and vendor mitigations, firewall rules that block non-VPN egress, kill-switch features |
| DNS leak | Queries go to the local resolver, exposing internal names and bypassing protective DNS | T1557 | Force DNS to corporate or protective resolvers inside the tunnel |
| Monitoring blind spot | Security teams lose visibility of browsing and C2 on excluded paths | Not applicable | Endpoint telemetry and cloud proxy logs |
The route manipulation case matters because it hits full-tunnel users too. The NVD entry for CVE-2024-3661 lists clients from many major VPN vendors and operating systems, and notes that an attacker on the same local network could read, disrupt or possibly modify traffic expected to be protected. Treat "full tunnel" as a routing preference, and back it with host firewall rules that block traffic outside the VPN interface where your client supports it.
What standards and guidance say
- NCSC device security guidance: use a full-device VPN and avoid split tunnelling to minimise the risk of data leaking outside the VPN; use a forced VPN so apps cannot evade enterprise monitoring; prefer an automatic connection; use a platform captive portal assistant rather than disabling the forced VPN on public Wi-Fi.
- NIST SP 800-53 SC-7(7): prevent split tunnelling unless securely provisioned with defined safeguards. Prevention can mean disabling the setting and stopping users changing it, or detecting split tunnelling on the device and refusing the connection.
- Microsoft 365 guidance: keep a forced tunnel and send only the Optimize category (Exchange Online, SharePoint and Teams endpoints, which Microsoft says make up about 70 to 80 percent of Microsoft 365 traffic over roughly 20 IP subnets) directly. Microsoft relies on in-service controls for that traffic: DLP, malware scanning, Conditional Access and tenant restrictions, with authentication traffic still sent through the VPN to an on-premises proxy that enforces the tenant allow list.
Choosing a model
- Regulated or high-risk users (admins, finance, government): full forced tunnel, no local LAN access, automatic connection. Accept the bandwidth cost.
- General workforce on managed devices: forced tunnel with IP-based exclusions for named SaaS services that enforce their own controls, plus EDR and protective DNS on the device.
- Organisations with a cloud security service (SSE or SWG client): internet traffic can leave locally because the client inspects it; the VPN or ZTNA carries only private application traffic. This is split tunnelling with a different inspection point, not without one. See the SASE and SSE Guide.
- BYOD and mobile: per-app VPN for managed apps, with app-based Conditional Access so data cannot reach unmanaged apps.
- Small organisations with a single firewall and limited bandwidth often split tunnel by necessity. The minimum is an inclusion list fixed by the admin, no local LAN access, protective DNS on the device and Microsoft Defender or equivalent EDR.
Configuring exceptions safely
- Start from forced tunnel. On Windows, forced tunnel is the default when no routes are specified: the VPN's default routes are added with a lower metric than other interfaces, so traffic uses the VPN unless a more specific route exists on the physical interface.
- Define exclusions by IP range, not name. Microsoft recommends basing split tunnel rules on documented dedicated IP ranges and discourages FQDN or AppID rules, which may not fully cover the traffic and can conflict with IP routing.
- Keep the list short and owned. Each exclusion needs a business owner, the controls that protect it outside the tunnel and a review date. Track vendor range changes through their published endpoint feeds.
- Deliver through management, not the user. In the Windows VPNv2 CSP, routes are set under
VPNv2/<ProfileName>/RouteListwithAddress,PrefixandExclusionRoute; the routing policy isNativeProfile/RoutingPolicyType. Deploy through Intune or your MDM and prevent local changes. - Handle DNS explicitly. Send DNS for internal and general names to corporate or protective resolvers through the tunnel; only resolve excluded services locally if their vendor requires it.
- Block local LAN access unless there is a documented need, and use the host firewall to restrict inbound connections when on untrusted networks.
- Handle browser peer-to-peer. Microsoft notes that Edge 96 and later can respect OS routing for WebRTC peer-to-peer traffic via the
WebRtcRespectOsRoutingTableEnabledpolicy; other browsers may not. - Pilot and roll back: deploy to an IT pilot ring for two weeks, measure VPN load and call quality, then expand by ring. Keep the previous profile version so a faulty route list can be reverted through MDM in minutes.
Where identity fits
With split tunnelling, identity controls become the boundary for whatever bypasses the tunnel. Conditional Access that checks device compliance and sign-in risk protects excluded SaaS services even when traffic does not pass your proxy. Watch two machine identity cases: VPN clients that authenticate with device certificates (the NCSC prefers client certificates with keys in hardware over pre-shared keys), and automation or agents on remote devices that hold API tokens and talk directly to cloud services through the excluded path. Both need inventory, rotation and logging like any other non-human identity. See the Conditional Access Guide.
Detection and measurement
- Configuration drift: devices whose VPN profile, route list or local LAN setting differs from the managed baseline, collected through MDM compliance reports.
- Traffic outside the tunnel: EDR or host firewall telemetry showing connections from the physical interface to destinations not on the exclusion list while the VPN is up.
- DNS: share of remote device queries reaching corporate or protective resolvers, target close to 100 percent.
- Route anomalies: unexpected classless static routes or more-specific routes on the physical interface, a sign of the option 121 technique.
- Exception hygiene: number of exclusions, percentage with an owner and review date, days since last review.
- VPN connection posture: percentage of remote sessions on a forced, automatic profile. Correlate with VPN logs; see the VPN and Firewall Log Detection Guide.
Framework mapping
| Area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| Split tunnelling decision and safeguards | SC-7(7) Split Tunneling for Remote Devices | PR.IR-01 |
| Remote access control and monitoring | AC-17, AC-17(1) Monitoring and Control, AC-17(3) Managed Access Control Points | PR.IR-01, DE.CM-01 |
| Boundary protection for bypassed traffic | SC-7 Boundary Protection | PR.IR-01 |
| Network monitoring | AC-17(1) | DE.CM-01 |
Common failure patterns
- Splitting by domain name: FQDN-based rules miss traffic or conflict with IP routes, and the exclusion silently grows.
- Exclusions nobody owns: a temporary exception for a video tool during a surge is still there years later.
- User-controlled VPN: optional or user-editable profiles let staff turn off the tunnel or add routes, which NCSC treats as higher risk.
- Local LAN access left on: the corporate laptop is reachable by every device on a hotel network.
- Assuming full tunnel cannot leak: route-based clients without firewall enforcement remain exposed to option 121 route injection.
- No inspection on the direct path: internet traffic leaves locally with no SSE client, protective DNS or endpoint DLP, so exfiltration and C2 are invisible.
Practitioner checklist
- Document a tunnelling standard: full forced tunnel by default, approved exclusions by exception.
- Define every exclusion by IP range with an owner, protecting controls and review date.
- Deploy VPN profiles through MDM and prevent user changes.
- Make the VPN automatic and use captive portal assistants instead of disabling it.
- Disable local LAN access unless there is a documented need.
- Force DNS to corporate or protective resolvers through the tunnel.
- Patch VPN clients for CVE-2024-3661 and enable firewall-based leak protection where supported.
- Protect excluded SaaS with Conditional Access, device compliance and in-service DLP.
- Monitor for configuration drift, off-tunnel traffic and unexpected routes.
- Review the exclusion list at least quarterly.
Standards and references
- NCSC: Device security guidance, virtual private networks
- NIST: SP 800-53 Rev. 5 (SC-7(7) Split Tunneling for Remote Devices)
- NIST: SP 800-46 Rev. 2, Guide to Enterprise Telework, Remote Access, and BYOD Security
- Microsoft Learn: Optimizing Microsoft 365 connectivity for remote users using VPN split tunnelling
- Microsoft Learn: VPN routing decisions
- NIST NVD: CVE-2024-3661
- MITRE ATT&CK: Adversary-in-the-Middle
Related NHI Mgmt Group resources: Secure Remote Access Beyond VPN Guide · ZTNA Guide · Protective DNS Guide · Home Office and Remote Worker Security Guide