How to Set Up VPN Split Tunneling Rules on Windows

Split tunneling lets you choose which Windows traffic uses a VPN connection and which traffic follows your regular network route. It can be useful when one app needs a remote network path while another needs access to a local printer, company resource, or service that works best without the tunnel. The key is to identify what your client actually controls: some clients offer rules for individual applications, while Windows’ built-in VPN connection generally uses network routes rather than a simple per-app switch.

Understand the routing model before adding rules

A VPN connection creates a path between your device and a VPN endpoint. With full tunneling, the client attempts to send all applicable network traffic through that path. With split tunneling, some traffic uses the tunnel and other traffic goes directly through your normal internet connection. The exact behavior depends on the client, Windows configuration, and any policies set by an organization.

There are two approaches that are often described as “split tunneling,” but they are not interchangeable:

• Per-app rules: A compatible VPN client selects traffic based on the application making the connection. Depending on the client, a rule may include an app executable, a package identity, or a group of applications. A rule for one executable may not automatically cover its helper process, updater, or child process.
• Route-based rules: Windows or the VPN client selects a path based on destination addresses or network prefixes. An application’s traffic follows the route that matches its destination, so this method does not necessarily keep one entire app inside or outside the VPN.

Windows’ built-in VPN settings and PowerShell management tools can configure split tunneling using routes. That is useful when you want selected networks to use a VPN while other destinations remain reachable through the local connection. It is not the same as choosing a desktop application from a list and assigning that app a tunnel. App-specific VPN behavior may be available in managed Windows environments through organization policies, but it should not be assumed to exist in an ordinary consumer connection.

Third-party clients also differ. A client may offer an application list, destination rules, domain rules, or only a global routing mode. A subscription import does not guarantee that every client supports the same rule types. Before configuring anything, check the client’s own help text and confirm whether a setting applies to an executable, a destination, or all traffic.

Choose app-based or route-based rules

Start with the outcome you need, not a particular toggle. If a browser should use the VPN while a game launcher connects directly, an app-based control may fit—provided the client supports it and the relevant processes are covered. If you need access to a work subnet through a Windows VPN while ordinary internet traffic stays on your usual connection, route-based split tunneling may be the more appropriate model.

Before changing a rule, write down the intended behavior in plain language. For example: “This browser should use the VPN; the local printer and home network should remain reachable.” Or: “Only the company subnet should use the Windows VPN; internet destinations should continue through the local gateway.” This statement gives you a testable result and helps prevent a broad exception from being mistaken for a narrow one.

Consider these trade-offs when choosing a method:

• Per-app rules are convenient when the client exposes a clear application list and the application uses predictable processes. They can be less reliable when an app launches separate services, updates itself, or opens content in another program.
• Route-based rules are explicit about destinations and can suit private networks or known address ranges. They require accurate route information, and a destination can be shared by several apps, so a route does not identify which program initiated a connection.
• Full tunneling is simpler to reason about when all traffic should use the VPN. It may be unsuitable for local resources or applications that must use the ordinary connection, but it avoids maintaining exceptions for individual apps or destinations.

Also decide what should happen if the VPN disconnects. Some clients provide a kill switch that blocks selected or all traffic when the tunnel is unavailable; others have different behavior. A direct-connection exception may continue to use your regular network even when the VPN is active. Read the client’s description carefully, because an “exclude” option and a “bypass” option can have different meanings.

When comparing VPN setup information or selecting a client, VPNMT can be a starting point for checking the service’s supported platforms and account instructions; the actual availability of split-tunneling controls depends on the Windows client you use.

Configure per-app rules in a compatible client

If your client has an application-based split-tunneling feature, use its interface rather than editing undocumented files or copying rules from a different client. Menu names vary, but the general workflow is similar. Keep the change small: add one app, test it, and only then add further exceptions. This makes it easier to identify which rule caused a problem.

1. Confirm the active configuration. Open the client and check that the expected subscription or profile is selected and up to date. A saved rule in an inactive profile will not affect the connection you are using.
2. Find the routing controls. Look under settings or advanced options for terms such as split tunneling, application routing, bypass applications, or route selected apps through VPN. Read the accompanying description to establish whether the list means “include these apps” or “exclude these apps.”
3. Add the correct application. If the client asks for an executable, select the actual program file rather than a shortcut. Windows shortcuts can point to launchers, while the network connection may be opened by a separate executable. Avoid adding broad folders or unrelated processes unless the client documentation specifically recommends it.
4. Set the intended direction. Choose whether the listed app should use the VPN or bypass it. Do not infer the direction from a checkbox alone; labels such as “bypass selected apps” and “VPN only for selected apps” express opposite policies.
5. Apply the change as required. Some clients apply rules immediately; others require reconnecting the VPN, restarting the client, or selecting the profile again. Follow the client’s instructions, then confirm that its status indicates the intended profile is active.
6. Test one app at a time. Close and reopen the target application if it may reuse existing connections. Check the result before adding another rule. A browser may have multiple processes, so a successful test in one tab does not necessarily confirm every browser component follows the same path.

Keep a short record of each change: application or destination, intended path, and test result. If a client update resets settings or changes its rule interface, this record helps you restore the policy without guessing. Do not share screenshots that expose a subscription link, access token, account details, or private network addresses.

Set up route-based splitting in Windows

For a Windows built-in VPN connection, route-based configuration is the practical starting point. The idea is to send selected destination networks through the VPN while allowing other traffic to use the normal gateway. This is a network-level decision, not a promise that a particular application will always use one path.

Before modifying routes, confirm that you have the correct VPN connection name and the destination network information from the network administrator or service documentation. Do not invent a subnet or copy a route from an unrelated setup: an incorrect prefix can send traffic to the wrong interface or make a resource unreachable. On a managed computer, check with the administrator first, because organizational policies may replace or restrict local settings.

Windows PowerShell provides VPN management cmdlets, including Get-VpnConnection for inspecting a connection and Add-VpnConnectionRoute for adding a destination route to a VPN profile. The exact options and behavior can vary with the connection type, Windows configuration, and whether the profile is for the current user or all users. Review the command help on the device and confirm the profile name before applying a change. For example, inspect available connections with:

Get-VpnConnection

After identifying the correct profile, use the locally available command documentation to confirm the supported parameters and required destination prefix. Administrators may also configure routes through a management system. Avoid running commands copied from an unknown source, and do not treat a sample destination as suitable for your network. If the connection was created by your workplace, follow its documented process instead of changing it independently.

Once the VPN is connected, inspect the routing table with Get-NetRoute or route print. Look for the destination prefix and interface associated with the VPN, then compare it with the normal default route. Route metrics and more-specific prefixes influence which route Windows selects; the presence of a VPN connection alone does not prove that a particular destination uses it. If you remove a route later, verify that the relevant route belongs to the VPN profile and is not required by another network configuration.

Keep local network needs in mind. A VPN route can affect access to devices such as a printer or network storage if the destination overlaps with a routed network. Conversely, adding a route for a private subnet will not automatically make a public website or unrelated application use the VPN. If you need true per-application selection, use a client that explicitly supports it or ask the administrator whether a managed app-specific policy is available.

Verify the rules and troubleshoot

Test routing with a repeatable sequence rather than relying only on a client’s “connected” indicator. First note which profile is active and which rule should apply. Then test the target application and a control application that should use the other path. If possible, compare a destination’s observed public IP or network access with the VPN disconnected and connected. A difference can help identify the route, but a public IP check alone does not prove that all connections from an app use the same path.

• ✅ Confirm the intended profile is active and the rule is saved to that profile.
• ✅ Test the exact application process or destination named in the rule.
• ✅ Reconnect the VPN or restart the app if it keeps existing network sessions open.
• ✅ Check Windows routes when using a route-based configuration.
• ❌ Do not use a single browser result to claim that every app follows the same path.
• ❌ Do not disable Windows security features to make a routing rule appear to work.

For DNS, distinguish the route taken by an application’s connection from the resolver it uses to look up a domain name. Depending on the client and Windows configuration, DNS requests may follow different handling from other traffic. A browser’s secure DNS setting can also affect the resolver independently of the system setting. If a site loads from an unexpected region or fails only by name, compare name resolution with direct connectivity and review the client’s DNS options. Do not publish private DNS results or internal hostnames when asking for help.

If an app that should use the VPN connects directly, check whether the rule points to the correct executable, whether a launcher starts a separate network-facing process, and whether the app was already open when the rule changed. If an app that should bypass the VPN still uses it, verify the rule direction and look for a broader rule that takes precedence. Some clients apply global modes, domain policies, or process groups before individual exceptions.

If a destination stops working after you add a Windows route, inspect the route’s prefix, interface, and metric. Confirm that the destination belongs to the network you intended to route, and check whether a more-specific route or an overlapping local subnet is involved. If the problem began after a client or Windows update, compare the current profile with your change record and follow the client’s documented reset or repair procedure.

Finally, test both the normal and VPN-connected states. A configuration that works only while the tunnel is active may leave an app unable to connect after disconnection; a configuration that works only when disconnected may indicate a missing route or a client rule that is not being applied. The goal is not merely to see a connection succeed once, but to confirm the intended path under the conditions in which you plan to use it.

Reset the configuration and FAQ

If troubleshooting becomes confusing, return to a known state before trying another rule. In a third-party client, remove only the test rules you added, restore the original routing mode, reconnect, and verify ordinary connectivity. If you are unsure which entries were changed, use the client’s documented reset option and then re-import or select the intended configuration as instructed. Keep any required subscription or account information private.

For a Windows built-in VPN, remove only the route or setting you added to the correct profile. Check the current routing table before and after the change, disconnect and reconnect the VPN if required, and test the affected destination again. On a managed device, ask the administrator to restore the policy; local changes may be overwritten or conflict with organization settings. If you cannot identify the source of a route, do not delete it based on its destination alone.

Does Windows have a built-in per-app switch for every VPN?

No. Windows’ built-in VPN split-tunneling controls are primarily route-based. Per-app behavior depends on the VPN client or on managed policies configured for a specific environment. Check the exact client and profile documentation before expecting an app list.

Why does the rule not affect an app that is already open?

The application may keep existing connections alive, or its network activity may come from a separate helper process. Apply the rule, reconnect if required, fully close the app, and reopen it. If the behavior remains, confirm the executable or process identity the client expects.

Can one app use the VPN for some sites and connect directly for others?

That depends on the client’s rule model. Some clients support destination-based rules alongside application rules; others do not. Windows route-based rules select paths by destination network, not by the app that initiated the connection. Verify rule precedence and test the specific destinations you care about.

What should I do if a route breaks local network access?

Disconnect the VPN if necessary to restore access, then inspect the route and check for an overlapping local network or an incorrect prefix. Remove or revise only the change you made, reconnect, and retest. For a work-managed profile, contact the administrator rather than editing policy-owned routes.