Always On VPN IKEv2 Security Configuration

Always On VPN IKEv2 Security ConfigurationWhen deploying Windows 10 Always On VPN, many administrators choose the Internet Key Exchange version 2 (IKEv2) protocol to provide the highest level of security and protection for remote connections. However, many do not realize the default security parameters for IKEv2 negotiated between a Windows Server running the Routing and Remote Access Service (RRAS) and a Windows 10 VPN client are far less than ideal from a security perspective. Additional configuration on both the server and the client will be required to ensure adequate security and protection for IKEv2 VPN connections.

Windows 10 and RRAS IKEv2 Defaults

In their default configuration, a Windows 10 client connecting to a Windows Server running RRAS will negotiate an IKEv2 VPN connection using the following IPsec security parameters.

  • Encryption: 3DES
  • Authentication/Integrity: SHA-1
  • Key Size: DH Group 2 (1024 bit)

This information can be obtained by opening an elevated PowerShell command window and running the following command.

Get-NetIPsecMainModeSA | Select-Object -First 1

Always On VPN IKEv2 Security Configuration

This can also be confirmed by viewing a network trace as shown here.

Always On VPN IKEv2 Security Configuration

These IPsec security parameters might have been acceptable in the 90’s, but they certainly are not today. 🙂

Improving IKEv2 Security

To provide a baseline level of protection to meet today’s requirements for security and privacy for IKEv2 VPN connections, the following are the minimum recommended IPsec security parameters.

  • Encryption: AES128
  • Authentication/Integrity: SHA-256
  • Key Size: DH Group 14 (2048 bit)

RRAS Custom IPsec Policy

To implement these recommended security baselines for IKEv2 on a Windows Server running RRAS it will be necessary to define a custom IPsec security policy. To do this, open an elevated PowerShell command window and run the following commands on each RRAS server.

Set-VpnServerConfiguration -CustomPolicy -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES128 -DHGroup Group14 -EncryptionMethod AES128 -IntegrityCheckMethod SHA256 -PFSgroup PFS2048 -SADataSizeForRenegotiationKilobytes 102400

Restart the Remote Access Management service for the changes to take effect.

Restart-Service RemoteAccess -PassThru

Always On VPN IKEv2 Security Configuration

Note: A PowerShell script to implement the custom IPsec security policy settings shown above can be downloaded here.

Windows 10 Client Settings

The IPsec policy must match on both the server and the client for an IKEv2 VPN connection to be successful. Unfortunately, none of the IKEv2 IPsec security association parameters proposed by default on Windows 10 clients use 2048-bit keys (DH Group 14), so it will be necessary to define a custom IPsec security policy on the client to match the settings configured on the server.

To configure a matching IPsec security policy on an individual Windows 10 VPN client, open an elevated PowerShell command window and run the following command.

$connection = “[connection name]”
Set-VpnConnectionIPsecConfiguration -ConnectionName $connection -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES128 -DHGroup Group14 -EncryptionMethod AES128 -IntegrityCheckMethod SHA256 -PFSgroup PFS2048 -Force

Always On VPN IKEv2 Security Configuration

Restore Defaults

In the process of testing it may be necessary to restore the default IKEv2 configuration on both the client and the server. This can be accomplished by running the following PowerShell commands.

Server – Set-VpnServerConfiguration -RevertToDefault

Client – Set-VpnConnectionIPsecConfiguration -ConnectionName [connection_name] -RevertToDefault -Force

Always On VPN XML Settings

To implement a custom IPsec policy using the minimum recommended security settings for an Always On VPN connection using IKEv2, add the following settings to your ProfileXML.


Why Not AES 256?

In the examples above you’ll notice that I’ve chosen to use AES128 and not AES256. This is by design, as AES256 does not provide any practical additional security in most use cases. Details here.

Enhanced Security and Performance

To further improve security and performance for IKEv2, consider implementing Elliptic Curve Cryptography (EC) certificates and using Galois Counter Mode (GCM) cipher suites such as GCMAES128 for authentication and encryption.

Additional Information

Always On VPN Certificate Requirements for IKEv2

Always On VPN IKEv2 Connection Failure Error Code 800

Always On VPN IKEv2 Load Balancing with the KEMP LoadMaster Load Balancer


Leave a comment


  1. Tim

     /  December 10, 2018

    Thanks Richard, I cannot wait to test these settings. I’ll report back and let you know once I have had the chance!

  2. Tauno Vürmer

     /  December 10, 2018

    How can i verify on client that it is using 3DES? Is there powershell command to see it?

    • No command that I’m aware of to see it. You’ll have to take a network trace of the IKEv2 connection to see it. You’ll find that the Windows 10 clients submits 18 different IKE proposals, none of which use anything larger than DH Group 2 (1024-bit) keys. :/ In my testing I observed that when a Windows 10 client connects to a Windows Server running RRAS they always negotiate 3DES/SHA-1/DH2, by default. 😦

      • Marko

         /  December 11, 2018

        “Get-NetIPsecMainModeSA” on Windows 10 client should show that info.

        CipherAlgorithm: DES3
        HashAlgorithm: SHA1
        GroupId: DH2
        KeyModule: IkeV2

      • Thanks! This won’t let you see the default configuration exactly, but it will allow you to see the negotiated settings after the connection is made which is helpful. I’ll be updating the post to include this information. 🙂

    • Tim

       /  December 11, 2018

      Once connected, open a Powershell window as Administrator and run “Get-NetIPSecMainModeCryptoSet -PolicyStore ActiveStore” this appears to display what is currently being used by the IPSec VPN connection?

      • Oh yes, you can see what IKEv2 security parameters were negotiated using PowerShell after the connection has been made. I’ll update the post to reflect that additional detail. Thanks! 🙂

  3. Colin

     /  December 10, 2018

    Worth noting, in my testing anyway, that the VPN profile CryptographySuite blob needs to be directly under . I tried it above and it failed.

  4. Colin

     /  December 10, 2018

    Looks like my post had code wordpress didn’t like. It needs to be directly under NativeProfile. I tried it under Authentication and it failed.

    • Correct. As long as the CryptographySuite element is nested between the NativeProfile elements you’re good. 🙂

      • Tim

         /  February 25, 2019

        I don’t think it works for Powershell deployed profiles? I have added the CryptographySuite settings into the VPN_Profile.ps1 script on a test machine and I still get Policy Match Error when trying the connection after it installs – is the CryptographySuite settings only for an InTune MDM roll-out via XML?

      • It works for both PowerShell and Intune deployed connections. The important thing to remember is that the settings must also be configured on the server, and they must be identical to the settings on the client or else you will get the policy match error.

  5. Colin

     /  December 10, 2018

    Richard, to use AES256, would it be to simpley replace the two client side AES128 enrties and the two server side AES128 entries with AES256?

  6. Colin

     /  December 10, 2018

    Interesting. I am testing this right now and I have both a user tunnel and a device tunnel connected to the server successfully and I see in the event log that it is in fact using the new cryptography settings but the tunnel isn’t working any longer. I can’t communicate with anything on the internal network now.

    The only change to each profile was the addition of the cryptography blog under nativeprofile. The powershell command were executed on client and server respectively. What could it be?

  7. Colin

     /  December 10, 2018

    I rebooted the server and it passes traffic now. *shrug*

    • timbo01

       /  December 11, 2018

      I have noticed that simply restarting the RAS Service doesn’t apply the new settings when playing with changing encryption settings before now – and I have had to reboot the server to get the changes to take affect. I think the message Microsoft states to restart the RAS Service is misleading as it doesn’t seem to work 😦 and a full reboot is required.

      • That’s not been my experience and I’ve done extensive testing with this. If it doesn’t though, restarting always works. 🙂

  8. Chris

     /  December 11, 2018

    Hi Richard

    Thanks for the post

    When we set this on the RASS servers, as clients not matching the new IKEv2 security won’t be able to connect, am I right to assume if we hit any issues, we can run “Set-VpnServerIPsecConfiguration -RevertToDefault” on the RASS server to revert back? After a service re-start

    Also, our internal CA is on running an OS of Server 2008 R2 are we OK implementing the updated IKEv2 security when running an older internal CA

    Thanks for all you posts on Always ON VPN they have been a great help 😊

    • Chris

       /  December 11, 2018

      Sorry Richard just to clarify to revert back on the RASS Server “Set-VpnServerConfiguration -RevertToDefault” and on the end client “Set-VpnServerIPsecConfiguration -RevertToDefault” Thanks again

    • Yes, you can use -RevertToDefault to restore the default settings. Thanks for bringing that up. I’ll be sure to update the post with that information. You shouldn’t have a problem with your old CA as long as it is using at least SHA-1 and 2048 bit RSA keys.

      • Chris

         /  January 4, 2019

        Hi Richard that’s great thanks for the reply 🙂

  9. Colin

     /  December 11, 2018

    I am experiencing some odd issues. If I manually run my scripts for the profiles with the powershell to set the policy at the end of the script, the VPN behaves normally.

    If I deploy the exact same script through SCCM (which worked perfectly fine prior to the IKEv2 policy changes) it has all types of odd stuff going on like connected but no traffic flows… or the device tunnel will say connected but traffic wont flow and the user tunnel will say policy mismatch.

    I’m trying to narrow down the cause but it is so odd. If I manually run the IKEv2 policy commands on the system that received the profiles from SCCM it seems to work again.

    I’ll keep plugging away at it.

    Richard, is there anyway to view the IKEv2 policy settings that were applied to the profile with powershell to confirm they were applied properly?

    • Unusual indeed. The ProfileXML can be trick sometimes though. :/ As for viewing the IKEv2 policy settings, the only thing I can suggest is viewing the ProfileXML field in the output of this command:

      Get-WmiObject -Namespace root\cimv2\mdm\dmmap -Class MDM_VPNv2_01

      That will at least let you see if your ProfileXML has been applied as intended.

  10. Colin

     /  December 11, 2018

    This may have been resolved by adding a Start-Sleep 15 seconds in the profile script prior to executing the IKEv2 policy command

  11. Colin

     /  January 10, 2019

    Richard, what are possible solutions to computers with device tunnels that are in the possession of a terminated employee?

    I assume because the user tunnel uses NPS it can just be removed from a group and lose access. But what about the device?

    Let’s say a device tunnel exists on a computer that a current employee has possession of and they work 100% remotely. That employee is terminated and their user is removed from the group for AOVPN but they still have possession of the device.

    Wont that device connect to the company network and have access to whatever that device profile allowed indefinitely? Am I missing something?

    • Colin

       /  January 10, 2019

      I suppose this would come down to a publicly accessible CRL and a process to manually revoke the computers certificate?

      • Correct. If you want to prevent a machine from establishing a device tunnel connection you will need to revoke the machine’s certificate and publish a new CRL. The real challenge here is that this doesn’t happen immediately because CRLs are cached and have a defined lifetime. :/

      • Colin

         /  January 10, 2019

        Can the CRL lifetime be changed on certs that are already issued? This sounds like a pretty crappy scenario for companies.

      • The lifetime of the CRL is set on the CRL itself, not on the certificate. You could easily reduce the validity time on your CRLs, but you’d have to wait for your existing CRL to expire before that change takes effect.

      • Colin

         /  January 11, 2019

        I suppose if you are deploying the device profile via SCCM and the device establishes a tunnel, you could force a deployment to the terminated employees device to basically disconnect and remove the device profile.

        This would leave the computer in a disconnected state. The user would have to have admin rights and the know-how to create a new tunnel for the device, assuming the certificate was still valid. Maybe a combination of certificate revocation/Public CRL, SCCM deployment to remove profile would be best bet.

        What happens if the certificate is valid and the device profile still exists but the computer object is disabled in AD? What is the behavior at that point?

        If you are using Intune I guess you could send the machine a wipe command or whatever the options are.

      • Agreed, you can always use other tools/techniques to mitigate this challenge. Also, as you point out, it might actually be a benefit that the device tunnel stays active so you can remotely remove the VPN profile. That said, I do believe that managing these devices with Intune and issuing a remote wipe is probably the most ideal solution.

        Regarding the computer account in Active Directory, it has no impact on the Always On VPN device tunnel. Unlike DirectAccess, which does validate the computer account as part of the machine tunnel, Always On VPN device tunnel authentication validates only the computer certificate. Disabling the computer’s account in Active Directory would have no effect on the connection at all.

      • Pieter

         /  March 25, 2019

        You can place a copy of the computer certificate in the untrusted certificates store of RRAS. This will prevent access immediately. This might be necessary for instance if the computer is infected with ransomware.

      • Most interesting. I’ll have to test this out soon. 🙂

      • Colin

         /  March 25, 2019

        This is likely the best option to immediately shut down a computers access to the network.

        Would finding the computers certificate in the CA and revoking it have the same impact or would there be a delay?

        It sounds like placing a copy in the untrusted store would have no delay.

      • Revoking certificates will most certainly be delayed, the length of which would depend on how the CRLs are configured in your organization.

  12. Erin Mc

     /  May 6, 2019

    I’ve configured the variables above and they work … until I turn off the Triple DES cipher on the server itself (I use IIS Crypto usually rather than editing the registry). When I turn the TripleDES cipher off on the server, the VPN will connect, but I can’t get to any of the internal web pages. Has anyone seen this behavior too and know how to fix it?

    • That’s unusual. Disabling 3DES for SSL/TLS should have no effect on IKEv2, especially if you’ve configured VPN to use AES.

  13. I’ve noticed a strange behavior with the ciphers. I implement the above suggestions (thank you!) leaving off ” -SADataSizeForRenegotiationKilobytes 102400″ because I would get a policy mismatch error, and it would work. But as soon as I turn off TripleDES on the server itself (using IIS Crypto), the VPN will connect, but no internal webpages will come up. Has anyone experienced the same and know how to fix it?

  14. Nils

     /  July 25, 2019

    Strange. For use the default encryption is working fine, but after raising the server and client encryption with the exact commands you used it always fails with the policy mismatch error. Even after a reboot it is not working. After the reverttodefault command on the server and on the client and rebooting the server it works again.

    Strange thing is that if I on purpose have mismatched encryption settings on server and client it fails directly, but if I use your commands or any matching than I get MFA access is granted but always still the policy mismatch error.

    Have you seen this behavior or have any idea in which direction to search for? The logs and errors are not really helping in this case.

    • If you’ve configured both sides identically that would be unusual to get policy mismatch error. I’d suggest taking a network trace on the client to see what’s up. That should give you an idea why the connection is failing.

    • victor bassey

       /  September 27, 2019

      this is exactly my experience. both server and client has been configured with the scripts from this page

  15. Colin

     /  August 7, 2019


    I just noticed that my user tunnel which previously worked with IKEv2 is now generating an error with policy mismatch event ID 20227 with a message about dialing the connection and failing “The error code returned on failure is 13868.”

    Any idea what this could be? I am on 1903 and have not checked 1809 yet. I did notice that all users are connected over sstp so I’m not sure if this is a 1903 thing or something.

    I had not previously tested IKEv2 for the user tunnel on 1903 but I did on 1809 before I upgraded and it worked fine.

    • 13868 is definitely an IKEv2 policy mismatch error. Either the policy changed on the client or the server. 🙂 I’d have a close look at both of those and see what’s up.

      • Colin

         /  August 13, 2019

        If that is the case, why do device tunnels work fine? Interesting. I will dig deeper.

      • Have to assume the device tunnel and VPN server policies match then. BTW, there’s a known issue with Always On VPN and custom cryptography policies. Perhaps you’re running in to this issue? This bug yields a different error code, but worth checking.

      • Colin

         /  August 13, 2019

        The funny thing is it used to work and the server and profiles have not been modified.

      • Very strange! Let me know what you find out. 🙂

      • Colin

         /  August 14, 2019

        The policy was not applied. It was working and applied before… tested on a bunch of computers.. verified over and over. All of the sudden it is like the policy was removed and the client didn’t match the server any longer.

        I took the same powershell command from the profile script that installs the profile and sets the policy and manually entered it on a computer.. tested IKEv2 and it worked fine.

        I don’t know why it would have been removed/wiped out… but it seems to have been.

        Now I will likely have to execute the powershell command on tons of computers to make sure they all have it again.

        I may just have SCCM do this as a baseline config thing for anyone in the collection that receives the profile.

      • Colin

         /  August 14, 2019

        Do you know of a way to query the current policy on a client with powershell? I want to see if the existing policy is correct and execute remediation if it is not.

      • Sadly, Microsoft does not provide a native way to view the custom cryptography settings for VPN connections. So, although you can set the configuration using Set-VpnConnectionIPsecConfiguration, there is no Get-VpnConnectionIPsecConfiguration command. :/

      • Upon further review…this information is actually easy to find using PowerShell. 🙂

        Get-VpnConnection -Name ‘Foo’ | Select-Object -ExpandProperty IPsecCustomPolicy


      • Colin

         /  August 16, 2019

        Perfect! Thanks!

      • Colin

         /  August 16, 2019

        All set now. SCCM now has a baseline deployed to all computers with AOVPN that checks for profiles matching our naming convention and the state of IPsecCustomPolicy.

        If it is found to not exist or not match, it runs the set- command to fix and it and then report that it is compliant.

        This should continue to fix it if it decides to get wiped out again.

  16. Daniel K.

     /  September 3, 2019

    Any Idea, how to deploy such settings in an active Always-On-VPN deployment without Intune? My problem is, that when I will first set the policy on the clients, they wont be able to connect anymore. If I will set the policy first on the server, the same will happen and I’m not able to reach all VPN-clients at the same time.
    Is there a way, not to force the policy, to do a soft deployment?

    • If you’re not using Intune you’re in a tough spot, for sure. You’re right, once you change the settings on the server it will immediately disconnect all users. No problem with Intune, as the client settings will be updated out-of-band and they’ll reconnect once they receive those new settings. If you’re deploying the settings manually you’ll have to touch each one of those clients again, unfortunately.

      • Colin

         /  September 10, 2019

        Microsoft seems to really be steering everyone towards Intune and 3rd party vpn gateways as opposed to RRAS and Powershell scripts.

        Maybe I’m wrong about RRAS.. but it feels like they don’t care about RRAS much anymore.

        Speaking of 3rd party gateways, Richard do you still plan on doing an article/tutorial on using AOVPN with a Fortinet gateway?

      • Indeed. RRAS is legacy, and PowerShell scripts simply don’t scale and present other issues too. The post on deploying Always On VPN using the Fortinet Fortigate appliance is still on my list of things to do. Can’t say exactly when I’ll get to it though. Hopefully by the end of the year. 🙂

  17. victor bassey

     /  September 27, 2019

    What am i doing wrong, I still get the Policy Match Error despite matching the cipher suites on both client and server:


    AuthenticationTransformConstants : SHA256128
    CipherTransformConstants : AES128
    DHGroup : Group14
    IntegrityCheckMethod : SHA256
    PfsGroup : PFS2048
    EncryptionMethod : AES128


    AuthenticationTransformConstants : SHA256128
    CipherTransformConstants : AES128
    CustomPolicy : True
    DHGroup : Group14
    EncryptionMethod : AES128
    Ikev2Ports : 1024
    SstpPorts : 0
    GrePorts : 0
    IdleDisconnect(s): 300
    IntegrityCheckMethod: SHA256
    L2tpPorts : 0
    PFSgroup : PFS2048
    SADataSizeForRenegotiation(KB) : 102400
    SALifeTime(s) : 28880

    • I don’t see anything specifically wrong here. If you’re still trying to sort this out, drop me a note directly and I’ll have you send me some additional information.

      • Victor

         /  October 11, 2019

        Thanks Richard for the response. i did engage MS premier support and the issue was related to the encryption settings on the VPN connection profile on the NPS servers. I had only checked the option to use “Strongest Encryption” and it was failing. when i also checked the option for “Basic Encryption” and “Strong Encryption” this now works.

      • Ok, good to know!

  1. Always On VPN IKEv2 Connection Failure Error Code 800 | Richard M. Hicks Consulting, Inc.
  2. Always On VPN IKEv2 and SSTP Fallback | Richard M. Hicks Consulting, Inc.
  3. Always On VPN ProfileXML Editing and Formatting with Visual Studio Code | Richard M. Hicks Consulting, Inc.
  4. Always On VPN and IKEv2 Fragmentation | Richard M. Hicks Consulting, Inc.
  5. Troubleshooting Always On VPN Error Code 809 | Richard M. Hicks Consulting, Inc.
  6. Always On VPN IKEv2 Load Balancing with F5 BIG-IP | Richard M. Hicks Consulting, Inc.
  7. Always On VPN Device Tunnel Configuration using Intune | Richard M. Hicks Consulting, Inc.
  8. Always On VPN LockDown Mode | Richard M. Hicks Consulting, Inc.
  9. Always On VPN IKEv2 Features and Limitations | Richard M. Hicks Consulting, Inc.
  10. Deploying Always On VPN with Intune using Custom ProfileXML | Richard M. Hicks Consulting, Inc.
  11. Always On VPN IKEv2 Policy Mismatch Error | Richard M. Hicks Consulting, Inc.

Leave a Reply to Colin Cancel 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: