Windows 10 ikev2 policy match error

Is your feature request related to a problem? Please describe.
It’s more like get help rather than feature request, please forgive me for asking my question here.

I know setting up IKEv2 connection on Windows 10 is depreciated, but I have already deployed my VPN server and don’t want extra software running on it.

I used the following commands in the PowerShell:

$VpnServerAddress = "1.2.3.4"

$UserP12Path = "$HomeDownloadsUSER.p12"

$CaCertPath = "$HomeDownloadscacert.pem"

$VpnName = "Algo VPN $VpnServerAddress IKEv2"

$p12Pass = Read-Host -AsSecureString -Prompt "User p12 password"

Import-PfxCertificate -FilePath $UserP12Path -CertStoreLocation Cert:LocalMachineMy -Password $p12Pass

Import-Certificate -FilePath $CaCertPath -CertStoreLocation Cert:LocalMachineRoot

$addVpnParams = @{
    Name = $VpnName
    ServerAddress = $VpnServerAddress
    TunnelType = "IKEv2"
    AuthenticationMethod = "MachineCertificate"
    EncryptionLevel = "Required"
}

Add-VpnConnection @addVpnParams

$setVpnParams = @{
    ConnectionName = $VpnName
    AuthenticationTransformConstants = "GCMAES256"
    CipherTransformConstants = "GCMAES256"
    EncryptionMethod = "AES256"
    IntegrityCheckMethod = "SHA384"
    DHGroup = "ECP384"
    PfsGroup = "ECP384"
    Force = $true
}

Set-VpnConnectionIPsecConfiguration @setVpnParams

But when I tried to connect to my Algo VPN, I got Policy match error instead.

Describe the solution you’d like
I was hoping someone can look up the way I set up my Windows machine and see what am I missing, I guess there are some new changes since setting up IKEv2 on Windows 10 got depreciated.

Describe alternatives you’ve considered
I guess I can always try to redeploy a new VPS with WireGuard enabled, but I’d rather see if someone has a solution to my problem, since I only use Windows like once every month or so.

Additional context
I actually have a «pristine, up-to-date, Windows 10 with a single admin-privileged user and nothing else» like dguido mentioned here, and yet, Windows still failed to connect to my Algo VPN, so that sucks.

Additional request
Can anyone can give me a walk-through on how the Algo script got executed? I like those one file script where I can change anything I want. But with Algo. I just don’t know where to start.

We have an issue with a company VPN. A security audit recently revealed that our default RRAS VPN setup was fairly insecure; we followed Steven Jordan’s suggestions in his article on the topic: https://www.stevenjordan.net/2016/09/secure-ikev2-win-10.html

After adding the DWORD value to the registry as suggested (on both the server and client systems), all is happy, EXCEPT:

… it is now impossible to get our Windows 10 phone devices (we have several Lumia 950s and 950XLs being used in the field) to connect to the company public or private VPNs. The connection always fails with:

«Policy match error»

…which is to be expected, since the cipher suites no longer match up and IKEv2 cannot properly set up the tunnels.

Frustratingly, the couple of field devices we have running StrongSwan on Android work just fine, as do other connection devices (we have two off-site routers that make/break temporary VPN connections and some IoT Azure Sphere devices).

So, what I’m asking:

Given that there seems to be no way for us to edit the registry on these devices (I tried using WICD provisioning, but that didn’t work — although it did allow me to control SPLIT_TUNNELING which was very helpful), how might one go about making
the Windows 10 Phones perform the same way that our Windows desktop machines do — i.e., connecting to the VPN as per usual? We need to continue to use these phones until the end of their support lifetime — can’t afford to replace them all plus there’s Continuum
which no other phones seem to be able to match.

Thanks in advance

(Repost from Windows 10 IT Pro topic)

«I’m anispeptic, frasmotic, even compunctual to have caused you such pericombobulation.»

For anybody who is reading this, this solution leads to other problems like VPN frequently disconnecting after certain amount of fixed data transfer.

If you already did the above workaround-

You need to delete the adapter you just created and follow the nord VPN guide again to set up the new adapter. You need to just do ‘Set up a VPN Connection’ part again.

Now after doing it- you will get a policy match error like before.

The correct way to fix this policy match error is as follows explained by ProtonVPN but also applies to nordVPN.

From their guide-

If you are not able to connect and get “Policy match error” follow these steps:

Open “Run” window while pressing Windows button+R on your keyboard at the same time. Type in regedit.

Then, navigate to this directory – HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesRasManParameters

Now right click on right side empty space and create a new DWORD (32bit) file named NegotiateDH2048_AES256

Right click on new created registry file and click on “Modify…“, then in the value data field enter the value of 2 and click OK.

After doing this, close regedit and try connecting to the VPN server again.

It should work now without any problems. Cheers!

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

Set-IKEv2SecurityBaseline PowerShell script on Github

I have thought of deleting this question because I have found the answer myself, and the problem was not due to a bug in Windows. However, I have learnt that I am not the only one who had this problem, so I leave the question and the answer here for reference. Having said this:

The Windows IPSec stack does still not offer strong authentication, cipher, encryption, integrity and exchange algorithms by default; instead, you have to explicitly enable strong VPN IPSec cryptography. This is true even for the newest versions of Windows 10 (at the time of writing this), and it is a shame that Windows does not offer appropriate options in the GUI where VPN IPSec connections are normally created.

When researching how to enable strong cryptography in Windows, you will inevitably come across at least the following solutions:

1. Create and fine-tune VPN IPSec connections via Powerhell, using commands like those shown in my question.

2. If it does not exist yet, create the following DWORD in the registry:
   HKEY_LOCAL_MACHINESystemCurrentControlSetServicesRasmanParametersNegotiateDH2048_AES256
   Then set it to one of the following values:
   0: Disable AES-256-CBC and MODP-2048
   1: Enable AES-256-CBC and MODP-2048
   2: Enforce AES-256-CBC and MODP-2048

So we have a quick way to enable that strong encryption everybody is after by just editing one registry value, which most of us are used to anyway, right? And of course, we want to be sure that the strong encryption is actually used, so we set that value to 2 to prevent weak proposals from being chosen, or to prevent ourselves from connecting to sites which only offer weak cryptographic algorithms.

A few days later, we realize that this is not enough, because we now want to connect to a site which uses another DH group, for example. So we bite the bullet and learn how to configure VPN IPSec connections via Powershell.

Next, we wonder why Windows does not respect the cryptographic algorithms we have given for a certain VPN IPSec connection via Powershell, and why it sends wrong proposals, and we write questions at this site.

The reason for Windows disrespecting our Powershell VPN IPSec configuration is trivial:

The description for the value 2 in the above registry DWORD must be understood literally. Enforce means, well, enforce, which in turn means that the cryptographic parameters for any IPSec VPN connection will be overridden and that MODP-2048 and AES256-CBC will be used instead.

It does not mean that Windows insists on AES256-CBC and MODP-2048 just if something weaker is configured or offered. It really means that this setting under any circumstances will override other settings given by other configuration mechanisms.

Since I have deleted that registry value, Windows uses and offers the correct cryptographic configuration (i.e. the one given via Powershell) when establishing a VPN IPSec connection. It did not need to be restarted for this change in behavior.

Please note that I did not try what would happen if I set that registry value to 1; I just deleted it because it is not of any benefit as long as you create your VPN IPSec connections via Powershell, which I will always do in the future.

Likewise, I did not research whether it is possible to enable strong cryptography with VPN IPSec connections by group policies or other mechanisms not mentioned above — please leave a comment if you can tell anything about that.