VPN Authentication Failed: It Is Rarely the Port or the DNS

Authentication failed means the service received an identity and refused it, which is a narrower statement than most people read into it. The port is open, the TLS session may well have completed, and something in the credential or the account was rejected. Changing network settings cannot fix that, and repeating the attempt can lock the account. The error text already names the stage, so start there.

The Error Already Told You Which Stage Failed

A connection that never completes its TLS handshake has not reached authentication at all. A connection that completes the handshake and then reports a credential rejection has reached it and failed there. Those two outcomes need different investigations, and they are frequently confused because both end with a closed window.

OpenVPN makes the distinction explicit with an AUTH_FAILED message from the server, which is a decision rather than a transport error. A TLS negotiation timeout or a certificate verification error belongs to the earlier stage. Read which one you have before touching credentials, because a password reset cannot repair a handshake and a firewall change cannot repair a rejected login. One line of the client log answers the question.

The same logic applies to a session that connects and then drops later. A reauthentication failure at minute forty is a different fault from a first-login rejection, and the interval is the clue.

Confirm the Profile Points at the Right Service

The account used on a provider's website is not always the account its VPN gateway accepts. A saved profile can also point at an old gateway long after the service moved.

Check the endpoint in the profile against the one the operator published, and check which identity system the gateway consults. A password reset on a web portal changes nothing if the tunnel authenticates against a separate directory. Credentials for an unrelated public server will not work on yours, and testing a work password in a profile received through an untrusted message is a bad trade in any case. Confirm the origin before typing anything.

Two minutes on the profile prevents a day of credential guessing.

The Login Format Is Part of the Credential

A username may need an email form, a domain prefix or a directory suffix. The gateway compares the string it received, so the form is part of the credential rather than decoration.

Then rule out the boring causes before escalating. Check the keyboard layout, any trailing space introduced by a copy, and an old entry in the password manager. After a reset, confirm that the VPN uses the same identity source as the page where the password changed. If those details are right, stop guessing and ask the operator whether the account is enabled and authorised for VPN access. That is a service-side correction rather than a client setting.

openvpn --config office.ovpn --verb 3
journalctl -u openvpn-client@office -n 40 --no-pager

The log line carrying AUTH_FAILED usually includes a reason code or a challenge string. Copy it exactly rather than paraphrasing it when you ask for help.

Second Factors Have Their Own Contract

The profile may expect a one-time code, an interactive challenge, or a browser sign-in that hands a token back to the client. Use the flow the operator supports rather than inventing one.

Do not append a code to the password unless that format is explicitly required, because some deployments use a separate field and some use a challenge string. For time-based codes, check the device clock, since a few minutes of skew invalidates every code. If browser login succeeds and the client never resumes, note that exact point, because it identifies the handoff rather than the credential. Another password reset is unlikely to help.

A session limit is the other common rejection. If the account allows one session, a second login can terminate the first, and the symptom looks like a flapping connection rather than a policy.

A Certificate Is Not a Password

A client certificate can expire or be revoked while the account password stays perfectly correct. A private-key passphrase is a third secret again, and it protects a file rather than an account.

Read the error before replacing anything, then obtain the correct replacement from the verified operator. Keep server identity verification switched on while you do it: accepting an unrelated certificate or copying somebody else's private key is not a repair, it is a second incident. Then test the resource you actually need, because a connected tunnel with an unreachable service belongs to a different investigation. Write down which stage failed so the next person does not restart the whole process.

If the session establishes and fails later, record the interval and any nearby renewal events. That record separates a token lifetime problem from a first-login failure, and it is the difference between a five-minute fix and a week of retries.