OpenVPN authentication failed (AUTH_FAILED)

The client log prints AUTH: Received control message: AUTH_FAILED, then SIGTERM[soft,auth-failure] received, process exiting, and the connection is gone. OpenVPN authentication failed means the server evaluated the credentials it was given and refused them. It does not tell you which credential, and it does not tell you why.

That is the whole difficulty. The reason lives in a server log you cannot read, so every useful diagnosis has to be built from what your own client printed.

Check one thing before you continue. If your log reached Initialization Sequence Completed and the tunnel came up, authentication succeeded and your problem is elsewhere. Read OpenVPN connected but no internet instead.

AUTH_FAILED is a control message sent by the server, not a conclusion your client reached. It arrives after the TLS session is already established, which means the transport worked and the certificates were accepted well enough to talk. The server then ran its authentication step and returned a refusal.

Read that in both directions. It rules out a blocked port, a wrong protocol and a broken TLS handshake. None of those would have reached the point of receiving a control message at all.

Four causes account for almost all of it. Work down them in order, because the first two are free to check and the last two are not.

The credentials are wrong or the account is inactive

Start here even when you are certain. The most common mechanism is not a forgotten password, it is the wrong set of credentials entirely. Many services issue a separate VPN username and password that is not the one you log into the website with, and the two look interchangeable from the outside.

Force an interactive prompt so you can see exactly what is being sent.

sudo openvpn --config profile.ovpn --verb 4

The client prints Enter Auth Username: and Enter Auth Password: and uses what you type rather than anything stored. If a hand-typed attempt succeeds where the saved one failed, the credential store is the fault and the section below is your fix. If the hand-typed attempt fails too, the credentials themselves are wrong or the account is not in a state that permits a connection.

Check the account state next, in managing your account credentials. An expired subscription, a suspended account and a mistyped password all produce the identical AUTH_FAILED line.

Note that the client does not sanitise a credentials file for you. auth-user-pass reads two lines literally, so four things that are invisible on screen change what gets sent.

• A trailing space after the username or the password is part of the value.
• A file saved with CRLF line endings can leave a carriage return on the end of each field.
• A byte order mark written by a Windows editor sits in front of the username.
• A third line, or a blank line before the username, shifts both fields.

Rule all four out by typing the credentials at the prompt once. If the interactive attempt works and the file does not, the file is the fault and its contents are the place to look.

A cached password is being resent

This is the cause that survives longest, because the reader is convinced the credentials are right and is correct about that. A stale password stored by the client is resent on every attempt, including after you changed it.

auth-user-pass with a filename argument reads the username from the first line of that file and the password from the second. Read the file and confirm what it contains.

grep -n "auth-user-pass\|auth-nocache\|auth-retry" profile.ovpn

If auth-user-pass names a file, that file is the credential source and the client will never prompt you. If it names nothing, the client prompts on first use and may then cache the answer in memory for the life of the process.

auth-nocache turns that memory cache off. Adding it does not fix a wrong password. It does change the failure into something you can see, because the client asks again instead of silently reusing a stored value. That is also why it produces repeated password prompts, which is a separate complaint with the same root. auth-nocache and reconnection flags documents the flag on its own.

The certificate has expired or was revoked

Check whether this cause can apply to you before working through it. It applies only to profiles that carry a client certificate, and not every service issues one. PulseVPN profiles authenticate with auth-user-pass, a username and a password. They carry an inline <ca> block and no <cert> or <key> block, so a PulseVPN subscriber holds no client certificate that can expire. Skip to the next cause if your profile came from PulseVPN. Read on if it came from anywhere else.

A profile that does carry a client certificate carries it in an inline <cert> block, and certificates have an end date. When yours passes it, the server rejects the connection at the authentication stage and you get the same message you would get from a bad password.

Read the dates out of the profile directly.

openssl x509 -in profile.ovpn -noout -dates -subject

That works when the certificate is the first PEM block in the file. Otherwise extract the <cert> block to its own file first and run the same command against it. Compare notAfter against today. An expired certificate cannot be repaired locally, and the fix is a new profile: see generating a fresh config.

Revocation looks identical from the client and cannot be checked from the client at all. The server holds the revocation list. If the dates are valid and everything else on this page is ruled out, revocation is the remaining candidate.

Read the expiry off the profile you hold rather than assuming a schedule for it. Run the command above on the day you download a config and write the notAfter date down. A profile that authenticated for months and then stopped has an obvious first suspect once that date is somewhere you can find it.

The server rejected the connection for a reason unrelated to your password

AUTH_FAILED is the server's general-purpose refusal. Several conditions that have nothing to do with credentials are reported through it, because the protocol gives the server no better channel.

Four are worth knowing about.

• A concurrent-connection limit reached, where the credentials are correct and one session too many is open.
• A subscription that lapsed between your last successful connection and this one.
• A specific server withdrawn for maintenance while the rest of the fleet still accepts you.
• A server-side authentication backend that is down, which refuses everyone equally.

Test the third and fourth by changing only the server. Take a profile for a different endpoint and connect with the same credentials. Success on one endpoint and failure on another is a server-side fault and no amount of local work will move it.

A fifth condition belongs here for services that require a second factor. Where a one-time code is expected, the client has to be told to ask for it. static-challenge "Enter code" 1 prompts for the code alongside the password, and the second argument controls whether the response is echoed. Without that line the client sends a password where the server expects a password and a code, and the refusal arrives as the same AUTH_FAILED. Some deployments instead expect the code appended to the password in one field, so confirm which convention your service uses rather than guessing between the two.

PulseVPN subscriptions cover three simultaneous connections, so a forgotten fourth device is a real candidate on this account. Disconnect the others and retry before you go looking for anything subtler. The same test applies to any service that caps sessions, and it costs one minute.

The log is the only evidence you have. Run with --verb 4 and match what you see against this table. Each line rules something in or out.

Two of those rows deserve emphasis. The absence of a username prompt is positive evidence rather than a non-event, because it proves a stored credential is in play. And SIGTERM[soft,auth-failure] is not a second fault. It is the default auth-retry none behaviour doing what it is documented to do.

auth-retry decides what happens after that refusal, and it takes three values worth knowing. none exits, which is the default and the behaviour above. nointeract retries using the credentials it already has, which loops forever against a password that is genuinely wrong. interact asks you again, which is the only one of the three that gives a wrong password a chance to become a right one. Set interact while you are diagnosing, because it turns one attempt per client start into several. Set it back afterwards if an unattended client needs to fail rather than sit at a prompt.

Match this table against your own log rather than against your memory of one. Wording drifts between client versions, so read it as a map of what to look for and not as a transcript. When you search for a line, search the whole line, because a remembered fragment returns threads about other faults.

A stored password that no longer matches is invisible until you remove it. Clear it before you conclude the credentials are wrong, because the two produce identical log output. Where the value lives depends on which client imported the profile rather than on the profile itself, so check using your OpenVPN profile if you are unsure which client you are running.

Windows

Look for a plain text file named by auth-user-pass in the same folder as the profile. OpenVPN GUI documents two places it reads profiles from: the system-wide C:\Program Files\OpenVPN\config and the per-user C:\Users\username\OpenVPN\config, including their immediate subdirectories. Check both, because the copy you are editing may not be the copy that runs.

Delete the credentials file and reconnect, so the client has to prompt you. If you used the client's own save-password feature, the value lives outside the profile and deleting files changes nothing. Clear it in the client, then confirm the next connection asks again. OpenVPN GUI also documents a disable_save_passwords setting for turning the feature off entirely.

macOS

Credentials saved by a macOS client are usually held in the login keychain rather than on disk. Open Keychain Access, search for the client name and then for the server hostname, and delete what matches. Reconnect afterwards and expect a prompt. If no prompt appears, something is still holding a stored value and you have not found all of it yet.

Linux

Check the profile for an auth-user-pass filename first and remove that file. A connection imported into NetworkManager stores the password elsewhere. It sits either with the connection profile under /etc/NetworkManager/system-connections/ or in the desktop keyring, depending on the password flag set at import time. Use nmcli connection show <name> --show-secrets to read what is stored, and re-import if it is wrong.

A connection that succeeds and then fails a few minutes later is a different shape of problem. Authentication worked, so the credentials are correct. What follows is a renegotiation, and a renegotiation can fail on its own.

auth-nocache is the usual reason. With the memory cache disabled, the client has no password to present when the session renegotiates, so it prompts or fails. That produces the repeating disconnect and reconnect loop that looks like an unstable network and is not one.

Three other flags govern this behaviour. keepalive sets the ping interval and the timeout that triggers a restart. float allows the peer address to change mid-session, which matters on a roaming client. resolv-retry infinite keeps the client retrying name resolution instead of exiting. All three are covered in auth-nocache and reconnection flags.

Decide which behaviour you want rather than stacking flags. Removing auth-nocache keeps the credential in memory and stops the prompting, at the cost of a password sitting in the process. Keeping it means accepting a prompt on every renegotiation.

AUTH_FAILED is the server refusing you after the control channel is already up. If your log never reaches it, and instead ends with TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity), the transport never came up and no credential was ever evaluated. That is a port, protocol, tls-crypt or clock problem with an entirely separate check order, and it belongs on OpenVPN TLS handshake failed.