Always On VPN IKEv2 Policy Mismatch Error

Always On VPN IKEv2 Policy Mismatch ErrorThe Internet Key Exchange version 2 (IKEv2) VPN protocol is the protocol of choice for Windows 10 Always On VPN deployments where the highest levels of security and assurance are required. However, as I’ve written about in the past, often the default IKEv2 security settings are less than desirable. Before using IKEv2 VPN in a production environment the administrator will need to update these security settings accordingly.

Connection Failure

When configuring Windows Server Routing and Remote Access Service (RRAS) or a third-party VPN appliance to support IKEv2 using custom security policies, the administrator may encounter a scenario in which a connection cannot be established due to a policy mismatch error. When the connection attempt fails, an error will be recorded in the Windows Application event log from the RasClient source with Event ID 20227. The error message states the following:

“The user [username] dialed a connection named [connection name] which has failed. The error code returned on failure is 13868.”

Always On VPN IKEv2 Policy Mismatch Error

Error Code 13868

Error code 13868 translates to ERROR_IPSEC_IKE_POLICY_MATCH. Essentially this error indicates that the IKEv2 security policy on the client did not match the configuration on the server.

Server Configuration

To view the current IKEv2 IPsec policy configuration, open an elevated PowerShell command window and run the following command.


Always On VPN IKEv2 Policy Mismatch Error

Client Configuration

To ensure interoperability, the VPN client must be configured to use the same IKEv2 security policy as defined on the sever. To view a VPN client’s currently configured IKEv2 security policy, open an elevated PowerShell command window and run the following command.

Get-VpnConnection -Name [connection name] | Select-Object -ExpandProperty IPsecCustomPolicy

Always On VPN IKEv2 Policy Mismatch Error

Note: If this PowerShell command returns no output, the VPN connection is not using a custom IKEv2 IPsec security policy.

Updating Settings

Guidance for configuring IKEv2 security policies on Windows Server RRAS and Windows 10 can be found here.


IKEv2 policy mismatch errors can be resolved easily by ensuring both the VPN server and client are configured to use the same IPsec security policies. Use the PowerShell commands in the above referenced above to validate settings and make changes when necessary.

Additional Information

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN IKEv2 Features and Limitations

Show-VpnConnectionIPsecConfiguration PowerShell script on Github

Set-IKEv2SecurityBaseline PowerShell script on Github

Leave a comment


  1. Ceco Ceco

     /  September 6, 2019

    Hello Richard

    First of all – thanks for all you very informative articles on the DirectAcess and AlwaysOn VPN

    We’ve been having the policy mismatch error you describe in the this article, and indeed upon checking the client side IKEv2 policy was not there at all (no output at all)
    I’ve set it up via PowerShell as you prescribe , rebooted both client and server, but still getting exactly the same error …
    We’re using Server 2016 RAS and NPS on server 2019 (with the sc sidtype IAS unrestricted fix ran – thanks for that one as well:) ) and Windows 10 , 1903 as a client.

    I am really running out of ideas why is AOVPN not connecting – I had a test domain built (with single tier CA, where in the production we’ve got two tier CA with the root CA offline) and there everything worked perfectly fine .
    So was wondering whether the Root CA being offline could have something to do with this error?

    Hope all of the above makes sense!

    Thank you in advance for your time and consideration !

    Kind Regards
    Tsvetalin Chikov

    • You should not get IKE policy mismatch errors with an offline Root CA. The only thing that results in this error is a policy mismatch. You’ll have to look very closely at your client and server policies to see where you made the mistake. 🙂

      • Ceco Ceco

         /  September 13, 2019

        Thanks Richard

        The reason I was suspicious about the offline root CA is the error I was getting when switched from IKEv2 to SSTP :

        “The initial Secure Socket Tunneling Protocol request could not be successfully sent to the server. This can be due to network connectivity issues or certificate (trust) issues. The detailed error message is provided below. Correct the problem and try again.

        The revocation function was unable to check revocation because the revocation server was offline.”

        The certificates seem fine, so probably will go will setting up a second CA in our domain, and try issuing all needed certificates from there …

        Thanks again for your time and consideration!

        Kind Regards

      • For SSTP, if you are using an internally issued certificate for SSTP you must ensure the certificate revocation list (CRL) is available externally. Best practice here is to use a public certificate to avoid these types of issues.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: