Full Tunnel Killed Your SSH Session: Pin the Return Route

Start an OpenVPN client on the box you are working in over SSH, and mid-command the session freezes. The tunnel reports connected, the host can reach the internet through it, and your own keystrokes still arrive while nothing comes back. What changed is not the tunnel: it is the return path for packets addressed to you, which now matches the new default route and enters a tunnel the remote gateway will not use to reach your desk.

What redirect-gateway actually installs

In its def1 form, redirect-gateway adds 0.0.0.0/1 and 128.0.0.0/1 instead of overwriting the default route. Those two halves cover the whole address space while both remain longer prefixes than 0.0.0.0/0, so any destination without a more specific match now goes into the tunnel. That is the mechanism to hold onto, because every fix below works by installing a more specific match.

Your administrative address is one of those destinations.

The VPN server forwards traffic for its clients toward the internet. It has no route for the public address you are connecting from, and no reason to treat those packets as anything other than traffic arriving from a client, so it drops them. Meanwhile the request you sent still reached the host, which is why the session looks alive on one side only.

ip route show table main | head -n 20
ip route get 198.51.100.23

Find your source address and the pre-tunnel path

On the server, list the established SSH connection and note the peer address it came from. That address is what your return route has to cover, and it is not always what you think it is: a jump host, a NAT gateway or a carrier-grade translator can substitute a different source.

Then find the physical gateway and interface that carried traffic before the tunnel started. In the def1 arrangement the default route is still present beneath the half-defaults, so the information is available, though reading a long route table by eye invites mistakes.

Record both values and the interface name together, because the route you are about to add needs all three. If the host used a policy routing rule to pick its uplink, a plain route may not be consulted at all, and that possibility changes the fix.

Pin a host route that outranks the half-defaults

A /32 route is longer than either half-default, so replies to your address take it in preference to the tunnel. The next hop is the pre-tunnel gateway and the device is the physical interface, which keeps the packet on the path it used before the tunnel existed.

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

Verify with a lookup rather than by inspecting the table: the answer must name eth0 and the gateway, never tun0.

OpenVPN already adds a host route to the VPN server's own address for the same reason, so the pattern is familiar and the administrative address is simply another exception. Do not reach for route-nopull to fix this, because it discards the pushed routes the tunnel needs, including the remote network and DNS options.

Make it survive a reconnect

A route added by hand disappears when the client reconnects and reinstalls its own, which turns a fix into a recurring outage. Attach the command to something that runs after routes are installed.

A route-up script or the network manager's pre-up hook both work, and the reliable check is a reconnect followed by the same lookup.

On Windows the equivalent is a persistent route added with -p, which survives reboots but still has to point at the correct gateway after a network change. Whatever the platform, write the reason next to the route: the next administrator needs to know it exists to protect a management session, not because the network design required it.

When a pinned route is still not enough

Reverse-path filtering can drop a packet that arrives on one interface and leaves by another, which is exactly what a pinned route creates. Check the effective rp_filter value before disabling anything globally, and prefer fixing the asymmetry to turning the check off. The per-interface setting is the one that applies, and loose mode often only logs the asymmetry rather than dropping the packet. Read both before concluding that the filter is your fault.

Hosts with policy routing need a rule as well as a route, because the rule base selects the table before the route inside it is consulted. A route in the main table is invisible to a flow that matches a rule pointing at another table. Read the rules before you add anything to main. If a rule already covers management traffic, the exception belongs in that rule's table instead.

Keep an out-of-band console open while you test, and recheck from a second login before you disconnect the one you are using. A route that sends your own management traffic into the tunnel cuts the connection you are repairing it through. Getting back in then means a serial console or a rescue boot, which is a poor trade for skipping one verification step.