| Previous | Next |
| ERROR_IPSEC_IKE_STRONG_CRED_AUTHORIZATION_FAILURE | ERROR_IPSEC_IKE_STRONG_CRED_AUTHORIZATION_AND_CERTMAP_FAILURE |
ERROR_IPSEC_IKE_AUTHORIZATION_FAILURE_WITH_OPTIONAL_RETRY
ERROR_IPSEC_IKE_AUTHORIZATION_FAILURE_WITH_OPTIONAL_RETRY is an authorization denial with a useful qualification: the failure may be resolved by presenting updated or different credentials, such as a smart-card credential. It is not a recommendation to retry the same handshake repeatedly.
A meaningful retry follows a change in evidence available to the authentication stack: a smart card is inserted and unlocked, a renewed certificate and its private key become available, the correct account is selected, or the directory and certificate-mapping policy has propagated. An automatic retry loop with unchanged credentials can instead create noisy IKE traffic and trigger admission controls.
Before retrying
- Identify whether the connection is machine-based, user-based, certificate-based, smart-card based, or uses another configured authentication method.
- Verify that the available certificate corresponds to the expected account and has an accessible private key; a valid-looking public certificate alone is insufficient.
- Check certificate validity, trust, revocation reachability, and any deployment-specific authentication requirements.
- Confirm that the active IPsec rule authorizes the resulting user or machine identity rather than only accepting it cryptographically.
Do not treat this code as a generic network timeout. The practical evidence is the selected credential and the authorization decision on the VPN or IPsec endpoint, supported by the corresponding event records and IKE trace.
References
- Microsoft: smart-card certificate requirements and PKINIT
- Microsoft: Windows IPsec policy and authorization
- RFC 4556: PKINIT
Looking for a different code? Search another status or error code.