WIN 10 Secure IKEv2 VPN

How To:

Secure Windows 10 IKEv2 VPNs.  Improve IKEv2 security strength  -the easy way.  Enable hidden support for advanced cryptographic algorithms on Windows clients.


The default Windows implementation of IPsec is highly vulnerable to Man-in-the-Middle (MITM) attacks.  It uses depreciated security algorithms and should not be trusted.  DO NOT use IKEv2 or L2TP/IPsec with Windows clients unless it negotiates secure cryptographic algorithms.


A simple registry change enables secure IPsec.  This easy fix provides a respectable DH14-AES256-SHA256 negotiation.  Alternately, use PowerShell to enable even stronger security.  Both solutions provide a cryptographic baseline that ensures secure communications.


The VPN server confirms vulnerable  security:  3DES, SHA1, and DH2 -all bad.  Confirm active MM cryptographic algorithms with PowerShell:

PS C:\Users\stevenuwm> Get-NetIPsecMainMode
 Name                                : 51
 LocalEndpoint                       : x.x.x.x
 RemoteEndpoint                      : x.x.x.x
 LocalFirstId.AuthenticationMethod   : Certificate
 CipherAlgorithm                     : AES256
 HashAlgorithm                       : SHA1
 KeyModule                           : IkeV2
 CipherAlgorithm                     : DES3
 HashAlgorithm                       : SHA1
 GroupId                             : DH2
 KeyModule                           : IkeV1

3DES?  SHA1?  DH2?  Good thing we checked!

Security Guidelines:

The Internet Engineering Task Force (IETF) provides guidelines for securing IKEv2. (RFC4307 BIS-13).  These standards are based on key management security strength.  Do not use any cryptographic algorithm with less than 103-bits of security:

Key Management Tips:

  • DH Group-2 SHOULD NOT be used.
  • Use DH Group-14.    
  • Use RSA-3096 certificates.
  • Use AES128 encryption.
  • SHA1 (Main-Mode) can be used.  SHA256 is a better alternative.
  • Use HMAC-SHA1.  It is not the same thing as SHA1
Theses tips serve as baseline security -a starting point.

Registry Solution:  

Create a registry key that enforces modern cipher and transform sets.

STEP 1:  Edit Registry or create GPO:

STEP 2: Create new DWORD value:
STEP 3:  Modify DWORD value:

Table 2:  NegotiateDH2048_AES256 Values.
Value IKEv2 Security L2TP\IPsec (i.e., IKEv1)
1 MM: IKE-DH14-AES256- SHA1
MM: DH14-SHA1-AES128
2 M: IKE-DH14-AES256- SHA256
MM: DH14-SHA1-AES128
   Note:  This security target assumes the VPN server supports DH14-AES256-SHA256.
   No value, or value of 0 uses client defaults -weak encryption and hash! 
   VPN client security MUST be set to maximum strength encryption in it property settings. 


   Registry sub-key:
   Registry entry:
  NegotiateDH2048_AES256 Data Type:  Reg_DWORD
Value:  2

Windows VPN Server:

IPsec requires common cryptographic algorithms.  Windows 2012 IPsec is every bit as insecure as Windows 10.  Therefore we'll need to make adjustments to the server as well.

The above registry fix is recommended for Windows clients.  However it can work with Windows 2012 RRAS VPN server -with one catch.  It does improve security strength for DH and encryption, It does not improve the security strength for the hashing:


This registry change meets the bare-minimum IETF recommendations for IKEv2.  It's better than before -but we can do better.

Should we trust SHA1?  It's probably OK for now.  On the other hand, Google Chrome and Microsoft IE no longer support certificates that use SHA1.  Weak hashes (e.g., SHA1) are vulnerable to sophisticated off-line attacks  In other words, an attacker can steal your identity! (Entrust 2014).

We're not talking about credit scores.  We're talking about digital identity and authentication.  Fake RSA signatures that authenticate to the VPN, email, etc.  Yikes!

Why risk SHA1 when we can easily implement SHA256?  There are other simple (yet hard to find) methods that improve IKEv2 security strength  on Windows servers.  We can do better:


The Windows 10 registry fix is the path of least resistance.   However, PowerShell supports a wider range of cryptography algorithms.  N.B., These IPsec configurations are not available from the Windows GUI or registry.

Step 1:  Configure new IKEv2 VPN.

Create the new VPN connection with PowerShell.  Do not create the VPN connection with the GUI.
However, it's OK to use the GUI to edit authentication attributes after PowerShell creates the connection .

Add-VpnConnection -Name "IKEv2-VPN" -ServerAddress "" -TunnelType IKEv2 -AuthenticationMethod MachineCertificate

Step 2:  Configure an acceptable level of cryptography.

Set-VpnConnectionIPsecConfiguration -ConnectionName "IKE-SMJ" -AuthenticationTransformConstants None -CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup Group14 -PfsGroup None -PassThru -AllUserConnection

AuthenticationTransformConstants : None

CipherTransformConstants         : AES256

DHGroup                          : Group14

IntegrityCheckMethod             : SHA256

PfsGroup                         : None

EncryptionMethod                 : AES256

PfsGroup                         : None

Additional Thoughts:

Why does Microsoft cripple IPsec VPN security by default?  Is it support for legacy devices?  Are there more nefarious reasons (e.g., Eric Snowden)?  Does it nudge folks away from IPsec toward SSTP?  If so it's as good of a reason as any!  In fact, I recommend SSTP for most situations.  The only problem with SSTP is that it's limited to Windows and Android clients.  Direct Access is another great VPN solution (that incorporates Windows IPsec).  


In the end, NegotiateDH20148_AES256, is a Band-Aid for its default (i.e., broken) Windows IKEv2 VPN.   It provides bare-minimum IPsec security strength that should already be enabled by default. The registry fix may not be the best option but it's quick and it's easy.

On the other hand, Windows 10 supports stronger IKEv2 security strength via PowerShell commands.  By default, Windows IPsec VPN is not secure -it should not be trusted.  However, these VPNs can provide excellent security with a few simple changes.

That's it!

Microsoft Windows 8 Windows Server 2-12 Supplemental Admin Guidance IPsec VPN Clien.docx.


  1. When I add reg key IKEv2CustomPolicy with DH14-AES256-SHA256 settings, I cannot connect to server with less security settings (for example from Win Phone).
    Is it possible to configure server to support more then one type of cipher sttings?

    1. You should check out my article about site-to-site (S2S) VPNs. This should solve your problem:

  2. You recommend set PfsGroup = none ???

    1. Good point. To be clear, this article offers a solution based on IETF guidelines. It provides a starting point that provides at least 103-bits of security. I consider this approach as the bare minimum practice.
      That said, perfect forward secrecy (PFS) offers additional security for IKEv2. It ensures that new session keys are not derived from previous session keys. For the above example, it's good practice to change the PFS group value to PFS-2048 -you are correct.
      Other low hanging fruit: stroger encryption, stronger hashes, and eliptic curve prime groups.

  3. Replies
    1. It sure does. Just make sure the Open Swan server negotiates the same cryptographic algorithms.

  4. Most of the VPN service providers enjoy wide network coverage therefore rendering their service widely. This not only guarantees a reliable and fast connection but also ensures a fast network. surfeasy vpn coupons

  5. This is achieved by re-routing all the information to a VPN server where the integrity and the security of the information get verified before being transmitted to your system. Best VPN service

  6. Hi Steve, I get this was a while ago but it still comes up in top hits and has good information, Get-IPsecMainMode does not exist as a cmdlet in 1703 strangely there is no Get-VpnConnectionIPsecConfiguration either Microsoft are peddling IKEv2 Always On as the replacement for DirectAccess but none of the tools to effectively manage it seem to exist.

  7. Hi Steve, this post still ranks pretty high in searches and you may have some updated info I haven't found yet but the Get-NetIpsecMainMode cmdlet does not exist in Win10 1703 strangely MS thought a Set cmdlet Set-VpnConnectionIPsecConfiguration was a good idea but left off the Get-VpnConnectionIPsecConfiguration equivalent. Besides knowing what the defaults are have you found an updated cmdlet or command to show these settings as they aren't in the registry by default either? It's interesting that Microsoft is heavily favouring Always On VPN as a replacement for DirectAccess but a lot of the pieces to make managing it easily in the enterprise don't seem to be fully there and it comes out of the box with weak security. I am happy to post back the commands I'll be using to harden IKEv2 VPNs but I'm also happy not reinventing the wheel.

    1. Hi Ryan, Thanks for the updates. FYI, I wanted to confirm everything you've shared. I just tried these commands in Windows 10 build 16299 -it works for me.

      Now, you were testing it on build 1703 (Creators Update from March 2017). I'm running the insider's Fall Creators Update from September of 2017. It's completely possible that these commands are only available on the most recent editions of Windows 10.

      Thanks again for the feedback.

    2. DirectAccess uses the same weak settings.

  8. Thus, you can have a go at playing around with the encryption level, however unless you see huge speed changes with weaker encryption, it is best to adhere to the more grounded variants. browse with indian ip

  9. I wanted to thank you for this great read!! I definitely enjoying every little bit of it I have you bookmarked to check out new stuff you post.
    what does a vpn do for you

  10. I am working with Windows Server 2016 and trying to get it hardened up but still support Windows and Mac and ios and android. It looks like Microsoft has made a change to at least the first Powershell cmdlet you have here, Get-NetIPsecMainMode no longer works. Instead this cmdlet works.

    PS C:\Windows\system32> Get-NetIPsecMainModeSA

    Name : 167
    LocalEndpoint :
    RemoteEndpoint :
    LocalFirstId.Identity :
    LocalFirstId.ImpersonationType : None
    LocalFirstId.AuthenticationMethod : Certificate
    LocalFirstId.Flags : None
    RemoteFirstId.Identity :
    RemoteFirstId.ImpersonationType : None
    RemoteFirstId.AuthenticationMethod : EAP
    RemoteFirstId.Flags : None
    LocalSecondId.Identity :
    LocalSecondId.ImpersonationType :
    LocalSecondId.AuthenticationMethod :
    LocalSecondId.Flags :
    RemoteSecondId.Identity :
    RemoteSecondId.ImpersonationType :
    RemoteSecondId.AuthenticationMethod :
    RemoteSecondId.Flags :
    CipherAlgorithm : DES3
    HashAlgorithm : SHA1
    GroupId : DH2
    KeyModule : IkeV2
    MaxQMSAs : 0
    LifetimeSeconds : 28810
    LocalUdpEncapsulationPort : 4500
    RemoteUdpEncapsulationPort : 4500
    ExtendedFilterId : 0

    One thing I haven't been able to verify from your excellent articles on this topic is can I enable these changes on the server to allow clients with better authentication to connect with DH14 and AES but still allow the clients that I can't upgrade yet due to time constraints to still connect with DH2 and 3DES?
    I just can't get to everything simultaneously, but if I can roll out what I have and let our corporate folks in for now then I can check the server and see who not not yet connecting securely and get them up to speed.

    I am configuring the Windows Always On VPN, it is actually pretty cool and I am hoping I can integrate what I have so far with your modifications. There is a way to make a template VPN profile and export .xml or .ps1 scripts to roll it out with SCCM or Intune, but I found something even easier by simply copying the rasphone.pbk file around. If I copy the pbk file to the C:\Users\All Users\Microsoft\Network\Connections\Pbk folder, it adds the VPN connector to their list and leaves their personal VPN connections alone, or it can be appended to an existing AllUsers connection list with this powershell as a Computer Shutdown script. I copy the .ps1 file to the \\sysvol\...\policies\GUID\Machine\Scripts\Shutdown folder so the clients get a local copy of it to run and will try to fix it even if the user did something foolish and deleted it somehow. This way I avoided making the users local admins to be able to add a VPN connection with the Windows AO deployment script which is needed too.

    $PBKFile = Get-ChildItem 'C:\Users\All Users\Microsoft\Network\Connections\Pbk\rasphone.pbk' -ErrorAction SilentlyContinue
    If (!$PBKFile.Exists){
    Copy-Item '\\fileserver\Public\VPN\rasphone.pbk' 'C:\Users\All Users\Microsoft\Network\Connections\Pbk\rasphone.pbk'
    # Write-Host "File Copied, exiting now."
    If (!((Get-Content $PBKFile) -Contains '[VPN-Connector-Name]' )){
    # Write-Host "Adding VPN-Connector-Name to existing file."
    Add-Content $PBKFile -value (Get-Content '\\fileserver\Public\VPN\rasphone.pbk')
    #Else {Write-Host "No Changes Made."}

    What I am thinking is that I can push out whatever registry changes are needed by group policy, make a new VPN template as the windows AO VPN docs say to do, then run your commands on that VPN connector to make it secure, then distribute the pbk in the way I am doing to update the VPN connector over time. What do you think?

  11. This is essential when government VPN For Qatar confinements keep you from review particular sites.


My Instagram