Your old default route survives OpenVPN on purpose

You connect the tunnel, run ip route, and the original default gateway is still sitting there. The next thought is that the client failed to take over the route, so you delete the default manually and lose connectivity entirely. That entry is supposed to remain. With redirect-gateway def1, OpenVPN installs two more-specific routes that outrank the ordinary default instead of replacing it. The old gateway stays and stops carrying the traffic you were testing.

What def1 actually does

The flag adds 0.0.0.0/1 and 128.0.0.0/1, both pointing at the tunnel. 0.0.0.0/1 takes every address whose first octet is 0 through 127, and 128.0.0.0/1 takes 128 through 255, so every IPv4 destination has a match more specific than the old default. Prefix length, not metric, decides which route wins.

Leaving the original default in place is deliberate. The client does not have to remember what it replaced, and it does not rewrite the route that carries its own connection to the VPN server. On disconnect it removes the two half-routes and the table returns to what it was.

Why /1 and not /0

Routing picks the longest matching prefix, not the lowest metric, so a /1 beats a /0 whatever the default's metric says. Both halves exist because one /1 covers only half the space; with only 0.0.0.0/1 present, everything from 128.0.0.0 upward still follows the old default, which produces the confusing symptom where some sites work and others do not.

Raising or lowering the old default's metric changes nothing, and a lower-metric default on another interface does not steal the traffic either. Prefix length decides first, and only equal prefixes fall back to metric.

Read an actual routing table

A connected host can show all three entries at once, with the tunnel carrying the halves and the original gateway still listed. The addresses are examples rather than a configuration to copy, because interface names, tunnel topology and extra routes vary by platform and client.

default via 192.168.50.1 dev wlan0
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0

What matters is the relationship: two specific halves above one general default. The old gateway line stays because nothing replaced it.

Check the route the packet actually takes

More-specific routes can still win: a route for a private range, a local subnet or the VPN server's own address is longer than a /1. The tunnel needs an outer path to its server, and sending that connection back into the tunnel would break it immediately. On Linux, ask the kernel instead of reading the table by eye: ip route get with the destination you care about prints the chosen route, interface and source. If policy routing is configured, inspect the rules too, because a rule can select a different table before the main one is consulted.

If only part of IPv4 misbehaves, confirm both halves were installed and then look for an exception matching the failing destination. Deleting the old default is not a fix, and it removes the route the client needs to tear the tunnel down cleanly.

What def1 does not cover

Two IPv4 entries say nothing about IPv6: a host with IPv6 connectivity keeps using its own default until something redirects that family separately, which is why some traffic appears to bypass the tunnel on a dual-stack network. Other clients and network managers implement full-tunnel routing differently, and their tables will not match. The def1 behaviour described here belongs to OpenVPN's documented flag, not to every VPN on the machine.

A kill switch answers a different question: what the machine does when the tunnel drops. Routing precedence decides where traffic goes while the tunnel is up; it does not decide what a firewall does afterwards. Order of work: read the table, confirm both halves exist, run ip route get for the failing destination, check policy rules, then look at IPv6 separately. Leave the old default where it is.