When WatchGuard Mobile VPN with SSL refuses your login, the message on screen is the least informative part of the story. The client itself never decides who you are — it passes your credentials to a backend the administrator configured: the Firebox's own user database, a RADIUS server, Active Directory through a domain controller, or an identity provider with multi-factor authentication. Each of those backends fails for different reasons, and each failure looks identical from the login prompt.
So the first step is not to retype your password. It is to find out which system your organisation uses to verify VPN users, because that determines whether the problem is your account, your password, a second factor, or a server somewhere in the office you have never seen.
Rule out the keyboard before suspecting the system
It sounds trivial because it is trivial, and it is still one of the most common outcomes. Caps lock, a different keyboard layout than the one the password was memorised in, an autocorrected trailing space in a pasted password, or a stale saved credential in the client's prompt all produce "wrong password" for a correct one. Type the password into a plain text field once to see exactly what is being sent, then delete it immediately.
If your workplace uses Active Directory, remember that the VPN password is usually the same as your normal workstation login — including any complexity or expiry policy that applies to it. A password changed yesterday for network login purposes is now the password the VPN expects, and the old one is what muscle memory keeps offering. This single mismatch explains a remarkable share of Monday-morning authentication tickets.
Understand what a lockout actually is
Authentication systems protect themselves. After several failed attempts, an account can be locked for a period, or until an administrator releases it. The painful detail is that a lockout triggered by the VPN does not always announce itself as a VPN problem: the same account may also be locked for other services, and repeated VPN attempts while locked extend the lockout rather than wait for it to end.
If your attempts were rejected several times and now every attempt fails instantly even though you are certain the password is right, stop trying. Wait out the lock period without any further attempts, confirm the password is current through an official internal channel, and then try once. More attempts do not accelerate recovery; they demonstrate the opposite of what a lockout is designed to achieve.
Work through the second factor deliberately
Organisations that require multi-factor authentication add a second step with its own failure modes. If a push notification never arrives, the phone may have no data connection, the authenticator app may have drifted out of time synchronisation, or the registered device may have been replaced without the method being updated. If a code is required, check that you are generating it from the app your organisation actually registered — people routinely have two authenticator apps and read from the wrong one.
Never approve an unexpected prompt. An approval request you did not initiate is either a stale request or someone else trying your credentials, and in both cases the correct response is to deny it and report it. Authentication prompts should follow a login you personally started, on the device you personally use.
Separate account problems from service problems
If every colleague can connect and only you cannot, the problem is your account: password state, lockout, expired credentials, or a missing second factor. If nobody can connect, the problem is a server: the authentication backend is down, the connection between the Firebox and the directory is broken, or the policy itself was changed. This one observation — me versus everyone — saves administrators more time than any other piece of information.
Test your credentials in another internal system that uses the same backend, if one exists. If the same password fails there as well, the account is the problem, and no VPN-specific action will help. If it succeeds there but fails in the VPN client, the failure lives specifically in the path between the gateway and the authentication source, which only your administrator can reach.
Report failures in the language backends understand
A useful authentication report contains the client version, the exact error wording, the time with time zone, whether the account works on other internal services, and how many attempts preceded the failure. What it never contains is the password itself, a screenshot with characters visible, or a second factor code — those belong to you alone, permanently.
For general context on what the client does after a successful login, the overview on our home page describing WatchGuard Mobile VPN with SSL is a reasonable companion to this article. And when credentials are genuinely forgotten, only your administrator or the official password reset process can restore them — this fan site has no ability to see or reset anything, and anyone claiming otherwise is not to be trusted.
A short order of operations
When a login fails, this order resolves the majority of cases. Verify the keyboard and layout. Confirm the password is the account's current one. Stop attempting if a lockout is plausible. Check the second factor on the right device. Determine whether the failure affects only you or everyone. Then report with evidence. Skipping to the last step without the earlier checks is what turns a two-minute fix into an afternoon of tickets.