Why route-nopull Alone Leaves the File Server Unreachable
Ignoring pushed routes is half a split tunnel. Pick the route owner, add the office prefix by hand, and test three flows before calling it fixed.
The file server opens fine, and the video call in the next window starts to stutter. Nothing is slow and no MTU is wrong: your client took the route list the server handed it, so every packet now exits through the office firewall. The fix is not another tuning flag but a decision about who owns the client's route table. That decision belongs in one place, and the failure modes below tell you which place you actually chose.
Decide who owns the route table
Three owners are possible. The server can push routes and a default gateway, in which case the client installs whatever it is told and becomes a full tunnel. The client profile can take ownership by discarding pushes and carrying its own route lines. A desktop connection manager can also own the decision through its own route and default-route properties.
Each choice fails in a different way, which is why the table is worth reading before you edit a profile. The row that matches your symptom is the owner you actually have.
| Owner | Where it lives | Result |
|---|---|---|
| Server | server config, redirect-gateway, pushed routes | client becomes a full tunnel |
| Profile | route-nopull and its own route lines | tunnel up, office prefix missing |
| Manager | never-default plus its own routes | desktop decides, profile ignored |
Pick one and write it down. Mixing two leaves a host whose default path contradicts its own documentation, and the next engineer cannot tell which layer won. Delete the loser explicitly.
route-nopull filters pushes, it does not add routes
route-nopull belongs in the client profile, and its order in that file is irrelevant because it only discards values coming from the server. It discards pushed routes, including a pushed default route, while the tunnel still comes up normally.
The consequence people miss is that pushed DHCP options go with them. DNS settings sent by the server are discarded too, so internal names stop resolving even though the tunnel is healthy and the server is reachable by address.
That leaves a tunnel with no path to the office prefix unless you add one yourself: route-nopull followed by route 10.30.0.0 255.255.0.0 in the same profile. That line carries an address and a mask; it does not name a next hop.
An alternative form appends a gateway token, route 10.30.0.0 255.255.0.0 vpn_gateway, which points the entry at the tunnel by name. Importers differ in whether they translate that variant, so inspect the stored connection if the entry is missing from the kernel table.
Verify with route lookups, not with a ping
A ping tells you that something answered. A route lookup tells you which interface the kernel would choose, which is the question you actually asked. Four short commands separate a missing route from a route that points at the wrong device.
Read what the tunnel installed with ip route show dev tun0. No output at all means zero routes, which is not a split tunnel that works, and it is the usual outcome of adding the filter without the explicit line.
Then check one office address with ip route get 10.30.5.7, and one ordinary internet address with ip route get 1.1.1.1. The second should name the physical interface; if it names the tunnel, the push was not filtered at all.
Finally read ip rule, because a policy rule left by an earlier attempt can override the table you just corrected. A correct profile with a stale rule on top looks exactly like a broken profile. Delete the rule you added last time before you add another one.
Overlapping subnets look like a broken tunnel
Two private ranges can be identical from the client's point of view, and that is where a split tunnel gets blamed for something it did not cause. If the office hands out the same prefix your home router uses, the tunnel route covers the router and the house network appears to vanish.
Compare the address on your own interface with the route the profile installs, using a plain address listing before you change anything. The overlap is real, and no profile option resolves it. What you can fix is the naming, so the next person sees two ranges rather than one.
The honest fixes are to renumber one side or to translate addresses at the office. Pinning a single host route to the router works until the router address changes, and then it becomes a second mystery on top of the first.
Make the decision survive a reconnect
Entries typed by hand do not outlive a reconnect, and a connection manager rebuilds the table each time the profile starts. Put the decision where the connection is created, whether that is the profile or the manager's stored settings. Then restart the connection once on purpose rather than discovering the behaviour during a call. A profile that only works until the next reconnect is not finished.
Exercise three paths at once: an office host by literal address, the same host by name, and a normal public site. The middle one depends on the name service you configured after dropping the pushed DNS options, and it is the one that quietly fails.