IKEv2 server address vs identity: what the client actually checks

A gateway that changes address can keep working while the same gateway behind a new certificate stops, and the reverse happens too. The address tells the client where to send packets; the authenticated identity tells the client whether the peer answering is the one it should trust. IKEv2 keeps those as two separate fields, which is useful once you stop treating them as one string. They are also configured in different places, so one can be correct while the other is wrong.

Check them in this order and stop at the first mismatch, because the later checks assume the earlier ones passed.

First, which value is the address

The connection address is whatever the client dials: an IP, a DNS name that resolves to one, or a load-balanced front end. That is transport information and nothing more. The identity rides in the IKEv2 ID payload and is then matched against the peer's certificate. A DNS name in the address box does not become the expected identity, and a raw IP does not become the identity just because the socket connected to it.

In strongSwan terms, the address is right or left, and the expected identity is rightid or leftid, as the IKEv2 configuration documentation describes. If you have only ever edited the address, you have configured half of the pair.

Second, what the certificate can prove

The identity has a type, and the certificate has to carry a matching name. A DNS identity is satisfied by a dNSName entry in the subject alternative name extension; an IP identity needs an iPAddress entry. A certificate issued for vpn.example.com proves nothing about the literal address 203.0.113.10, and one issued for that address proves nothing about the name. Reissuing for a different name is therefore not a drop-in replacement, even when the same key and CA are reused.

Modern clients ignore the common name when a subject alternative name exists, and many ignore it entirely. If the SAN list does not contain the value the client checks, the handshake fails after the certificate has already been accepted as trustworthy, which is why the log reads like an identity error rather than a trust error.

Third, how each client states the expectation

Windows takes the server name or address you typed and requires the certificate to match it, so typing an IP creates an IP expectation. Android's IKEv2 client behaves the same way, and both reject a valid, publicly trusted certificate that names a different host. A profile can start failing merely because someone replaced the hostname with its address during a migration. Look at what the client asked for before you look at what the certificate contains.

On strongSwan the expectation is explicit: set rightid to the identity the server actually presents, which may differ from right. Setting it to %any accepts whatever the peer offers and removes exactly the check you are trying to keep.

Fourth, separate user login from peer identity

EAP authentication and the server identity answer different questions. An EAP identity such as [email protected] says who the user is, after the client has decided that the server is the right one. Rotating that password cannot fix a peer identity mismatch, because the connection never reaches the user-login stage.

A sanitized report should name both: the identity the client expected, the identity the server presented, and the certificate's SAN entries.

Fifth, change it through a verified channel

When the gateway legitimately moves, update the address first and leave the identity alone, because that is the case IKEv2 handles well. When the identity itself changes, treat it as a trust event and get the new value from a source you already trust, not from the endpoint that is currently failing. A message delivered over the connection you are trying to validate is not evidence about that connection.

Record the final address, identity and SAN list together in the profile notes. The next person to touch the certificate will then see which of the three is allowed to move.