OpenVPN auth-nocache: What Happens at the Next Login

Turn on auth-nocache and the password-caching warning disappears, along with the copy of the credentials OpenVPN was holding for the next renegotiation. Whether that turns into a prompt, a silent retry or a dropped tunnel depends on where the credentials come from the second time. That makes this a comparison between deployment shapes rather than a verdict on the option. Read the shape you actually run before editing any profile.

Where the second set of credentials has to come from

OpenVPN applies auth-nocache to the secrets collected by auth-user-pass and askpass: once they have been used, the process drops them instead of holding them for the next handshake. A renegotiation arrives on a timer, once an hour by default, so the second request lands long after the person who typed the password has moved on. That gap is the whole story. With caching left on, the client replays the stored copy without asking anyone; with caching off, it has to find the secret somewhere else or fail.

So list every place the secret could come from at that moment, and be honest about which of them exist on the host. A person at a terminal, a file that auth-user-pass or askpass can read, or a server-issued session token are the three that matter here. If none of them is available, the renegotiation fails an hour after the change rather than at the moment you made it.

Three shapes, three failure points

A desktop client with a person in front of it is the mild case: the prompt returns, someone types the password again, and the cost is attention. A service, container or router running OpenVPN without a terminal is the harsh case, since nobody is there to answer and the reconnect that used to be silent now ends the tunnel. A hybrid sits between the two, behaving like the desktop case until the session that could answer the prompt goes away. What separates them is not whether a GUI is installed but whether a credential source exists at renegotiation time.

Map your deployment onto one of those three before changing anything, because the advice you find online is almost always written for the first. Applying the desktop answer to a headless service is how a tunnel that worked for months starts dropping every hour.

Directive or flag: pick one and know which you used

Inside a profile, auth-nocache is a line of its own; on an invocation that names a profile explicitly, it is a flag on that command line, and the OpenVPN manual lists both forms. Both do the same thing to credential retention, and neither touches the interface type or repairs an unrelated warning sitting in the same log. The difference is persistence: the flag covers that run only, so a service restarted from a unit file or wrapper script will not have it unless the wrapper passes it too.

auth-nocache
openvpn --config /path/client.ovpn --auth-nocache

Decide which artefact owns the setting, change it there and nowhere else. A profile edited on a laptop plus a systemd unit that overrides it with a flag is the pairing that produces contradictory behaviour after a reboot.

A credential file relocates the secret instead of deleting it

Pointing auth-user-pass at a file gives every later renegotiation a source, and it also puts the password somewhere that survives reboots. Ask who can read that file, whether the daemon can still read it after dropping privileges, and what happens when the filesystem is mounted read-only or a container view hides the path. A secret on disk and a secret in memory are different problems, and solving one leaves the other in place. Rotation is the step that gets skipped: a password changed on the server but not in the file produces a failure that reads like a network fault.

Keep the file owned by the account that runs the daemon, readable by nobody else, and outside backups that leave the host. OpenVPN's server-side auth-gen-token option hands the client a session token after a successful login, which is a smaller thing to leave lying around than the account password. Write the rotation step next to the file either way, because the file usually outlives the person who created it.

Stretching renegotiation moves the cost, it does not remove it

The other suggestion is to raise reneg-sec until the prompt is rare enough to ignore. That rewrites the session's key-rotation schedule and pushes the same credential problem to a later, less predictable moment; it does not create a credential source. A policy that renews keys on a schedule for a reason should not be relaxed just to avoid typing a password.

Test the reconnect rather than the session you are sitting in, because the live session proves nothing. Drop the tunnel from the server side, or restart the client service, and watch what the next renegotiation does with nobody at the keyboard. If it reconnects, name the mechanism that supplied the secret; if it does not, you have found the real cost of the option on this host. Either outcome gives you an answer that holds during an outage instead of one that held during testing.

On a managed fleet, whoever owns the deployment should be able to name three things: where the credential comes from, where it is stored, and who rotates it. If any of those answers is the person who set the host up, the option is not yet safe there.