How IKEv1 hybrid auth maps onto IKEv2 user authentication
Hybrid mode split gateway proof from user proof. Moving to IKEv2 keeps that split but changes the exchange, the EAP method and the certificate checks.
Every legacy VPN profile that asks for a server certificate and then for a username carries two authentication events inside one exchange, and that shape outlives the protocol that introduced it. IKEv1 hybrid mode was built for exactly this: the gateway proves itself with a public key while the user proves themselves later through XAuth. IKEv2 expresses the same two-step idea with different machinery, and those differences are where migrations fail. No version number converts one into the other, and copying the old option names into a new profile yields a client that negotiates and then authenticates nothing.
What hybrid mode did inside IKEv1
In a hybrid profile the responder signs the phase-one exchange with its certificate while the initiator deliberately presents none. The identity proof is therefore asymmetric, which is what let a gateway keep its existing PKI while users kept directory passwords. Once phase one completes, XAuth runs as a request and reply that carries username and password attributes inside the now-encrypted ISAKMP channel.
Note where the trust lands. The certificate answers which gateway the client reached; XAuth answers which user wants access. Neither substitutes for the other, and a client configured to accept any server certificate has quietly discarded the first answer. The label hybrid also gets used for aggressive-mode pre-shared-key plus XAuth, a different arrangement with the same user experience, so read the profile rather than the name. Both variants trace back to drafts that never became standards, which is why two vendors can implement hybrid mode and interoperate with neither.
How IKEv2 reaches the same two proofs
IKEv2 splits the work across IKE_SA_INIT and IKE_AUTH. The first exchange agrees proposals and keys with no identities at all; the second carries IDi, IDr and the AUTH payloads. Under EAP the initiator's first AUTH payload goes out empty, the responder authenticates first with its certificate and signature, and the EAP conversation then runs inside IKE_AUTH messages.
The mechanism that makes this safe is key material. A successful EAP method exports a session key, and the initiator's final AUTH payload is computed from it, so the user's proof and the tunnel's keys are bound together. XAuth has no equivalent: its attributes arrive after phase one and contribute nothing to the keys. That gap is exactly what the IKEv2 framework was designed to close, and it is why a working IKEv2 login validates the server certificate before it prompts for anything.
This ordering is also a useful diagnostic. When a client complains about credentials before it has shown you a certificate, it is not doing an IKEv2 EAP exchange at all.
Keep three identities separate
A migration goes wrong when three identities collapse into one field. There is the gateway identity the client validates, usually a DNS name in the certificate subject or SAN. There is the user identity presented in EAP, which may be a domain login, an address or an explicit EAP identity string. And there is the authorization source that maps that user onto networks and routes.
strongSwan's swanctl syntax makes the split visible: the connection sets remote { auth = pubkey } for the gateway and local { auth = eap-mschapv2 } for the user, with the EAP identity carried separately.
When the user identity in the new profile differs from the old XAuth attributes, a UPN rather than a short name for instance, the authentication server sees an unknown user and the failure looks like a bad password. Check the identity string before you check the credential.
Map the options, then expect the traps
The mapping is short, and every row has a trap that appears only at authentication time.
| Legacy hybrid element | IKEv2 equivalent | Where it bites |
|---|---|---|
| Gateway certificate, no client certificate | Responder authenticated with pubkey, initiator with EAP | The server needs an EAP method configured, not just a certificate |
| XAuth username and password | EAP-MSCHAPv2 or an inner method | Password policy and account format differ from the old directory field |
| XAuth attribute replies | IKEv2 configuration payload | Attribute numbering is unrelated; nothing is renamed |
| Proxy IDs from quick mode | TS_i and TS_r in IKE_AUTH | Narrowing on the responder can leave an IKE SA with no child SA |
None of those rows is a rename. The configuration payload delivers addresses and resolvers through a typed attribute list, while XAuth's attribute space was its own invention; treating them as interchangeable is how a profile ends up asking for a setting the gateway will never send.
Traffic selectors deserve their own warning. IKEv1 expressed interesting traffic through proxy IDs bound to a quick-mode exchange, whereas IKEv2 negotiates selectors during IKE_AUTH and the responder may narrow them. A mismatch produces an established IKE SA with no child SA, which some clients happily display as connected.
Treat the old connection as a boundary
RFC 9395 deprecates IKEv1, so a legacy hybrid connection is a compatibility boundary with a date on it, not a foundation. Run both profiles side by side during the change, because the test that matters is not whether the new profile comes up but whether the same user on the same device reaches the same resources.
Keep certificate validation strict throughout. Once the client stops presenting its own certificate, the temptation is to relax the server check until the handshake completes, and that trades the only remaining proof for a green icon.
Write down four things before you retire the old profile: the EAP method, the identity string, the authorization source, and the date support ends.