Keep Local SSH When the Host Runs an Outbound VPN

A small Linux server runs an outbound VPN for the application it hosts, and the administrator still wants to reach it over SSH from the desk next door. That is a reasonable requirement, and it usually needs no port forwarding, no provider address, and no hole in the tunnel. What it needs is a management path that is designed on purpose instead of inherited from whatever the VPN client did to the routing table.

The steps below assume the administrator is on the same LAN. Remote administration is a different problem with a different answer.

Bind SSH to the address administrators use

Start from the listener. ss -ltnp | grep :22 shows what sshd is bound to, and a listener on 0.0.0.0 accepts connections from every interface, including the tunnel. Binding to the LAN address is narrower and makes the intent visible: ListenAddress 192.168.10.20 in sshd_config, followed by a configuration test and a reload. A typo in that address is more visible than a wildcard, because sshd refuses to start when the address does not exist.

Keep host-key checking and per-user authentication exactly as they are. "It is only the local network" is not an authentication method, and a management channel that skips key verification because the route is short is a management channel waiting to be abused. A DHCP reservation or a static address makes the target predictable without turning it into the server's public identity.

Keep the LAN route out of the tunnel

A host with an address on 192.168.10.0/24 has a connected route for that prefix, and a more specific route beats the VPN's default inside the same table. That is why local SSH often keeps working by itself when the tunnel comes up. Verify it rather than assuming: ip route get 192.168.10.50 names the interface and source address the kernel would use, and the answer should be the LAN device, not the tunnel. Repeat the check from the administrator's machine too, because its own table decides whether the packets ever arrive. Two hosts on the same wire can disagree about which direction is reachable.

The assumption breaks in two places. A policy-routing rule can send traffic to a table whose default points into the tunnel before the main table is consulted. A VPN client with a lockdown or kill-switch feature can also block traffic that does not enter the tunnel, regardless of what the route table says.

Routed management VLANs are the other case. If the administrator sits on 192.168.50.0/24 behind the local router, the server needs an explicit route for that prefix through 192.168.10.1, and that route has to survive a reconnect. Keep the exception specific to the management prefix; a broad private-range exception defeats the purpose of the tunnel.

Make the firewall exception as narrow as the rule

If the host runs a firewall, permit SSH from the management source only, on the LAN interface only. A rule that allows port 22 from anywhere is broader than the requirement and harder to justify in a review. On an nftables host the rule belongs in the input chain with the interface and source matched; on an iptables host the equivalent is a pair of matches on -i and -s. Comment the rule with the administrator group it serves, so the next audit does not have to guess why port 22 is open.

Check the VPN client's own filter as well. Some clients install rules that drop local traffic by design, and a correct firewall rule on top of a client-level drop changes nothing. Read the client's configuration before editing the host firewall, because two filters in series produce a failure that looks like neither one.

Test both states

Run the test twice: once with the tunnel connected and once with it disconnected. In each state, confirm the listener, the route, and an actual SSH login from the administrator's machine. A path that works only while the tunnel is up is not a local management path; it is a coincidence.

Then restart the tunnel while an SSH session is open. A session that survives proves the routing is stable; a session that drops tells you the client is rewriting routes or filters on reconnect, which is worth knowing before an incident rather than during one.

Record the source address you tested from, because a rule written for 192.168.10.50 fails silently when the administrator's laptop moves to another subnet.

Write the recovery path into the runbook

Decide now what happens if the outbound VPN breaks the local path. Console access, a second management address, or a documented procedure for stopping the client are all legitimate answers, and any of them is better than discovering the problem at the moment you need to log in. If the server is remote, the local path does not exist, and the correct design is a separate approved remote-access route or a bastion rather than an exposed public port.

Keep the two roles separate in the documentation: local SSH for the administrator who is nearby, and the outbound tunnel for the application's traffic. When those roles are written down, a future change to either one has an obvious place to be checked, and the next person does not have to rediscover why a server with a VPN still answers on its LAN address.