Short answer: Windows split tunneling is a routing policy: configured destination routes use the VPN interface, while other traffic can use another interface. Microsoft's built-in and managed Windows VPN profiles express this with network routes. A consumer VPN app may instead offer its own app or destination controls, so do not assume that its interface follows the built-in Windows rules. Check which client owns the connection and who manages its profile before changing anything.
What split tunnel means in a Windows VPN profile
Windows makes outbound routing decisions using routes. Microsoft's documentation describes a split-tunnel profile as sending specified routes over the VPN while other traffic uses the physical interface. A force-tunnel profile adds default routes for IPv4 and IPv6 through the VPN; specific routes can still affect the actual path. These terms describe routing configuration, not a guarantee about every application, DNS request, or traffic filter.
For managed built-in VPN profiles, administrators can define routes with the VPNv2 configuration service provider or a supported profile-management tool. Windows PowerShell's Add-VpnConnectionRoute can add a destination prefix to a specified VPN profile. Those are configuration mechanisms for a Windows VPN connection; they are not generic instructions for every commercial VPN app.
Route-based and app-based controls are different
- Route-based split tunneling: sends matching destination networks through the VPN. Windows selects a route for the destination address; the setting does not inherently mean “only this app uses the VPN.”
- App-based split tunneling: selects applications for VPN or direct access. Consumer VPN apps may provide this as a provider-specific feature. Microsoft also documents traffic filters and per-app policies for managed VPN profiles, but their availability and behavior depend on the profile and management setup.
A name such as “split tunneling” in two products does not prove that their controls work the same way. Check whether the setting names apps, IP prefixes, domains, or exclusions, and read the current documentation for the exact Windows client and VPN profile.
Decide what should travel through the tunnel
| Your goal | Routing question | What to verify |
|---|---|---|
| Reach work or school networks | Which internal address ranges must use the VPN? | Ask the administrator for the approved route list and name-resolution requirements. A route by itself does not grant access or authorization. |
| Send ordinary internet traffic through an organization | Does the profile use a VPN default route? | Confirm the organization's force-tunnel policy, DNS settings, and any documented exclusions. Do not create routes that weaken a managed policy. |
| Use a personal VPN for selected apps | Does the provider app select apps, destinations, or both? | Follow that provider's Windows instructions. An app's exclusion can use the ordinary network path, exposing its connection metadata to the local network or ISP and its ordinary public IP to destinations. |
| Keep local devices reachable | Does local-network traffic match a VPN route or block rule? | Check the VPN client documentation and local subnet routes. Ask the device administrator before altering work or school settings. See the printer/NAS troubleshooting checklist. |
A cautious way to inspect a routing issue
- Identify the connection type: Windows built-in VPN, an organization-managed profile, or a consumer provider app. Record the Windows version and exact client name.
- Read the current profile or app documentation. Note whether the policy is split tunnel or force tunnel, whether routes are included or excluded, and whether app-level rules are present. Do not copy route values from an unrelated example.
- For a route list you are authorized to review, use the IPv4 subnet calculator to work out individual prefix ranges. It performs address arithmetic only and does not find overlaps or verify the routes configured on the device.
- If the device is managed by work, school, or another administrator, ask them to confirm the intended route before editing settings. A routing change can expose traffic outside the organization's VPN or interrupt access to internal services.
- For a personal device, change one documented setting at a time and keep a note of its previous value so you can restore it. Use a non-sensitive test destination that the provider or administrator says should follow that route.
- Compare the observed route only as a point-in-time check. A browser IP page observes that browser's request, not every app, protocol, DNS resolver, or future connection. The VPN visibility matrix and IP/DNS check guide explain those limits.
Traffic that bypasses a VPN does not use that VPN tunnel's network path. HTTPS may still protect page contents in transit, but the local network or ISP can handle the bypassed connection and a website may see the ordinary public IP. A VPN also does not hide account sign-ins, browser identifiers, or information submitted to a site. See what a VPN can and cannot hide, the general split tunneling guide, and Windows disconnect protection.
Sources
- Microsoft Learn: VPN routing decisions (Windows 10 and 11; accessed 2026-11-03) — defines Windows VPN split and force tunnel routing, route lists, and exclusion routes for configured profiles.
- Microsoft Learn: Add-VpnConnectionRoute (accessed 2026-11-03) — documents adding IPv4 or IPv6 destination routes to a named Windows VPN connection.
- Microsoft Learn: VPNv2 CSP (accessed 2026-11-03) — describes managed Windows VPN profile settings including split/force tunnel routing policy.
- Microsoft Learn: Windows VPN technical guide (Windows 10 and 11; accessed 2026-11-03) — frames routing choices within organization-managed Windows VPN configuration.
Impact — TODO: apply/approval and configure referral URL — referral link not configured.
PartnerStack — TODO: apply/approval and configure referral URL — referral link not configured.
CJ Affiliate — TODO: apply/approval and configure referral URL — referral link not configured.