The 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.”
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
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
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.
NPS Policy
Another common cause of IKEv2 policy mismatch errors is a misconfigured Network Policy Server (NPS) network policy. Specifically, administrators may disable Basic and Strong encryption for MPPE in an attempt to improve security.
The NPS policy for Always On VPN must include Strong encryption at a minimum. Basic and No encryption can be safely disabled.
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
Ceco Ceco
/ September 6, 2019Hello 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
Richard M. Hicks
/ September 10, 2019You 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, 2019Thanks 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
Richard M. Hicks
/ September 16, 2019For 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.
Mey
/ September 27, 2019Hi 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 “
Richard M. Hicks
/ October 7, 2019I 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.
Justin
/ March 18, 2020I’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.
Richard M. Hicks
/ March 18, 2020Thanks 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! 🙂
sergiibiletskyi
/ April 6, 2020Hi 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
Richard M. Hicks
/ April 6, 2020Not 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.
sergiibiletskyi
/ April 6, 2020In 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.
Richard M. Hicks
/ April 6, 2020That’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.
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.
Richard M. Hicks
/ April 13, 2020Very strange. A network trace on the client might be helpful to see what’s happening on the wire too.
Richard M. Hicks
/ April 13, 2020One 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. 🙂
sergiibiletskyi
/ April 14, 2020So 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:)
Richard M. Hicks
/ April 14, 2020Have to assume it is being enforced by group policy then?
emanthi
/ February 4, 2021Hello.I had this policy mismatch error a few time ago, and after i made this command requested by support of vpn also, my vpn got some data blockage and got out of network after some data usage – like 300mb only :/ is there any solution to this and why this happens?
Richard M. Hicks
/ February 5, 2021Not sure why you’re having throughput issues after changing these settings. I’d have a close look at all of your networking to insure everything is in working order. Often I find that network devices are misconfigured (for example MTU configured too small) or perhaps there are some interface errors that need to be addressed.
John B
/ February 14, 2024Hi Richard
I am trying to replace my 2016 server and using my original custom ipsec policy. I am getting the error “Failed to plumb the custom IKEv2 policy.”
I’ve tried your script as well as setting it manually myself
Is there a limitation on ciphers on newer editions of windows server?
Set-VpnServerConfiguration -CustomPolicy -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES128 -DHGroup Group14 -EncryptionMethod AES128 -IntegrityCheckMethod SHA256 -PFSgroup PFS2048 -SALifeTimeSeconds 28800 -MMSALifeTimeSeconds 86400 -SADataSizeForRenegotiationKilobytes 1024000
Richard M. Hicks
/ February 14, 2024Not to my knowledge. I use my script all the time on Windows Server 2019 and 2022 without issue. I just copied/pasted your command and ran it successfully on my Windows Server 2022 test machine, too. Worked fine. 🤷♂️