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 RaMgmtSvc -PassThru

Always On VPN IKEv2 Security Configuration

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.

<VPNProfile>
 <NativeProfile>
  <CryptographySuite>
   <AuthenticationTransformConstants>SHA256128</AuthenticationTransformConstants>
   <CipherTransformConstants>AES128</CipherTransformConstants>
   <EncryptionMethod>AES128</EncryptionMethod>
   <IntegrityCheckMethod>SHA256</IntegrityCheckMethod>
   <DHGroup>Group14</DHGroup>
   <PfsGroup>PFS2048</PfsGroup>
  </CryptographySuite>
 </NativeProfile>
</VPNProfile>

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

32 Comments

  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!

    Reply
  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?

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

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

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

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

    Reply
  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?

    Reply
  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?

    Reply
  7. Colin

     /  December 10, 2018

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

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

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

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

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

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

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

      Reply
  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

    Reply
  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?

    Reply
    • Colin

       /  January 10, 2019

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

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

  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.

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: