route-gateway Is Not redirect-gateway: What Actually Changes
The option only supplies a next hop for routes OpenVPN installs. Removing it does not turn off a pushed full tunnel, and the fix belongs on the redirect.
Your tunnel comes up, the private subnet answers, and ordinary browsing still vanishes into the VPN even though someone deleted the gateway line from the profile. That combination is the fingerprint of the wrong directive being edited. What was removed gave the client a next hop for routes it installs; what kept capturing traffic arrived from elsewhere and was pushed by the server. Coverage and next hop are separate jobs, and only one of them decides whether public destinations use the tunnel.
The line you removed was a next hop, not a policy switch
Every route the client installs needs a gateway address to point at, and the gateway directive is where that address comes from when a route does not name one itself. Delete it and those routes have nowhere to attach, so they either fail to install or land on a path that leads nowhere. The private subnet is precisely what such a route was carrying.
Meanwhile the behaviour that survived has a different author: a redirection option in the pushed block, which moves ordinary outgoing traffic into the tunnel according to its flags. Removing the gateway neither disables it nor weakens it. The result is the worst of both states, with public traffic still captured and the private destination that justified the tunnel now unreachable. That is why the second edit, made in the same spirit, also changes nothing.
Four levers, four different jobs
Four directives get quoted interchangeably in this discussion, and only one of them governs coverage, meaning which destinations are routed through the tunnel at all. A second sets the next hop that routes use, a third installs a single prefix, and a fourth throws away everything the server pushed, including the private routes the deployment needs. The table sorts them by what an administrator is trying to change rather than by name, because the names are what cause the mix-up. Treat it as four separate decisions and pick the one you actually want to reverse.
In practice all four often arrive in one pushed block, line after line, which makes them look like parts of a single setting. They are not, and the OpenVPN reference documents them as distinct mechanisms for that reason. Working out which decision you are reversing is the task; the edit is one line.
| What you are trying to change | Directive that decides it | What it leaves alone |
|---|---|---|
| Which destinations use the tunnel | redirect-gateway | Per-prefix routes and resolver choice |
| The next hop a pushed route points at | route-gateway | Coverage of public destinations |
| One reachable prefix | route | Every other destination, default path included |
| All pushed routing and DNS at once | route-nopull | Nothing, which is the problem |
Filter the pushed line, keep the next hop
If the coverage you object to arrives as a pushed option, the narrow response is to ignore that option by name and leave the rest of the pushed block intact. Written as a filter, it looks like the line below, and it belongs in the profile of the affected client rather than in the server configuration.
pull-filter ignore "redirect-gateway"Narrowness is the point. Because the filter compares a text prefix, a shorter pattern also matches the next-hop directive, which strips exactly the information the private routes depend on, reproducing the original mistake in a new costume. A filter also acts only on pushed options, so it never touches an equivalent line written locally or imposed by a network manager. Reconnect afterwards, since a live session does not re-evaluate what the server pushed.
Read the lookup, not the table
After reloading the profile, ask the kernel where two destinations would actually go: one inside the private prefix and one on the public internet. A full dump of the main table is harder to read and easier to misread, because a route can exist and still lose to a more specific match. Under policy routing the rule, the table and the source address belong in the check too.
ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule showThe def1 variant deserves familiarity, because it leaves the old default entry visible while a pair of half-defaults wins the lookup. A 0.0.0.0/0 line in the output therefore proves nothing by itself. The lookup answers the question that the listing only appears to answer.
DNS, IPv6 and the private route still have to work
Declining one IPv4 redirection says nothing about the resolver, so a pushed DNS option can keep sending queries into the tunnel while the routes look correct. An IPv6 default can do the same for an address family the IPv4 check never touched. Both need an explicit decision rather than an assumption. Then confirm the private service still answers, because a split tunnel that has lost its private route is not a split tunnel, it is a broken one.
One wider tool deserves a warning: route-nopull discards every pushed route and pushed DNS option, which certainly stops the full tunnel and just as certainly breaks the private routes the deployment depends on, so it is a far bigger hammer than a name filter aimed at one option. Check the private destination, a public destination and the resolver after any change, and treat a completed handshake as evidence of nothing except the handshake.