IKEv1 with XAuth and OTP: what each prompt is asking for
A group PSK, a user XAuth exchange and an OTP challenge are three different inputs. Match each prompt to its owner before installing another client.
IKEv1 with PSK, XAuth and OTP is not asking for one complicated password. It layers a shared key between peers, a user exchange, and a second factor that the backend decides how to request. Each layer has its own owner and its own failure message. Confusing them sends people to retype a one-time code into a field that stores a group secret.
Match each prompt to the layer that asks for it before installing another client or resetting a credential.
Three secrets, three owners
The pre-shared key belongs to the peer relationship and is configured once by whoever owns both ends. The user credential belongs to the authentication backend and is validated per login. The second factor belongs to a token system whose response changes every attempt. None substitutes for another, and a deployment that treats them as one password fails at the layer nobody documented.
Write three columns down: owner, lifetime, and the failure message each one produces. That table is the diagnostic tool, and the client's field names are not.
| Layer | Owner | Lifetime |
|---|---|---|
| Pre-shared key | Peer configuration | Until operators change it |
| XAuth credential | Authentication backend | Per session, per policy |
| One-time code | Token system | Single use |
PSK: the peer, not the person
The pre-shared key authenticates the gateway pair in this legacy arrangement, so the user's login never replaces it. It is also the value most likely to be wrong in a way that produces a generic negotiation error instead of a prompt. When the tunnel fails before any user prompt appears, the key or the proposals are the suspects.
A user credential cannot repair a phase-one failure. Rotating it wastes the one credential you can safely rotate, and it reinforces the wrong theory.
XAuth: the legacy user exchange
XAuth adds a user authentication exchange on top of IKEv1 peer authentication, and the gateway decides which backend validates it. Depending on that backend, the exchange may accept a directory password, a RADIUS credential or a token response. The word XAuth names the transport of the exchange, not the credential type.
Check which backend the gateway profile points at. That tells you what the user will be asked for and what a password reset actually changes, and neither is visible in a client profile.
OTP: whatever the backend asks for
Some deployments prompt for a separate one-time code after the password, and others define a combined input format with a documented separator. Both exist, and the profile in front of you decides which. Inventing a concatenation because it worked at another site is the most common way to burn an enrollment token. The gateway's own documentation is the only source that settles it.
Use the documented format with a client that can complete the exchange the gateway offers.
Where the client boundary bites
Fortinet documents that FortiClient 7.4.4 and later no longer support IKEv1 for IPsec VPNs, which is a product and version boundary rather than a universal removal, as the FortiClient compatibility note records. Other clients are not interchangeable either: OpenConnect and openfortivpn speak particular gateway protocols, not arbitrary IKEv1 profiles. Check the installed client's IKE version, PSK mode, XAuth support and interaction model individually. A client that connects using a different method has not proven the original requirement.
IKEv1 is deprecated, so a new rollout built on an unsupported old client is a short-lived solution. Ask the gateway owner for a supported migration path, including how the second factor will be handled there.
Diagnosing without disabling the factor
Separate the stages in the log: peer negotiation, the user exchange, the second-factor result, then address and route assignment. Record the component and the stage instead of trying the code in every field. Disabling the factor so a test passes produces a tunnel that proves nothing about the deployment.
Keep enrollment secrets and the shared key in protected storage under the organization's process. A one-time code in a persistent file is a factor that has stopped being one.