Keep private routes and drop the redirect: OpenVPN split tunnel
A private-only tunnel needs two rules: private prefixes go through it, ordinary browsing keeps its local path. Deleting a default route is not a policy.
The tunnel comes up, the application loads, and then everything else on the laptop starts behaving oddly. That is the usual shape of a private-only policy implemented by deleting one line. Removing a pushed default route does change where traffic goes, but it does not say where traffic should go instead, and it does not touch name resolution at all. A policy needs two positive halves before it can be tested.
Deleting the redirect is only half the change
A full-tunnel redirect and a private-only policy differ in what they claim about the world. The redirect claims every destination, while the private policy claims a list and leaves the rest alone. Deleting the claim without writing the list produces a client that reaches nothing outside the LAN, which looks like a routing failure rather than a policy gap. Write the list before you remove the claim, and the order of those two steps stops mattering.
Both halves are requirements rather than defaults. Private prefixes have to enter the tunnel, and ordinary destinations have to keep the path they had before the connection.
If an organisation mandates full tunnel, none of this applies. The private-only design belongs to deployments where split routing is approved.
pull-filter is a match, not a switch
The pull-filter directive removes pushed options whose names match a prefix, and that is all it does. Ignoring the redirect leaves every other pushed option in place, which is usually what you want: routes, DNS settings and the route-gateway value all still arrive. It also cannot remove a directive written in the local profile, because filtering applies to what the server pushes.
Resist the temptation to ignore every option beginning with route. That pattern also discards the private routes the connection needs, and it can drop gateway information the tunnel depends on.
route-nopull is a wider decision than it looks. It stops the client accepting pushed routes and DHCP-style options as a group, which is a different policy from filtering one option out.
Write the route list from the application outward
Start from what the user actually opens, then add the supporting pieces. An application at 10.60.20.15 implies its subnet 10.60.0.0/16, and a private name implies the resolver that answers it. A user who asked for one application therefore needs two destinations and one DNS decision. Everything beyond that list is out of scope by construction, which is what keeps the policy reviewable.
On a cooperating server those become two pushed routes, and neither of them is a redirect. Keep the tunnel topology and route-gateway values the existing service supplies.
When only some users need this policy, apply it per client or per group. Changing everyone's routing to fix one team's requirement is how a split tunnel becomes an outage.
| Destination | Intended path |
|---|---|
10.60.0.0/16 | Tunnel, for the approved application services |
10.61.0.53/32 | Tunnel, to reach the internal resolver |
corp.example queries | Internal resolver, selected per namespace |
| Everything else | Local path and local resolver |
Make DNS follow the same path
A route to the resolver is not a resolver policy. On a systemd-resolved client the semantic result is a routing domain for the private namespace pointing at the internal resolver, which is what makes only those names use it. A Windows client needs its own namespace policy mechanism instead. A DNS server line in the profile does not install either of those by itself.
Check what the operating system selected rather than what the profile requested. On Linux, resolvectl status shows the per-link domain and server; on Windows, the namespace policy table is the equivalent evidence.
Keep the resolver reachable through the tunnel, or the policy points at an address that cannot be queried. A resolver address the tunnel cannot reach turns a working policy into a timeout.
Verify both halves on a reconnect
Reconnect the client after the change and inspect the effective route to a private address and to a public one. Then resolve a private name and a public name and confirm each used the intended resolver. A public website loading proves only the second half, and that is the half which usually works by accident.
Record the finished policy in one sentence: these prefixes and names use this connection, everything else follows the local path. Then keep it in the profile rather than repairing adapter settings after each login.