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 -SALifeTimeSeconds 28800 -MMSALifeTimeSeconds 86400 -SADataSizeForRenegotiationKilobytes 1024000

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.

Root Certificate

It is essential to define the root certification authority for which to accept IPsec security associations (SAs) for IKEv2 VPN connections. Without this setting configured, the VPN server will accept IPsec SAs using any certificate issued by a CA defined in its Trusted Root Certification Authorities certificate store. To configure this setting, open an elevated PowerShell window and run the following commands.

$Thumbprint = โ€˜Root CA Certificate Thumbprintโ€™
$RootCACert = (Get-ChildItem -Path cert:\LocalMachine\root | Where-Object {$_.Thumbprint -eq $Thumbprint})
Set-VpnAuthProtocol -RootCertificateNameToAccept $RootCACert -PassThru
Restart-Service RemoteAccess -PassThru

Note: A PowerShell script to implement the root certificate name to accept can be found here.

CRL Checking

By default, RRAS does not enforce CRL checks for IKEv2 VPN connections. Additional configuration is required to enable support for CRL checking. Microsoft published guidance for configuring CRL revocation checks for IKEv2 VPN connections using machine certificate authentication here. Specifically, administrators must enable the RootCertificateNameToAccept parameter (guidance above) and set the following registry key to enable this functionality.

New-ItemProperty -Path โ€˜HKLM:\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\Ikev2\โ€™ -Name CertAuthFlags -PropertyTYpe DWORD -Value โ€˜4โ€™ -Force
Restart-Service RemoteAccess -PassThru

Note: A PowerShell script to configure root certificate settings and enforce CRL checking 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.

<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

194 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
    • Correct. As long as the CryptographySuite element is nested between the NativeProfile elements you’re good. ๐Ÿ™‚

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

    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 ๐Ÿ™‚

      • Tom

         /  May 18, 2021

        I feel like I’m asking a stupid question here, I’m sorry – but are you saying that despite our internal root CA only being SHA1/RSA 2048, we can use this config for the IPSec tunnel?

        That would definitely fix a few headaches for me if that’s the case.

      • Absolutely. IPsec will work with RSA and SHA-1 as long as you configure the same settings on the client. ๐Ÿ™‚

  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.

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

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

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

    Reply
    • Steve C

       /  January 18, 2020

      I run separate RAS servers for the device and user tunnels. I found that I had to leave this option off for the user tunnel RAS servers also:
      -SADataSizeForRenegotiationKilobytes 102400

      Reply
      • Steve C

         /  January 20, 2020

        I discovered that SADataSizeForRenegotiationKilobytes was not the real problem. The real problem was that I needed to enable IKEv2 Fragmentation as described in Richard’s article here:
        https://directaccess.richardhicks.com/2019/02/14/troubleshooting-always-on-vpn-error-code-809/

        Note that if you don’t enable fragmentation you can still establish a connection using the custom IKEv2 security detailed in this post if a connection was previously established using default security, so restart all of your VPN infrastructure and your client to be sure your configuration is thoroughly tested.

      • Dan S

         /  August 25, 2021

        Steve, I’m interested in your choice to use separate servers for the device and user tunnels. Was it an organizational decision or in response to an issue?
        I’m currently dealing with certain users’ IKEv2 connections being dropped and then not reconnecting. I’m using Richard’s IPsec settings, IKE fragmentation and have added IkeNumEstablishedForInitialQuery DWORD = 50000 to the registry. Dividing the tunnels would reduce the number of connections to a server from a single IP, which most of my reading claims is the root of this issue.

      • Andrew

         /  August 26, 2021

        Hi Dan
        I have had similar issues with using both user and devic with IKE
        I am using kemp loadbalancer which had some issues with persistence which Kemp helped address
        I also found this article which also helped
        https://www.poweronplatforms.com/managing-inconsistent-aovpn-disconnects/

  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.

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

      Reply
    • victor bassey

       /  September 27, 2019

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

      Reply
  15. Colin

     /  August 7, 2019

    Richard,

    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.

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

      Reply
      • 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. https://directaccess.richardhicks.com/2019/01/07/always-on-vpn-ikev2-connection-failure-error-code-800/

      • 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

        Enjoy!

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

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

      Reply
      • 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. ๐Ÿ™‚

      • victor bassey

         /  October 31, 2019

        Do I still need device tunnel if I’m going to be managing VPN clients via intune?

      • That depends. If your clients are still on-premises domain-joined, then perhaps. If they are Azure AD-joined only, then no.

      • Victor Bassey

         /  November 2, 2019

        Thanks Richard that makes sense.

  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:

    CLIENT SIDE CONFIGURATION:

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

    SERVER SIDE CONFIGURATION:

    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

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

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

    • Michael Leeming

       /  October 29, 2019

      What are best practices for these two IKEv2 parameters?
      Defaults are:
      SADataSizeForRenegotiation(KB) : 102400
      SALifeTime(s) : 3600

      I think 1 hour for SALifeTime(s) is too low, but if datasize before renegotion is only 100MB, then 1 hour is probably enough in most cases anyway.

      Could it be that disconnecting clients are often caused by too many SA renegotiations? (what if downloading large files cause hundres of renegotiations in a short timespan!)

      Maybe I’m misunderstanding these parameters, but I have not found any newer great articles about best practice for the values inside the IKEv2 tab in RRAS properties:

      IKEv2 client connection Controls:
      Idle time-out (minutes) = 5
      Network Outage Time (minutes) = 30 (this specific parameter is not even listed in Get-VpnServerConfiguration)

      Security Association expiration control:
      Security Association expiration time (minutes) = 60
      Security Association data size limit (MB) = 100

      Anyone have great experience tweaking these values for the better?

      Reply
      • Michael Leeming

         /  October 29, 2019

        We had an incident today, where the “IKE and AuthIP IPsec Keying Modules” service terminated unexpectedly.

        Faulting application name: svchost.exe_IKEEXT, version: 10.0.17763.1, time stamp: 0xb900eeff
        Faulting module name: ikeext.dll, version: 10.0.17763.1, time stamp: 0xeda91c33
        Exception code: 0xc0000005

        This did not cause any disconnecting clients at first, but all clients started to disconnect within 1 hour.
        My best guess is that the SA renegotiations failed, due to the IKEEXT service was restarted while the clients already had device tunnels active.
        Eventually they one by one had to renegotiate the SA, but I guess the IKEEXT service did not recognize or know the clients from ealier SA negotiations and now the renegotiations failed.

        After these events, almost all clients ended up with new device tunnel session, but with multiple sessions in the remote access clients list.
        To clear things up, this is the first time we have had a crash with the IKEEXT service, but we have seen multiple sessions from the same clients many times before this also. (So other times where there are multiple sessions from clients, I guess they failed SA renegotiations for some reason and now the client is not allowed make a valid disconnect and the rras server keeps the broken session forever)

      • Hopefully those services crashing isn’t a regular occurrence. Those services restarting could definitely cause duplicate IPsec SAs though. Restarting the RemoteAccess service would clear them, although it’s potentially disruptive to clients who are connected at the time.

      • I typically use 28800 (8 hours) for the SALifeTime value. I leave the SADataSizeForRenegotation at 102400 (100 MB).

      • Michael Leeming

         /  October 31, 2019

        Hi Richard

        Thank you for the info, I think I will increase at least the SALifeTime to 8 hours also.
        Regarding the service crash we had, I have now create a few powershell scripts, one to list or kill dead duplicate sessions and one to list or kill sessions that are without any MainModeSA/QuickModeSA
        We actually had 20 sessions without SA, long after the service crash
        These scripts have to be use carefully, but as they default list any potential issues found, I will go a head and use them to alert us about broken sessions, along with alerting us if the IKEEXT service crash event happens again. (the hardest part is probably to verify is sessions without SA are actually broken or just waiting to fail the next time SA needs renegotiation)

      • Thanks for the additional detail. I’m working on some PowerShell scripts to manage orphaned sessions currently and will share them via GitHub once they are ready.

  18. John Garrity

     /  November 6, 2019

    Hi Richard, we’re still having issues with the AOVPN Automatic type when using the improved IKEv2 security in-as-much as the connection is still being established with 3DES,SHA1,DH2. We obviously can’t force the higher cipher at the server end until the connection is established with AES128. We are also keen on retaining both SSTP and IKEv2 to cater for higher compatibility for clients whilst also serving those who may have weaker internet connections. Do you know if Microsoft have any fix for this on the horizon?

    Reply
    • John Garrity

       /  November 7, 2019

      ..actually I’ve just had a response from Microsoft who say a fix for this behaviour is due to land in the third week of January 2020.

      Reply
    • When you update the IKEv2 security settings you have to configure both the server and client at the same time, which can obviously pose challenges if you’ve already deployed the solution and have people actively connecting. SSTP and IKEv2 can be used together, but the fallback persistence has been a problem. Microsoft is working on a fix for this and I should be publishing some information on this in the near future. Stay tuned!

      Reply
  19. Mark H

     /  January 7, 2020

    Thanks so much for this blog series, Richard.

    When you say “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.”, would this require a new Workstation Authentication certificate template with settings such as Key Storage Provider, ECDH_P256 & Microsoft Platform Crypto Provider for Cryptography rather than the default Legacy / CSP settings?

    Reply
    • Yes, but keep in mind that your CA must be configured to use EC. A CA with an RSA key cannot issue EC certificates. The best thing to do is implement a new issuing CA and configure it to use EC.

      Reply
    • victor Bassey

       /  January 11, 2020

      Hello John, with ECDH_P256 you cant use Microsoft Platform Crypto Provider for Cryptography, it will have to be Microsoft Software Key Storage Provider. The downside being that you cannot use TPM Key Attestation with ECC based configuration. In case you need to do TPM Key attestation, you will need the Microsoft Platform Crypto Provider which is only available with RSA option,

      Reply
  20. Some Guy

     /  March 13, 2020

    This article is outdated; AES-CBC ciphers are no longer considered a good choice these days. Best to use AES-GCM ciphers exclusively now.

    This article is also incorrect. You do *not* need to use an EC cert for authentication in order to be making use of GCM ciphers and EC key exchange. The only setting that cares whether you have an EC cert or an RSA cert is DHGroup. You have to choose an EC or RSA DHGroup accordingly.

    For present-day best practice, I suggest AuthenticationTransformConstants=GCMAES128, CipherTransformConstants=GCMAES128, EncryptionMethod=GCMAES128, IntegrityCheckMethod=SHA256, PfsGroup=ECP256 and DHGroup=Group14 (for an RSA certificate) or DHGroup=ECP256 (for an EC certificate).

    Reply
    • I agree that using GCM is recommended and preferred. However, Microsoft did not support the use of GCM for encryption with RSA until Windows Server 1803. The guidance I have provided here is a baseline that works well for all supported versions of Windows Server RRAS. Indeed, I recommend and use GCM whenever it is supported for my deployments, but this works well for general use and is certainly better than the default settings. ๐Ÿ™‚

      FYI, thanks for the clarification with regard to using an EC certificate with GCM ciphers. I’ll update the post to reflect that detail soon!

      Reply
  21. Andy

     /  April 17, 2020

    Thought this might be worth putting on here if anyone else has been pulling there hair out. Has anyone seen the following behaviour below.

    If IKEv2 is set to Automatic the elements are not applied to the connection from the xml.

    This is causing me grief as I would like the higher security applied to IKE but also need SSTP. Seems you cant have both!

    This is on 1809 with latest cumulative (April 2020). Haven’t tested on anything else yet.

    I think I’m going to get around it by using some of the scripts to set the vpnstrategy to 8.

    Reply
  22. Alex M

     /  May 12, 2020

    Hi Richard,

    Our 2012 R2 Windows Server is setup to accept VPN connection via the “Routing and Remote Access” Tool.
    We currently only accept L2TP and IKEv2 VPN Connections with a Preshared Key Setting.
    Since our business accepted credit cards, we are required to run a PCI scan via trustwave.com.

    The PCI scans are failing due to:
    Weak Encryption Ciphers identified on VPN Device on port 500 UDP Protocol
    Weak Diffie-Hellman groups identified on VPN Device on port 500 UDP Protocol

    The remediation recommended are:
    Removing support for DES/3DES encryption ciphers on this VPN device.
    Use Diffie-Hellman Key Exchange Group 5 or higher where possible, or the highest available to the VPN endpoints.

    How can I apply the above remediation to our the RRAS on our Server? I have been looking all over the web without much success.

    Thanks in Advance for all your help.

    Reply
    • You can use the native Set-VpnServerConfiguration PowerShell command to update IKEv2 security parameters. Or you can download my script that will configure the values for you using minimum recommended security baselines here: https://github.com/richardhicks/aovpn/blob/master/Set-IKEv2VpnSecurityBaseline.ps1.

      Be advised that you have to update the client configuration as well. Security paraemters must match on both sides of the connection, server and client. You can update client settings using the Set-VpnConnectionIPsecConfiguration PowerShell command.

      Reply
      • Alex M

         /  May 14, 2020

        Thanks Richard.
        I forgot to mention in my post that I did use the ” Set-VpnServerConfiguration” with the parameter you provided in your article.
        And I did checked the configuration using the “Get-VpnServerConfiguration”.
        All looks correct but somehow the scans from trustwave.com are still seeing the week encryption on the VPN connections as being accessible.

        Thanks Again.

      • Interesting. I’m not sure what to tell you then. If you’ve enable those parameters and you see they are in place on the server using Get-VpnServerConfiguration then you should be ok.

  23. Ankur

     /  June 3, 2020

    Hi Richard, I have a set up an AlwaysOnVPN and it’s working fine except it drops after 30 mins of connection. I suspect it may be related to SA Data Size limit = 100 MB. I have set SA Life time = 8 hours. I don’t seem to get any logs on RAS server or on VPN client machine. I am using split tunnel and VPN connection says it’s connected but can’t ping any internal resources. Is it the case where renegotiation is failing? Thanks Ankur

    Reply
    • I use those settings routinely without issue, so I’m not sure that’s the cause of your problems. I’d suggest enabling IPsec auditing on the VPN server and client to see if that provides more information.

      auditpol.exe /set /subcategory:”IPsec Main Mode” /success:enable /failure:enable
      auditpol.exe /set /subcategory:”IPsec Quick Mode” /success:enable /failure:enable

      Look for event IDS in the 4600-5500 range for more information.

      Reply
      • Ankur

         /  June 4, 2020

        Thanks Richard. I have enabled the auditing and now see the IPSec Quick mode is renegotiating as they reach their data-size limit or life-time limit for the same Main mode. I also checked the Firewall on RAS server and it was dropping the traffic for port 5355 and 137,138 and so allowed the traffic for those ports. MainMode SA Connection on RAS get disconnected with event ID 4655 but for the VPN client, Main Mode still stays connected until I manually disconnect the VPN client and then I can see the log of Main mode SA disconnection with event ID 4655.

        I am still using the DES3, SHA1 and DH2 default security parameter and I saw one of the article to use SHA256 and DH14 for better security. I will try that.

        I have used AlwaysOn “True” for the powershell VPN client script. Would that be the reason, even the Main Mode SA disconnected on RAS but Main Mode SA is still connected at client level until I manually disconnect the VPN client.

        Thanks Ankur

      • I’m not sure what to make of this to be honest. I’d definitely recommend using minimum best practice security parameters for IKEv2, but I don’t expect that to resolve your issues.

  24. Is DH Group 21 supported, as a customr would like to use that? Are there any drawbacks to use DH21?

    Reply
    • I don’t believe so. It is not listed in the supported DH Group values in the VPNv2CSP. Only ECP256 (DH Group 19) and ECP384 (DH Group 20) are currently listed.

      Reply
  25. bueschu

     /  June 9, 2020

    Is DH Group 21 supported and are there any drawbacks using it. A customer whises to use DH 21.
    Many thannks

    Reply
    • I don’t believe so. It is not listed in the supported DH Group values in the VPNv2CSP. Only ECP256 (DH Group 19) and ECP384 (DH Group 20) are currently listed.

      Reply
      • bueschu

         /  June 9, 2020

        Many thanks for your help.
        I appreciate your websites with full of very helpfull information. Do you have a book about AOV like the one conerning Direct Access?
        Bueschu

      • Not at the moment. Considering it though. Might have something late this year, you never know. ๐Ÿ™‚

  26. Hello there Richard.
    First thank you for all the great work and sharing of this knowledge. I implement always on VPn with your steps, making also an internal guide for future reference. Everything is working as expected.

    Now Iโ€™m trying hardening the system with this information but Iโ€™m have so much trouble with it. First Iโ€™m implementing the profile using SCCM and Software Center, because we donโ€™t have Intune, though a script. And Iโ€™m using user tunnel.

    I ran the command stand alone and then ran the cmdlet from your script for the server. Restarted the server. When I run the command on my client I have the error that no phone book entry exists, so I canโ€™t never get the changes to apply via PowerShell cmdlet.

    Added the CryptographySuite to the XML and still have profile mismatch. Added this part only with the already info I add:

    โ€ฆโ€ฆ. (content above described)

    After reverting the server and installing the default profile that worked, everything connects. Any idea why the XML containing this info doesnโ€™t match the server?

    Thank you again for all your help!

    Reply
    • If you are implementing custom cryptography using ProfileXML, there is a bug that prevents it from loading correctly if your NativeProtocolType is set to Automatic. Try setting the protocol to IKEv2 and then loading the XML with custom cryptography. Details here: https://directaccess.richardhicks.com/2019/01/07/always-on-vpn-ikev2-connection-failure-error-code-800/.

      Reply
      • Hello Richard. Thank you for your quick answer. It was on IKEv2 already. I found on another site (I think MS foruns) that my NPS only had the highest security selected on the NPS policy. Added all the encryption options and I connected without any issue now. Again great scripts you have over GitHub, many thanks for those!

        This only affects IKEv2 correct? I’m thinking of using SSTP as fallback, that needs some tweaks also? Thank yo uso much again!

      • I’ve heard a few folks report issues when they configure NPS with only highest encryption. Adding all options restores functionality. Not sure exactly why that is…I’ll have to do some testing and see what I learn. ๐Ÿ™‚ Not sure if SSTP is affected to be honest. Only thing you need to do with SSTP is ensure that TLS ciphers are configured optimally. There’s a script for that on my GitHub of course. ๐Ÿ™‚

      • Thank you again for you feedback ๐Ÿ™‚ I used IISCrypto to disable SSL2.0 and 3.0 but will take a look at your scripts and be sure that I didn’t let anything pass. Again thank you again for your time and great tech info!

      • My pleasure! ๐Ÿ™‚

      • Sorry to add another message ๐Ÿ™‚ I was looking at your script for TLS hardening, if I can say it like that, and I understood that TLS 1.0 and 1.1 are disabled with it. On another post, regarding Reporting, there were some comments that we should maintain TLS 1.0 if possible. Any other downsizes of disabling TLS 1.0 and 1.1? The script doesn’t have a reset option. I just need to remove the registry entries that are created? Thank you again.

      • Disabling TLS 1.0 and 1.1 on Windows Server 2016 and earlier will break reporting. No issues at all disabling it in Windows Server 2019 though. Backing out is a simple as deleting the registry key HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002\. Backing out the TLS settings just requires changing from DWORD 0 to 1.

      • Hello Richard.
        I looked for the script for TLS improvement and checked that TLS 1.0 and 1.1 is disabled with it. Also there is no “reset” option, so I didn’t test it yet.
        On another post you mentioned that TLS 1.0 should not be disabled because the reporting portion of RRAS will no longer work.

        So is it safe to change the TLS options? Is there an option to reverse it?
        Thank you again for all your help.

      • I will look in to adding an option to revert the changes made by the script for sure. However, backing out the changes to cipher suite order is as easy as deleting the following registry key: HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002\.

        As for disabling TLS 1.0 and 1.1, you can do that safely on Windows Server 2019. However, if you do this on Windows 2016 and earlier it will break reporting. I will update the script soon to include a warning and possible option to skip that step if necessary.

  27. Rob M

     /  June 23, 2020

    Hi Richard, Big fan of your work. Got me out of a lot of holes ๐Ÿ™‚

    Just wondering have you come across any problems with device tunnels not connecting due to an error ID – 20255 – New policy invalidated SAs formed with old policy.

    I’m thinking its something to do with the SALifeTime(s) configuration but not sure really. Its set to 3600 (Default)

    Thanks.

    Reply
    • Not encountered that specific issue myself. However, I am aware of some IKEv2/IPsec issues in Windows that Microsoft is working to address, it could possibly be related.

      Reply
  28. Shaun Danz

     /  June 30, 2020

    I found this blog while trying to trouble-shoot Policy Match Errors on some of our AOVPN clients. The problems persist even after following these instructions. I notice though, that when running Get-NetIPsecMainModeSA | Select-Object -First 1 on both the client and the server, the client shows LifetimeSeconds of 28800 but the server shows 28810. Do you think this is where the policy mismatch is occurring?

    Reply
    • Different SA lifetimes would not cause a policy mismatch error. It is most likely to do with authentication or encryption settings. Does this issue occur for the device tunnel, user tunnel, or both?

      Reply
  29. TB

     /  July 29, 2020

    Hello, thanks for your article! The problem I see is that we need to do the change “one shot”, on servers and devices. Is there a way to tell Windows 10 to negociate the best cipher to make a soft transition to AES128? When all Windows 10 are up to date with the new settings I can change the settings safly on the server side?

    Thanks!

    Reply
    • Not to my knowledge, but that’s a good point. If you’ve deployed Always On VPN and IKEv2 using default parameters and want to update after clients have been provisioned it will be highly disruptive. I’ll do some research and let you know what I find.

      Reply
  30. Nat Hazlett

     /  October 27, 2020

    Hi Richard,
    First of all, thanks for maintaining an excellent resource for all things AOVPN / DA related – it’s been incredibly helpful ๐Ÿ™‚

    Just a heads up for anyone else playing with a custom IPSec policy, there’s a little gotcha in the XML config…

    Whilst “GCMAES128” is a valid entry for AuthenticationTransformConstants, and for CipherTransformConstants, it’s NOT a valid entry for EncryptionMethod, even though it’s probably the value you’re trying to set, and its both valid and what PowerShell reports once you’ve set it manually. When configuring EncryptionMethod via the ProfileXML, you will need to use the string “AES_GCM_128” instead of “GCMAES128”.
    (The valid options are listed about halfway down this page https://docs.microsoft.com/en-us/windows/client-management/mdm/vpnv2-csp – just search for EncryptionMethod )

    I have absolutely no idea why they would switch it out for this one option >.< thankfully it didn't take me too long to find ๐Ÿ™‚

    Thanks again for all of your efforts here!
    Nat

    Reply
  31. Urs Egli

     /  November 18, 2020

    We have the following IPSec Settings on the VPN User Tunnel Client
    AuthenticationTransformConstants : SHA256128
    CipherTransformConstants : AES128
    DHGroup : Group14
    IntegrityCheckMethod : SHA256
    PfsGroup : PFS2048
    EncryptionMethod : AES128
    if we would use DH Group 20 (ECP384) instead of Group 14 would this mean that we can’t use our RSA Key CA for the User VPN Certifcates. So we had to build a new EC Key CA?

    Reply
    • These settings are for IKEv2 and IPsec. They won’t have any impact on certificates used for user authentication. For the record, if you use DH Group 20 you’ll need to have an EC certificate installed on the VPN server. Also, if you plan to use TPM for user certificates (highly recommended) then they must be RSA. EC is not supported on TPM.

      Reply
      • Urs Egli

         /  November 24, 2020

        Does this mean we have just to follow your recommendation in the following links to use DHGroup20
        https://directaccess.richardhicks.com/2018/08/20/always-on-vpn-ecdsa-ssl-certificate-request-for-sstp/
        https://directaccess.richardhicks.com/2018/07/16/always-on-vpn-ssl-certificate-requirements-for-sstp/
        Actually we have 2 certificates on the VPN Server, one from the internal CA (RSA) and one public certificate for the SSTP (RSA) connections. The first certificate is based on the VPN Server Authentication template according to the microsoft documentation.
        Template=1.3.6.1.4.1.311.21.8.5414884.4052086.14503085.3847168.13024048.246.5587852.14086471

        If we install a new public certificate for the SSTP connections using ECC or ECDSA does this solve our problem and we can connect with IKEv2 and SSTP using DH Group 20 when clients still using RSA certificates?

        Many thanks for your fantastic and very interesting blog and your help

      • You would not need to configure DH groups for SSTP, only for IKEv2. If you install a TLS certificate for SSTP that uses ECDSA keys there’s nothing else to configure. You can connect with SSTP or IKEv2 because they use different certificates. Using an EC certificate for SSTP won’t negatively affect IKEv2. IKEv2 can still use RSA certificates in that scenario.

  32. Urs Egli

     /  December 7, 2020

    Many Thanks for your help and the fantastic blog

    Best regards – urs egli

    Reply
  33. Andrew

     /  January 4, 2021

    Hi All, firstly what a great resource this and Richard has been fantastic in assisting with any queries. I have a very unique setup / issue to challenge everyone.
    1. Everything is setup and working correctly for both internal and external connections, Device tunnel connects for pre windows authentication and then vpn user tunnel connects and works perfectly for external connections – All good.
    2. We have a unique setup for a segment of our network. This part of the network is sort of a public wifi BUT is on the mpls of the main network so all traffic from this network hits the firewall and routes to internet but for the VPN server access it hits the firewall and then hits the DMZ as it cannot go out to internet and back in for the VPN access it does not route to the external IP. I have set the user tunnel as test and can connect to the dmz address rather than the public address with SSTP and it works fine. If I connect via IKE the tunnel is created and I get connected I can see the tunnel on the server and the IP address it has assigned the client but the client sticks on identifying and eventually has the vpn connection name instead of the domain. I can see that there is no traffic flowing from the server to the client although the tunnel is connected. It appears to potentially be some kind of nat issue with IKE but I am not seeing any errors. Any suggestions of what i can check to find the route cause of this would be great, all ports are open etc. It maybe that using IKE is not possible in this scenario
    many thanks in advance

    Reply
  34. James A

     /  January 10, 2021

    I’m having a funny issue where the connection (deployed via Intune) connects the first time, but then at some point it stops working. It seems like phase 1 is up but phase 2 drops and doesn’t reconnect. The client (win 10 edu 20H2) thinks it’s connected though. The odd thing is “get-vpnconnection |select -expandproperty ipseccustompolicy” shows nothing, but earlier it did show my custom settings (AES128, SHA2-256, DH group 14). “Get-NetIPSecMainModeCryptoSet -PolicyStore ActiveStore” only shows “DirectAccess – Phase1 Crypto Set” (and this laptop is still configured for DirectAccess, but AoVPN takes over so DA thinks it’s connected to corporate network) which is all DH2 (with AES128/SHA256, AES128/SHA1, DES3/SHA1). So maybe DA is overriding the policy? “Get-NetIPsecMainModeSA” reports varying results, one time AES256/SHA256/DH2, the next AES128/SHA256/DH14 (but I did deploy the profile with a new VPN name so I could be sure it had gone out, and of course it made a second VPN connection rather than disabling the first.). The Intune profile doesn’t apply cleanly, right now it’s erroring with “-2016346112 (No error code)” but it’s had another one in the past, I can’t see anything in the Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin log that’s obvious to do with the profile. The VPN server is a fortigate fwiw. Anyway I don’t expect a particular answer, just dupming stuff here for the benefit of google.

    Reply
  35. VBSingh

     /  January 19, 2021

    Hi Richard,
    Firstly, thank you sharing your knowledge on this voodoo known as DirectAccess and Always On VPN!

    I came across some information about stale IKEv2 connection from the following site: https://directaccess.richardhicks.com/2018/12/10/always-on-vpn-ikev2-security-configuration/

    As suggested, a reboot seemed to have cleared all stale connections, but I was hoping you could offer some guidance on how to removed stale/duplicate sessions. I was thinking about a powershell script that could find multiple entries of the same computer name and probably remove the oldest.

    Reply
  36. Jonatan Kragh Hovgaard

     /  January 25, 2021

    I have several different deployments where cryptography settings for IKEv2 in the XML file is ignored when “NativeProtocolType” is set to “Automatic”. If I change the protocol to IKEv2 the correct cryptography settings will be deployed to the client. From my point of view, it seems like we have a bug which caused Windows 10 to ignore IKEv2 cryptography configuration if the XML file if “auto” is beeing used. Does anybody else have this issue?

    Reply
  37. Fabio

     /  January 27, 2021

    Hello Richard!
    Regarding SSTP ciphers, I have the doubt related to the SSTP configuration. Do I need to change anything on the client side or that is only applied to the IKEv2 connections?

    I have the IKEv2 hardened by your script (thank you) and after checking the server security with an external pentest the only “flag” I had is TLS 1.0. On Server 2016 it will break reporting, as you stated, but wanted to know the effects on the connections (if any) when changing the cipher.

    For IIS i used IIS Crypto sometimes, and when I open on the RRAS server I see some old hash algorithms and ciphers that I was asked to disable (for example some with CBC).

    Thank you again for all your help and all this valuable information!

    Reply
    • For IKEv2, you must match the policies on the client and server. If you change it on the server (highly recommended), then you must update the client. You can define custom cryptography settings for IKEv2 in Intune or in ProfileXML. However, there’s a bug in Windows that prevents custom cryptography settings from being applied if you select “Automatic” for the NativeProtocolType. For SSTP, I have a script that can be used for hardening the TLS configuration here: https://github.com/richardhicks/aovpn/blob/master/Optimize-VpnServerTlsConfiguration.ps1. Indeed, disabling TLS 1.0 on Windows Server 2016 will break reporting, but won’t affect client connections at all.

      Reply
      • Thank you! I was checking your script and in the information I received, and using IISCrypto, I was told to disable all these ones:

        TLSv1.0
        TLS_RSA_WITH_AES_256_CBC_SHA
        TLS_RSA_WITH_AES_128_CBC_SHA
        TLSv1.1
        TLS_RSA_WITH_AES_256_CBC_SHA
        TLS_RSA_WITH_AES_128_CBC_SHA
        TLSv1.2
        TLS_RSA_WITH_AES_256_GCM_SHA384
        TLS_RSA_WITH_AES_128_GCM_SHA256
        TLS_RSA_WITH_AES_256_CBC_SHA256
        TLS_RSA_WITH_AES_128_CBC_SHA256
        TLS_RSA_WITH_AES_256_CBC_SHA
        TLS_RSA_WITH_AES_128_CBC_SHA

        It would only remain TLS_ECDHE_*
        For those I need an EC certificate correct? The one I have it can’t be using EC just yet, so I can’t just disable all of these correct? I think I should disable the ones using CBC?

        For your script, with a traditional SSL certificate, which option should I use? Sorry for so many questions but I just don’t want to “kill” the SSTP functionality just because someone told to remove all of these. Thank you in advance!

      • Not necessarily. You would still have TLC_ECHDE_RSA_* ciphers available for use with an RSA certificate. You should in theory be able to disable other ciphers and SSTP should still work. I’d test before implementing in production though. ๐Ÿ™‚

      • Thank you for the info regarding the ciphers! Used the IIS Crypto to disable all non EC ciphers, and also TLS 1.0 and 1.1 for the server side, and it worked perfectly!

        Again thank you so much for all your valuable information!

      • Sweet! Glad it worked out for you! ๐Ÿ™‚

  38. DLH

     /  January 29, 2021

    I’m working on getting RRAS to pass a PCI compliance test. It’s showing that 3DES and DH2 are still valid on port 500. I’ve run your PS script on a fully patched Windows Server 2019 (1809). It still fails the scan. When I test with “ike-scan” I get the same results.

    Main Mode Handshake returned HDR=(CKY-R=9dd57f7c7117dd6b) SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration(4)=0x00007080)

    Any ideas why? Have you run ike-scan on one of your hardened servers? Does it still show DH Group 2?

    Reply
  39. Kieran

     /  February 28, 2021

    We recently deployed AOVPN due to Covid and didn’t realise that the Ciphers etc aren’t exactly ideal until it was too late. I want to migrate to using AES128 etc but don’t want to cause an outage. Is it possible to enable AES etc whilst leaving 3DES still in place until the migration is complete?

    Reply
    • Not to my knowledge. I’ve tried a few things to make this work but have been so far unsuccessful. Your only option to do this seamlessly will be to implement new infrastructure in parallel and migrate users from the old to the new.

      Reply
  40. Ludde

     /  March 3, 2021

    Hi! I have ran into a very interesting issue that I simply cannot solve. In order to increase security of our existing Always-ON VPN solution I modified the existing CustomPolicy replacing the DH Group from 24 to ECP384 and the PFS from 24 to ECP384 on both clients and the server configuration. That resulted in the error event of 13806 and the error message “IKE failed to find a valid machine certificate. Contact your network security administrator about installing a valid certificate in the appropriate certificate store.”

    I tried modifying the Certificate Template cryptography from RSA 4069 to ECDSA 384 on the Workstation certificate but it did not resolve the issue.

    Any advice would be greatly appreciated and does the server certificate also need to be using ECDSA / the same crypto suite as the workstation certificate?

    Reply
    • You can’t issue an EC certificate from a CA configured with an RSA signing key. You’d have to configure the CA to use EC, then you could issue EC certificates.

      Reply
  41. Bob Clark

     /  April 13, 2021

    Our PKI uses an Intermediate CA to create client certificates. Should we configure the RAS Server to trust the intermediate cert, or should we still trust the Root that we used to signed the Intermediate Cert??

    Reply
  42. Simon Knaggs

     /  May 9, 2021

    Hi Richard, big fan of your work – have been making use of your guides and knowledge since the Direct Access days, and implemented Always On VPN over a year ago now.

    We use split tunnelling and machine based authentication, all works like a dream.

    I’m currently in the process of securing communication to certain servers using connection security rules. All works perfectly on the internal LAN, as well as from a client machine on a remote network traversing an appliance-based VPN.

    Endpoints are defined broadly for this test configuration, and for a remote client connected via Always On VPN, main mode and quick mode security exchanges between the remote client and the server are successful, but no data passes between them. Data passes normally without the rules on either end in place, and as I say, the internal configuration works normally so it’s not fundamental.

    Is this is an issue with IPSEC within IPSEC (I think not given the security associations are successful?) or some sort of routing based issue specific to remote clients using always on VPN?

    Any hints on further troubleshooting would be appreciated, before I raise the issue with Microsoft and see what they might have to say on the matter!

    Thanks.

    Reply
    • Thanks Simon! Glad you are finding useful information here on the site. ๐Ÿ™‚ I’ve never tested the scenario using IPsec within a VPN tunnel, so I don’t have any experience to share with you here, unfortunately. It could very well be a limitation of using IPsec within IPsec (IKEv2). A good test would be to use an SSTP tunnel to see if it behaves any differently. Let me know what you find!

      Reply
  43. First – thanks so much for this for this article – the RRAS Custom IPsec Policy section was โ€‹very helpful.

    We are deploying Always On VPN with only user tunnels (no device tunnels at this time). User tunnels authenticate by EAP (RADIUS) with a TPM backed (EKPub method) user certs.

    The output of PowerShell Get-VpnAuthProtocol on our RRAS server does not include “Certificates”. It seems according to the PowerShell command documentation that the -RootCertificateNameToAccept parameter only applies if the UserAuthProtocolAccepted parameter contains “Certificates”.

    Is that correct? Just wanting to make sure we are not missing something here. Thanks again for all of the great information you provide.

    Reply
    • That’s correct. One of the user authentication protocols must be “certificate” in order to configure those additional parameters such as root certificate to accept.

      Reply
  44. Q

     /  May 27, 2021

    Is it applicable or possible to define the root CA for which to accept IPsec SAs, or enforce CRL Checks for VPN Connections if only allowing Ikev2 User Tunnel with Certificate Authentication on the RRAS server?

    Reply
  45. Matthias

     /  June 17, 2021

    I am curious what are the “best” (not minimum) settings for rsa, while our CA is able to issue ECC certificates, i cant get an working connection those settings on user and server side

    $Parameters = @{
    AuthenticationTransformConstants = ‘GCMAES128’
    CipherTransformConstants = ‘GCMAES128’
    DHGroup = ‘Group14’
    EncryptionMethod = ‘GCMAES128’
    IntegrityCheckMethod = ‘SHA256’
    PFSgroup = ‘ECP256’
    }

    So we are using
    $Parameters = @{
    AuthenticationTransformConstants = ‘SHA256128’
    CipherTransformConstants = ‘AES256’
    DHGroup = ‘Group14’
    EncryptionMethod = ‘AES256’
    IntegrityCheckMethod = ‘SHA256’
    PFSgroup = ‘PFS2048’
    }

    For Client and Server ( i read your link about aes256). But is there something we can improve without taking our whole ca infrastructure to ecc certificates?

    Any recommendation to get max sec?

    This is our ecc server certificate, our client/user are look similar
    https://abload.de/img/cert.w2kr2.png

    Is there a way to use gcm?

    Reply
    • The best settings for IPsec with RSA certificates are as follows:

      AuthenticationTransformConstants GCMAES128
      CipherTransformConstants GCMAES128
      DHGroup Group14
      EncryptionMethod GCMAES128
      IntegrityCheckMethod SHA256
      PFSgroup ECP256

      If you use ECC certificates, you can use the following settings for even better security:

      AuthenticationTransformConstants GCMAES128
      CipherTransformConstants GCMAES128
      DHGroup ECP256
      EncryptionMethod GCMAES128
      IntegrityCheckMethod SHA256
      PFSgroup ECP256

      It’s important to remember that if you are configuring this using XML, the GCM encryption method must be specified as AES_GCM_128. Why that syntax is different than it is from the authentication or cipher transforms I have no idea. ๐Ÿ™‚

      Reply
      • Matthias

         /  June 18, 2021

        Sadly no luck with those settings, with the working rsa certificates and

        AuthenticationTransformConstants GCMAES128
        CipherTransformConstants GCMAES128
        DHGroup ECP256
        EncryptionMethod GCMAES128
        IntegrityCheckMethod SHA256
        PFSgroup ECP256

        Client jumps from connection to authentication back to connection and is stuck there. Client message (translated sorry)
        “Remote connection could not be established caused by an VPN-Tunnel error. The VPN Server may not be reachable. If there is a L2TP/IPSec-Tunnel in use, the required security parameter may not configured correctly.”

        We see the following errors in eventlog (VPN Server)
        EventID 20271 (while we dont see any event on the nps)
        followed by
        EventID 20255 (message includes not authenticated)

        We set it for client and server, rebooted both. No luck. Also tried pfsgroup PFS2048 instead of ecp256. Any ideas on this?

      • If you are using RSA certificates, then you must use Group14 as the value for DH Group. ECP256 for DH will only work with ECC certificates. You can still use ECP256 for PFS with RSA certificates, however. You must be running Windows Server 2019 or later though to support that.

      • Matthias

         /  June 18, 2021

        sorry, my bad. I meant we tried
        AuthenticationTransformConstants = ‘GCMAES128’
        CipherTransformConstants = ‘GCMAES128’
        DHGroup = ‘Group14’
        EncryptionMethod = ‘GCMAES128’
        IntegrityCheckMethod = ‘SHA256’
        PFSgroup = ‘ECP256
        for client and server (copied the wrong one)
        https://abload.de/img/serveripsecqrkwn.png

        This is what we use to configure
        Server
        $Parameters = @{
        AuthenticationTransformConstants = ‘GCMAES128’
        CipherTransformConstants = ‘GCMAES128’
        DHGroup = ‘Group14’
        EncryptionMethod = ‘GCMAES128’
        IntegrityCheckMethod = ‘SHA256’
        PFSgroup = ‘ECP256’
        SALifeTimeSeconds = ‘28800’
        MMSALifeTimeSeconds = ‘86400’
        SADataSizeForRenegotiationKilobytes = ‘1024000’
        }
        [PSCustomObject]$Parameters | Set-VpnServerConfiguration -CustomPolicy

        Client
        $Parameters = @{
        ConnectionName = ‘Template’
        AuthenticationTransformConstants = ‘GCMAES128’
        CipherTransformConstants = ‘GCMAES128’
        DHGroup = ‘Group14’
        EncryptionMethod = ‘GCMAES128’
        IntegrityCheckMethod = ‘SHA256’
        PFSgroup = ‘ECP256’
        }
        [PSCustomObject]$Parameters | Set-VpnConnectionIPsecConfiguration -Force

        Just double checked it and had no luck. Doesnt work for us.
        Running Windows Server 2019 and Windows 10 20h2
        Both rebooted after setting it.

        Actually we are at the point, seeing the success in nps but still event id 20255 at the ras/vpn server.

        Dont get it why.

      • Did you change any of the encryption settings on the NPS rule? If you’ve disabled both Basic and Strong encryption it will result in a policy mismatch error.

      • Matthias

         /  June 22, 2021

        We`ve disabled basic and strong (but not strongest). Tried to activate basic + strong. But same result. Think i give up on this

      • Try enabling all of them and see what happens. I’ve tested this myself and it should work if you have either Basic or Strong Encryption checked. But it won’t work if both are unchecked.

  46. Chris

     /  July 2, 2021

    Hi Richard

    I just ran your Optimize-VpnServerTlsConfiguration.ps1. Much appreciated. However SSLLabs listening those as WEAK:
    TLS_RSA_WITH_AES_256_GCM_SHA384
    TLS_RSA_WITH_AES_128_GCM_SHA256

    Do you think I can safely disable them with those settings on the server:

    AuthenticationTransformConstants : GCMAES128
    CipherTransformConstants : GCMAES128
    CustomPolicy : True
    DHGroup : Group14
    EncryptionMethod : AES256
    Ikev2Ports : 2044
    SstpPorts : 2044
    GrePorts : 0
    IdleDisconnect(s) : 300
    IntegrityCheckMethod : SHA256
    L2tpPorts : 0
    PFSgroup : ECP256
    SADataSizeForRenegotiation(KB) : 102400
    SALifeTime(s) : 28800

    Unfortunately I cannot use ECC Certs as SCCM (Software Center) does not support ECC Certs.

    Reply
    • You can certainly try, but it might break other things like RDP or remote system management. Honestly, it’s not terrible that those ciphers are supported. They are still pretty decent, just not the absolute best at the moment.

      Reply
  47. Carmen D.

     /  July 21, 2021

    Hi Folks,

    I’m looking for some advice from the community and/or Richard regarding the best way to apply enhanced security settings to an existing AO VPN connection using “Set-VpnConnectionIPsecConfiguration”. The majority of our environment is in an on-prem AD domain managed by SSCM with a small subset of Intune managed systems. So my focus is currently on-prem. I’ve been able to get the base VPN client configuration to successfully deploy to my POC group with an SCCM package however I can’t seem to get the “Set-VpnConnectionIPsecConfiguration” portion to apply whether I include it as an additional command at the end of the base vpn_profile.ps1 script generated from my test workstation or attempt to deploy it as a second standalone SCCM package with a separate PowerShell script. Any advice would be appreciated… Thanks!

    Reply
    • It is recommended to deploy the custom cryptography settings as part of the initial configuration by defining them in ProfileXML. This assumes you are using Always On VPN of course. If this is a standard Windows VPN profile, your only option to change the settings is with PowerShell. If you are still having issues getting PowerShell to work, you could also edit the rasphone.pbk entry. I’d recommend using PowerShell though. ๐Ÿ™‚

      Reply
      • Carmen D.

         /  July 23, 2021

        Richard,

        Thanks for the suggestion, it nudged me in the right direction and I was able to get the settings applied appropriately using the CrytographySuite settings block listed in your GitHub example files. Your expertise is much appreciated !

      • Great to hear. Enjoy! ๐Ÿ™‚

  48. Dave

     /  July 28, 2021

    Thanks for your info here Richard, rolling out AOVPN all your articles make sense and are easy to follow. Also see you like Untappd so added you on there. Cheers good sir.

    Reply
  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.
  12. Always On VPN Device Tunnel with Azure VPN Gateway | Richard M. Hicks Consulting, Inc.
  13. Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC | Richard M. Hicks Consulting, Inc.
  14. Always On VPN Device Tunnel and Custom Cryptography Native Support Now in Intune | Richard M. Hicks Consulting, Inc.
  15. Always On VPN IPsec Root Certificate Configuration Issue | Richard M. Hicks Consulting, Inc.

Leave a Reply to victor Bassey Cancel reply

%d bloggers like this: