OpenVPN redirect-gateway: What Each Flag Does to Routes

Connect with redirect-gateway in the profile and your machine's default route may vanish, split in two, or stay exactly where it was, depending on flags nobody reads twice. The option edits routing state and nothing else, so the only trustworthy evidence of what it did is the table the client installed afterwards. What follows is the table after a connection, the route that keeps the tunnel itself alive, and the IPv6 traffic the directive never claims to cover. Every step is a command you can run on the client while the tunnel is up.

What Each Flag Does to the Default Route

With no flag at all, the option removes the ordinary default route and puts the tunnel in its place, so the old gateway disappears from the table while the connection is up. Add def1 and that default stays listed, with two narrower routes doing the work instead. Add bypass-dhcp and the DHCP route survives as well, which matters on a network where the client still has to reach the local DHCP server. The flag list on the OpenVPN 2.6 manual page is short enough to read once, and every entry changes which routes end up in the table.

A pushed option behaves the same way once it arrives, so the client profile may contain nothing at all while the table looks fully redirected. That is normal: the server sent the flags, the client applied them, and the local file never mentioned the directive. When a push appears to do nothing, check the client-side filter that accepts or drops pulled options, because a dropped option raises no error on either end.

def1 Wins by Specificity Without Touching Your Default

Two half-default routes cover the IPv4 space between them, 0.0.0.0/1 and 128.0.0.0/1. Each is more specific than 0.0.0.0/0, so a lookup prefers them while the real default stays in the table for anything that asks for the least specific match.

Read the table rather than the profile, because only the table shows which of those cases you are in. Two lines are enough to tell them apart:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

Note the interface and the metric on every line, not just the destination. A default pointing at the tunnel and a half-default pair pointing at the tunnel describe the same intent and fail differently when the tunnel drops, because the fallback still exists in one case. Record both fields in the change note. A surviving fallback is sometimes what keeps a remote session alive long enough to repair the tunnel, and it is also what leaks traffic when the intent was a full tunnel.

Keep the Tunnel Endpoint Reachable

The client needs a route to the far end of the tunnel that does not itself run through the tunnel. OpenVPN installs that host route before it changes anything else, and a manual route edit or a second VPN client can take it away. The symptom afterwards is a connection that reports connected and then passes nothing.

Ask the kernel which interface it would use for the endpoint address while the tunnel is up. The answer must name the physical interface and its gateway, never tun0:

ip route get 198.51.100.20

If that lookup returns the tunnel device, the tunnel is carrying its own transport and will collapse as soon as a packet needs to leave. Local prefixes, a second adapter and policy routing still matter here, which is why a redirect that works on a clean laptop can fail on a host with a management interface and two defaults. The profile usually gets blamed for what the address plan did.

IPv6 Traffic Keeps Using Its Own Table

Redirecting IPv4 leaves IPv6 alone, and the two families are changed by different flags. On a dual-stack host with a working v6 default, v4 traffic can sit fully inside the tunnel while every v6-capable destination leaves over the physical link. A host that looks correct in one table is leaking in the other.

Check the v6 table after connecting instead of assuming the tunnel covered it. The directive carries address-family flags for exactly this reason, and a profile that omits them inherits whatever the platform does by default:

ip -6 route show default
ip -6 route get 2001:db8::10

Prove Which Interface an Application Uses

A connected state is not a block, and a route change is not a kill switch. If direct traffic has to stop when the tunnel fails, that policy lives in the firewall and needs a test of its own.

Test the path an application really takes rather than the path the profile describes. Ask for the route first, then bind a request to each interface in turn and compare what the far side reports:

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

If both requests return the same address, the application is not using the tunnel even though the routing table says it should. If only the tunnel-bound request succeeds, the physical path is filtered for that destination and the tunnel is doing what you asked. Write the flags, the installed routes, the endpoint lookup and both egress results into the change record, so the next person inherits facts instead of a screenshot.