SSH Session Dies With the VPN: tmux or a Job Runner?

Your VPN indicator turns green, the route is back, and the SSH window you left open never returns a prompt. Restoring a path does not restore the TCP conversation that was using it, so anything typed into that window is gone. If the real concern is an editor buffer or a long migration, the fix is to stop tying that work to one connection. tmux and a job runner solve different halves of that problem.

A reconnected VPN does not resume the socket

TCP has no notion of resuming after an address change. The SSH connection is identified by both endpoints, and when the tunnel rebuilds, the local address may change and the old socket is dead. The server notices eventually, but your terminal notices immediately.

A client keepalive detects a dead peer sooner. It does not bring the session back, and it cannot recover a command that was already running. The keepalive is a detector, not a recovery tool. It says nothing about whether the remote command survived.

Put the work on the remote host

Create the session on the remote host, not on the laptop. Connect as usual, start tmux there, and run the editor or migration inside it. Detach with the default prefix and the session keeps running while the SSH connection goes away. Starting tmux locally protects your shell from a closed window, not a remote command from a dead tunnel.

ssh [email protected]
tmux new-session -s office-work

After the VPN is back, open a fresh SSH connection to the same host and reattach by name. The session is the durable object, not the connection. Name it something you will still recognise a week later.

tmux versus a job runner

tmux keeps an interactive process alive while the host stays up. A job runner or service manager keeps a non-interactive job alive, records its exit status, and survives the SSH session ending entirely. The first is for work you watch; the second is for work you schedule and inspect later.

Neither survives a reboot unless the host is configured to restore it. A tmux session dies with the machine, and a transient job dies with the boot unless it was registered as a unit. Choose according to what the work must outlive.

Both approaches also need a log you can read after reconnecting. Without one, you know the process exists but not what it has done. Write the log path down next to the session name.

Decide by what must survive

Decide by the worst thing that can happen if the work stops halfway. An editor session loses unsaved buffers, which is annoying but recoverable. A migration that commits half its changes is not, and that argues for a runner with a recorded outcome. If the job is interactive and long, tmux plus a written log is usually enough.

systemd-run --user --unit=migrate-customers --collect ./migrate.sh

Whatever you choose, inspect the recorded outcome before rerunning anything. A missing final line tells you what the laptop saw, not what the server committed. That distinction is the reason to keep the work off the connection in the first place, and the detach and reattach model is the smallest version of it.