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.

Get-VpnServerIPsecConfiguration

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.

Summary

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

18 Comments

  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

    Reply
    • 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. 🙂

      Reply
      • 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
        Tsvetalin

      • 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.

  2. Mey

     /  September 27, 2019

    Hi Richard, Thanks for the good document. I am getting below error, Can you please help on this. “The following error occurred in the Point to Point Protocol Module on port vpn2: 1023. User Name:XXXX. Policy Match error “

    Reply
    • I would need additional information, but again, policy match errors typically mean that one side of the connection is not configured like the other. I might suggest resetting both sides of the connection to their default settings just to make sure everything works that way first.

      Reply
  3. Justin

     /  March 18, 2020

    I’ve ran across another source of IKEv2 VPN Policy Mismatch errors in the NPS server setup. If the NPS policy’s Network Policy -> Settings -> Routing and Remote Access -> Encryption Settings is only set to allow “Strongest Encryption (MPPE 128-bit)” with all other options deselected, then the recommended AES128 Encryption for the IKEv2 security optimizations as used on this site and in your example powershell scripts do not work and result in a Policy Mismatch error on the VPN Client and on the RRAS VPN server. This is despite verifying the custom crypto settings match exactly between client and RRAS server. Further complicating things is that there is no indication of the issue in the NPS server’s Windows event log.

    If NPS is configured with only highest encryption, VPN’s using the MS default 3DES encryption can connect successfully. As this is how I was initially testing the new VPN setup with success, I was unaware that NPS setup was going to be an issue. VPN’s also connect successfully if the custom IKEv2 encryption settings (EncryptionMethod, CipherTransformConstants) are increased to use AES256. No other custom crypto options like DH group or PFS needed to change from your example script settings.

    To successfully use AES128 encryption for the VPN client/server settings, the NPS policy needs to be set to additionally allow “Strong Encryption (MPPE 56-bit)”.

    This was with a Win10 (18363) client, Server 2019 Core (17763) RRAS, and Server 2012R2 NPS.

    Reply
    • Thanks for the tip, Justin! As a general practice I never touch the default encryption settings in the NPS policy and choose instead to manage those exclusively on the RRAS server. However, this is excellent information for those who might have changed these settings from their default. Thanks for sharing! 🙂

      Reply
  4. sergiibiletskyi

     /  April 6, 2020

    Hi Richard,

    I’ve configured custom policies according to your recommendations and they work for most of my users but couple of them get “Policy match error”. What could be wrong on the client side? Powershell gives correct out for both server and client.
    Client:
    AuthenticationTransformConstants : SHA256128
    CipherTransformConstants : AES128
    DHGroup : Group14
    IntegrityCheckMethod : SHA256
    PfsGroup : PFS2048
    EncryptionMethod : AES128

    Server:
    AuthenticationTransformConstants : SHA256128
    CipherTransformConstants : AES128
    CustomPolicy : True
    DHGroup : Group14
    EncryptionMethod : AES128
    Ikev2Ports : 256
    SstpPorts : 256
    GrePorts : 128
    IdleDisconnect(s) : 300
    IntegrityCheckMethod : SHA256
    L2tpPorts : 128
    PFSgroup : PFS2048
    SADataSizeForRenegotiation(KB) : 102400
    SALifeTime(s) : 3600

    Reply
    • Not sure, really. This isn’t something I’ve encountered myself. I have heard others report that if they make changes to the default encryption settings on the NPS network policy it could cause problems. Of course if this is a device tunnel connection then you aren’t using NPS, so that can be ruled out.

      Reply
      • sergiibiletskyi

         /  April 6, 2020

        In fact I’m using RRAS and NPS hosted on the same server with user certificate authentication.. But as i said among 20-30 users just two of them experience this issue.

      • That’s very strange. Ensure that the encryption settings on the network policy rule are set at their defaults. All options should be checked, including “no encryption”. Again, not sure why, but I’ve had others report this same issue (policy mismatch) and they had success restoring those settings to their defaults.

  5. sergiibiletskyi

     /  April 13, 2020

    “No encryption” wasn’t checked in the default settings. Even with that option enabled client still gets “Policy mismatch” error.
    I will try to use NPS from another server just to be sure that the problem is not related to it.

    Reply
    • Very strange. A network trace on the client might be helpful to see what’s happening on the wire too.

      Reply
    • One more thing. On your client, check for the presence of the following registry key: HKLM\SYSTEM\CurrentControlSet\Services\RasMan\Parameters\NegotiateDH2048_AES256. If it exists, delete it entirely and restart.

      Let me know how it goes. 🙂

      Reply
      • sergiibiletskyi

         /  April 14, 2020

        So i did remove that key, restarted the laptop and the key re-appeared back, and client still gives same error. BUT if i remove the key without system restart (key is not re-created) VPN connects like a charm:)

      • Have to assume it is being enforced by group policy then?

  1. Always On VPN Device Tunnel and Custom Cryptography Native Support Now in Intune | Richard M. Hicks Consulting, Inc.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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: