Harden RRAS IKEv2

How To:  

Harden Windows Server 2012R2 Routing and Remote Access (RRAS) VPN server.  Implement strong IKEv2 VPN cryptography:
• Diffe-Hellman Group (DH) 14 or DH Group 19
• Enable AES256 and SHA256 L2TP/IPsec and IKEv2 on Windows Server VPNs.

This simple method significantly improves security strength for Windows 2012 IPsec VPNs.

Problem:  

Windows RRAS server negotiates insecure IKEv2 and L2TP/IPsec cryptographic algorithms:

  • DH2-3DES-SHA1.   
Weak security strength risks data integrity and confidentiality.  IKE SA authenticates with RSA certificates.

This problem impacts all RRAS VPN clients:  Windows 10 phones, iPhones, Android, Cisco, Juniper and Sawn.  

Solution:  

Enable strong IPsec security algorithms in the Windows server registry:

  • IKEv2 DH14-AES256-SHA256

This (mostly) original approach is hands-down the easiest way to secure a Windows 2012 IKEv2 or L2TP/IPsec VPN.

Step 1:  Regedit:

HKLM\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\IKEV2\

Step 2:  Create new key:

\IKEv2CustomPolicy\

Step 3:  Create new DWORDs (Table 1):



Table 1
IKEv2CustomPolicy DWORD Attributes

IntegrityMethod1Integrity check algorithm to be negotiated during MM SA negotiation [RFC4306].
INTEGRITY_SHA1 (0x1)
INTEGRITY_SHA_256 (0x2)
EncryptionMethod4Encryption algorithm to be negotiated during MM SA negotiation [RFC4306].
CIPHER_AES_128 (0x2)
CIPHER_AES_256 (0x4)
CipherTransformConstant5Encryption algorithm to be negotiated during QM SA negotiation [RFC4306].
(0x3) CIPHER_CONFIG_CBC_AES_128
(0x5) CIPHER_CONFIG_CBC_AES_256
AuthTransformConstant1Specifies the hash algorithm to be negotiated during QM SA negotiation [RFC4306].
AUTH_CONFIG_HMAC_SHA_1_96 (0x1)
HMAC secret key authentication algorithm. SHA-1 (Secure Hash Algorithm) data integrity and data origin authentication algorithm. [RFC2404].
AUTH_CONFIG_HMAC_SHA_256_128 (0x2).
HMAC secret key authentication algorithm. SHA-256 data integrity and data origin authentication algorithm.
DHGroup3Type of Diffie-Hellman group used for Internet Key Exchange (IKE) key generation during MM SA negotiation [RFC4306].
DH_GROUP_2 (0x2)
DH_GROUP_14 (0x3)
DH_GROUP_2048 (0x3) - IKE for DH-14. Name change to match standard terminology
PfsGroup0Diffie-Hellman algorithm to be used for Quick Mode Perfect Forward Secrecy (PFS) [RFC4306].
PFS_NONE (0x0)
PFS_2 (0x2)
PFS_2048 (i.e., DH-14) (0x3)
PFS_MM (0x6) - Uses same DH as MM that contains this QM.
Note: DWORD values for IKEv2 Custom Policy Key: HKLM\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\IKEV2\IKEv2CustomPolicy\
This method also supports stronger security (e.g., DH-EC and GCM).  See MSDN MS-RRASM for additional options.

Additional Thoughts:

Client Requirements:

VPN clients must support the same cryptography in order to connect.  Consider how Windows clients use DH2-3DES-SHA1 by default (yikes).  I'll provide instructions on how to update Windows 10, iPhones, and Android IPsec clients in an upcoming article.

PowerShell:

PowerShell can implement stronger IKEv2 secuirty targets for both Windows 8.1 and 2012R2:

New-NetIPsecMainModeCryptoProposal -Encryption AES256127 -Hash SHA256 -KeyExchange DH19
Be warned, the process is challenging.  If you go this route don't test it out on production servers.  Also, the TechNet examples create new GPO policy specific to IKEv2.  It does not account for all the other firewall rules.  In other words, it creates a new firewall policy that only permits IKEv2 traffic -it's easy to get locked out without console access.  

The trick is to copy ALL firewalls rules and IPsec rules, crypto-sets, and IPsec rules (and anything else I haven't thought of) to the new GPO -all through PowerShell.  Alternately, use the GUI to copy the existing firewall settings to a separate firewall policy (i.e., separate from the PowerShell IKEv2 GPO).  Do not use the GPO GUI to edit the IKEv2 (i.e., PowerShell) firewall or you risk corrupting it.   You can then apply both GPOs to the VPN server.     

Also, we may be able to accomplish the same thing by saving the object to the local policy store.  Don't take my word on this because I haven't tried it yet.  So yeah, this is a bit more work but the benefits should provide solid security and greater interoperability.   

If anyone completes this script before I get around to it please forward me your work!  Either way, I'm sure it will be good material for another blog article.

That's it!  

References:

https://msdn.microsoft.com/en-us/library/hh536658.aspx
https://technet.microsoft.com/en-us/library/jj573824(v=wps.630).aspx
https://technet.microsoft.com/en-us/library/jj554897(v=wps.630).aspx


11 Comments

  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?

    ReplyDelete
    Replies
    1. Yes, this is a limitation (or strength). It prevents the use of weak cryptographic algorithms.
      For your situation, I suggest using dynamic site-to-site VPNs. You can define a different cipher-suite for every S2S interface. You can then assign S2S interfaces to specific clients. S2S VPNs work alongside RRAS remote access client VPNs: http://www.stevenjordan.net/2016/11/dynamic-s2s-vpns.html

      Delete
  2. Hi Steven. I know this is an old post. Hope you reply.
    There is "IPsec Settings" in "Windows Firewall with Advanced Security", I tried to set the above parameters in there instead of registry but it didn't work. Why?

    ReplyDelete
  3. It probably doesn't work because IPSec policies, in the Windows Firewall GUI, only apply to IKEv1 -not IKEv2. N.B., IPsec firewall policy will affect L2TP VPNs. That's only because L2TP and Win Firewall use the same flavor of IPsec (v1).

    The absolute easiest way to improve IPsec in Windows is with the NegotiateDH2048_AES256 regedit. Instructions are found here:

    http://www.stevenjordan.net/2016/09/secure-ikev2-win-10.html

    This registry change provides acceptable security: DH14-AES1288-SHA1. It works for both IKEv1 (Win Firewall and L2TP) and IKEv2 VPNs. It also works for both clients and servers.

    The only limitation is that it prevents stronger cryptography. Nonetheless, it's a MUCH better option than doing nothing.

    ReplyDelete
    Replies
    1. Thanks. One more question. For Integrity Method you choose SHA-1. Why not SHA-256?

      Delete
    2. By all means, choose the highest encryption levels that your hardware (i.e., servers and clients) supports. The only caveat is the highest encryption and hashing levels limit the number and types of devices that can connect.

      For example, the very first comment describes how their client was unable to connect after they implemented stronger security measures. Their old Windows phone simply could not connect to the server via DH14-AES256-SHA256. N.B., Neither can iPhone 6 or iPhone 7.

      In a perfect world, we implement a policy that prevents insecure devices altogether. In the real world, we support Windows laptops, Android phones, iPhones, Chromebooks, etc.. Each device has different encryption and hashing limitations. However, in my experience most devices support MM:IKE-DH14-AES256-SHA1 and QM: AES128-SHA1.

      Delete
  4. Hi Steven, I've installed a RRAS (Win2016) for IKEv2 VPN clients. Authentication is based on machine certificates. Clients are able to connect without any problem. If I revoke the computer certificate on the internal CA, the computer is still able to connect. I've published a new CRL, and comfirmed the revoked cert is on the list. Do you know I to enable revocation checking on the RRAS server?

    ReplyDelete
    Replies
    1. I suspect RRAS uses a cached CRL. The server stores this cache until it expires. This interval is determined by the CA.

      By default, the CRL interval is set for one week. The delta (i.e., short-term updates) interval is set for one day.

      Edit CRL intervals: Certificate MMC > Sever > Revoked Certificates > Properties.

      Note, short CRL intervals can generate a lot of traffic. I suggest you shorten the delta interval before the CRL.

      Also, make sure the delta location is published along with CRL: CA MMC > Server > Properties > Extensions.

      Without any changes, I expect things should work within one day. Of course, if this were an emergency you'd need an immediate way to delete the CRL cache:

      (a) Stop all related RRAS & IIS services.
      (b) certutil -setreg chain\ChainCacheResyncFiletime @now
      (c) Restart all services.

      Note: CRL cache resides in memory and disk. The above command may not clear the cache from memory if another application has it in use. If you run into trouble you can try the following:

      (a) Disable the network connection.
      (b) Restart the server.
      (c) Log on as a local administrator.
      (d) certutil -setreg chain\ChainCacheResyncFiletime @now
      (e) Enable network. Restart.

      Finally, I believe renewing the certificate also update the CRL cache:

      MMC > Certificates (Computer) > Personal > Server-Certificate > Renew certificate with the same key.

      Delete
  5. Hello Steven,
    Thank you for sharing this article.

    I've setup two Windows 2012 R2 servers and made the suggested registry changes. However the servers are still using DH2-3DES-SHA1.

    Is there anything else I could check?

    Thank you
    Bob

    ReplyDelete
    Replies
    1. I suggest you try the NegotiateDH2048_AES256 registry hack. It only offers two options: DH14-AES256-SHA1 or DH14-AES256-SHA256. Implement the change on both server and client. Instructions:

      http://www.stevenjordan.net/2016/09/secure-ikev2-win-10.html

      Delete
    2. That worked!
      Thank you again.

      Bob

      Delete

My Instagram