ifconfig-noexec Will Not Save Your SSH Session: What It Does
It suppresses OpenVPN's own interface address setup. It does not reserve an SSH reply route, disable every route change, or supply the missing address.
Somewhere in a forum thread, ifconfig-noexec is offered as the fix that keeps an SSH session alive when a tunnel comes up. The reasoning sounds plausible until you check what the option touches. It stops OpenVPN from configuring the tunnel interface's address and hands those values to scripts instead; it has nothing to say about where replies to your management connection go. Believing otherwise produces a tunnel with no usable address and an SSH session that still dies.
What the option actually delegates
By default, the client brings up the tunnel device and assigns the local and remote addresses that the server handed it. With ifconfig-noexec set, that step is skipped, and the negotiated values are exported to the script environment so something else can apply them.
Ownership moves. Nothing is invented in its place.
So the question the option answers is who configures the interface, and the question it does not answer is how packets find their way back to you. Keep those separate or you will spend an evening editing routes to compensate for an interface with no address.
Three similar options with different jobs
The family is easy to confuse because the names differ by one word and the symptoms overlap. Read what each one suppresses before choosing any of them.
| Option | What stops happening |
|---|---|
ifconfig-noexec | OpenVPN's own tunnel-address configuration; values go to scripts instead |
route-noexec | Automatic route addition and removal; route details go to a script |
route-nopull | Server-pushed routes and related options such as DNS are rejected |
These are alternatives to understand individually, not a set to paste together. Suppressing address configuration does not suppress route changes, firewall rules or the pushed options that carry DNS. A delegated script is also free to change routes, which is a decision you are handing over rather than avoiding.
If a vendor client wraps the engine, use its supported integration instead of dropping a low-level directive into a profile and hoping the wrapper respects it. Wrappers often regenerate the profile on connect, so a manual edit disappears without an error. Check where the client keeps its settings before spending an evening on the file. That applies to every row in the table, not only the one you came for.
The SSH session you meant to protect
An SSH connection has a source address, a destination address and a reply path. On a server that has just installed a full-tunnel default, the reply to your public address matches the tunnel, and the VPN gateway drops it.
Nothing in the address configuration of the tunnel interface changes that.
What fixes it is a more specific route for your management address through the pre-tunnel gateway, or a policy rule that steers that traffic, plus whatever filter settings your host applies. The two problems sometimes appear together, which is how one gets mistaken for a cure for the other. Test them separately: bring the tunnel up without the option, look at the interface address and the reply path, then decide which of the two is actually broken.
What a delegated script has to take over
If you genuinely want another owner to configure the interface, enumerate the work: apply the local and remote address, bring the device up, restore or remove the addressing at teardown, and do the same again after a reconnect. Values from one successful session must not be hard-coded, because the server may hand out a different pair next time.
The environment variables the client exports are the only supported input for that work.
env | grep -E '^ifconfig_|^route_'Within a route-up script those variables are available; from a cron job or a manual shell they are not. Confirm which lifecycle hook your version uses, and confirm the hook runs with enough privilege to change the interface, since the client may already have dropped to an unprivileged user.
Test the whole lifecycle, not one session
Bring the tunnel up, check the address on the device, then reconnect and check it again. A configuration that works once and fails on the second attempt usually means the delegated step only runs on the first connect.
Then test both acceptance criteria together: a fresh SSH connection through the intended management path works, and a permitted application uses the tunnel correctly.
An old SSH session that happens to survive while the tunnel has no address is not a success, and it is exactly the state this option produces when nobody takes over the work. Check the interface address first, then the management reply path, then the application. If two of the three are wrong, the option moved work without giving it an owner.