When 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
This can also be confirmed by viewing a network trace as shown here.
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
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
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
Tim
/ December 10, 2018Thanks Richard, I cannot wait to test these settings. I’ll report back and let you know once I have had the chance!
Tauno Vürmer
/ December 10, 2018How can i verify on client that it is using 3DES? Is there powershell command to see it?
Richard M. Hicks
/ December 10, 2018No command that I’m aware of to see it. You’ll have to take a network trace of the IKEv2 connection to see it. You’ll find that the Windows 10 clients submits 18 different IKE proposals, none of which use anything larger than DH Group 2 (1024-bit) keys. :/ In my testing I observed that when a Windows 10 client connects to a Windows Server running RRAS they always negotiate 3DES/SHA-1/DH2, by default. 🙁
Marko
/ December 11, 2018“Get-NetIPsecMainModeSA” on Windows 10 client should show that info.
CipherAlgorithm: DES3
HashAlgorithm: SHA1
GroupId: DH2
KeyModule: IkeV2
Richard M. Hicks
/ December 11, 2018Thanks! 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, 2018Once 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?
Richard M. Hicks
/ December 11, 2018Oh 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! 🙂
Colin
/ December 10, 2018Worth noting, in my testing anyway, that the VPN profile CryptographySuite blob needs to be directly under . I tried it above and it failed.
Colin
/ December 10, 2018Looks like my post had code wordpress didn’t like. It needs to be directly under NativeProfile. I tried it under Authentication and it failed.
Richard M. Hicks
/ December 10, 2018Correct. As long as the CryptographySuite element is nested between the NativeProfile elements you’re good. 🙂
Tim
/ February 25, 2019I 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?
Richard M. Hicks
/ February 26, 2019It 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.
Colin
/ December 10, 2018Richard, to use AES256, would it be to simpley replace the two client side AES128 enrties and the two server side AES128 entries with AES256?
Richard M. Hicks
/ December 10, 2018Correct. You can reference the VPNv2/ProfileName/NativeProfile/CryptographySuite element details in the VPNv2 CSP here: https://docs.microsoft.com/en-us/windows/client-management/mdm/vpnv2-csp. Be sure to use the exact syntax as defined in the CSP! Some of the GCM suites have underscores, others don’t. 😉
Colin
/ December 10, 2018Interesting. 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?
Colin
/ December 10, 2018I rebooted the server and it passes traffic now. *shrug*
timbo01
/ December 11, 2018I 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.
Richard M. Hicks
/ December 11, 2018That’s not been my experience and I’ve done extensive testing with this. If it doesn’t though, restarting always works. 🙂
Chris
/ December 11, 2018Hi Richard
Thanks for the post
When we set this on the RASS servers, as clients not matching the new IKEv2 security won’t be able to connect, am I right to assume if we hit any issues, we can run “Set-VpnServerIPsecConfiguration -RevertToDefault” on the RASS server to revert back? After a service re-start
Also, our internal CA is on running an OS of Server 2008 R2 are we OK implementing the updated IKEv2 security when running an older internal CA
Thanks for all you posts on Always ON VPN they have been a great help 😊
Chris
/ December 11, 2018Sorry Richard just to clarify to revert back on the RASS Server “Set-VpnServerConfiguration -RevertToDefault” and on the end client “Set-VpnServerIPsecConfiguration -RevertToDefault” Thanks again
Richard M. Hicks
/ December 11, 2018Yes, you can use -RevertToDefault to restore the default settings. Thanks for bringing that up. I’ll be sure to update the post with that information. You shouldn’t have a problem with your old CA as long as it is using at least SHA-1 and 2048 bit RSA keys.
Chris
/ January 4, 2019Hi Richard that’s great thanks for the reply 🙂
Tom
/ May 18, 2021I 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.
Richard M. Hicks
/ May 18, 2021Absolutely. IPsec will work with RSA and SHA-1 as long as you configure the same settings on the client. 🙂
Colin
/ December 11, 2018I 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?
Richard M. Hicks
/ December 11, 2018Unusual 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.
Colin
/ December 11, 2018This may have been resolved by adding a Start-Sleep 15 seconds in the profile script prior to executing the IKEv2 policy command
Colin
/ January 10, 2019Richard, what are possible solutions to computers with device tunnels that are in the possession of a terminated employee?
I assume because the user tunnel uses NPS it can just be removed from a group and lose access. But what about the device?
Let’s say a device tunnel exists on a computer that a current employee has possession of and they work 100% remotely. That employee is terminated and their user is removed from the group for AOVPN but they still have possession of the device.
Wont that device connect to the company network and have access to whatever that device profile allowed indefinitely? Am I missing something?
Colin
/ January 10, 2019I suppose this would come down to a publicly accessible CRL and a process to manually revoke the computers certificate?
Richard M. Hicks
/ January 10, 2019Correct. 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, 2019Can the CRL lifetime be changed on certs that are already issued? This sounds like a pretty crappy scenario for companies.
Richard M. Hicks
/ January 12, 2019The 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, 2019I 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.
Richard M. Hicks
/ January 12, 2019Agreed, 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, 2019You 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.
Richard M. Hicks
/ March 25, 2019Most interesting. I’ll have to test this out soon. 🙂
Colin
/ March 25, 2019This 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.
Richard M. Hicks
/ March 25, 2019Revoking certificates will most certainly be delayed, the length of which would depend on how the CRLs are configured in your organization.
Erin Mc
/ May 6, 2019I’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?
Richard M. Hicks
/ May 8, 2019That’s unusual. Disabling 3DES for SSL/TLS should have no effect on IKEv2, especially if you’ve configured VPN to use AES.
erinmcdonald123
/ May 6, 2019I’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?
Steve C
/ January 18, 2020I 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
Steve C
/ January 20, 2020I 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, 2021Steve, 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, 2021Hi 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/
Nils
/ July 25, 2019Strange. 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.
Richard M. Hicks
/ July 25, 2019If you’ve configured both sides identically that would be unusual to get policy mismatch error. I’d suggest taking a network trace on the client to see what’s up. That should give you an idea why the connection is failing.
victor bassey
/ September 27, 2019this is exactly my experience. both server and client has been configured with the scripts from this page
Colin
/ August 7, 2019Richard,
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.
Richard M. Hicks
/ August 13, 201913868 is definitely an IKEv2 policy mismatch error. Either the policy changed on the client or the server. 🙂 I’d have a close look at both of those and see what’s up.
Colin
/ August 13, 2019If that is the case, why do device tunnels work fine? Interesting. I will dig deeper.
Richard M. Hicks
/ August 13, 2019Have 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, 2019The funny thing is it used to work and the server and profiles have not been modified.
Richard M. Hicks
/ August 13, 2019Very strange! Let me know what you find out. 🙂
Colin
/ August 14, 2019The 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, 2019Do 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.
Richard M. Hicks
/ August 15, 2019Sadly, 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. :/
Richard M. Hicks
/ August 15, 2019Upon further review…this information is actually easy to find using PowerShell. 🙂
Get-VpnConnection -Name ‘Foo’ | Select-Object -ExpandProperty IPsecCustomPolicy
Enjoy!
Colin
/ August 16, 2019Perfect! Thanks!
Colin
/ August 16, 2019All 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.
Daniel K.
/ September 3, 2019Any 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?
Richard M. Hicks
/ September 10, 2019If you’re not using Intune you’re in a tough spot, for sure. You’re right, once you change the settings on the server it will immediately disconnect all users. No problem with Intune, as the client settings will be updated out-of-band and they’ll reconnect once they receive those new settings. If you’re deploying the settings manually you’ll have to touch each one of those clients again, unfortunately.
Colin
/ September 10, 2019Microsoft 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?
Richard M. Hicks
/ September 12, 2019Indeed. 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, 2019Do I still need device tunnel if I’m going to be managing VPN clients via intune?
Richard M. Hicks
/ November 1, 2019That 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, 2019Thanks Richard that makes sense.
victor bassey
/ September 27, 2019What 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
Richard M. Hicks
/ October 7, 2019I don’t see anything specifically wrong here. If you’re still trying to sort this out, drop me a note directly and I’ll have you send me some additional information.
Victor
/ October 11, 2019Thanks 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.
Richard M. Hicks
/ October 11, 2019Ok, good to know!
Michael Leeming
/ October 29, 2019What 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?
Michael Leeming
/ October 29, 2019We 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)
Richard M. Hicks
/ October 30, 2019Hopefully 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.
Richard M. Hicks
/ October 30, 2019I typically use 28800 (8 hours) for the SALifeTime value. I leave the SADataSizeForRenegotation at 102400 (100 MB).
Michael Leeming
/ October 31, 2019Hi 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)
Richard M. Hicks
/ November 1, 2019Thanks 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.
John Garrity
/ November 6, 2019Hi 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?
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.
Richard M. Hicks
/ November 10, 2019Good to know!
Richard M. Hicks
/ November 10, 2019When 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!
Mark H
/ January 7, 2020Thanks 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?
Richard M. Hicks
/ January 8, 2020Yes, 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.
victor Bassey
/ January 11, 2020Hello 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,
Richard M. Hicks
/ January 13, 2020Good point. Best to stick with RSA certificates for user authentication so you can take advantage of TPM. 🙂
Mark H
/ January 21, 2020Thanks all. BTW this issue came about as I was helping a customer meet the (UK) NCSC guidelines for AlwaysOn VPN. Interesting point re: TPM Key Attestation & needing the RSA option. That is confirmed here – https://docs.microsoft.com/en-gb/windows-server/identity/ad-ds/manage/component-updates/tpm-key-attestation?redirectedfrom=MSDN. I expect we may just have to have devices enrolling for multiple certificates which, as far as I can tell, doesn’t appear to cause issues. My test clients had multiple old and new certs, and behaved fine.
Some Guy
/ March 13, 2020This 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).
Richard M. Hicks
/ March 18, 2020I 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!
Zerqent
/ October 8, 2020Hello. Richard. Thanks for all the great information for Always on VPN.
You are saying “Microsoft did not support the use of GCM for encryption with RSA until Windows Server 1803”. Not that I do not believe you – but do you have any reference for this, as I am unable to dig anything up – and working with that kind of customer.
Cheers!
Richard M. Hicks
/ October 16, 2020Normally it would be documented here: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd125380(v=ws.10). However, this document is sadly out of date. I’ve asked Microsoft if they have anything published they can share. Haven’t heard back yet though. :/
Andy
/ April 17, 2020Thought 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.
Andy
/ April 17, 2020Sorry original post striped out some XML.
The CryptographySuite elements are not applied when NativeProtocolType is set to Automatic.
Richard M. Hicks
/ April 17, 2020This is a known issue. Details here: https://directaccess.richardhicks.com/2019/01/07/always-on-vpn-ikev2-connection-failure-error-code-800/.
This issue is still unresolved by Microsoft today. The workaround is to configure the profile to use IKEv2 (instead of automatic) and then change this later by updating the VpnStrategy entry in rasphone.pbk. A PowerShell script to update the rasphone configuration file can be found here: https://github.com/richardhicks/aovpn/blob/master/Update-Rasphone.ps1.
Alex M
/ May 12, 2020Hi 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.
Richard M. Hicks
/ May 14, 2020You 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.
Alex M
/ May 14, 2020Thanks 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.
Richard M. Hicks
/ May 14, 2020Interesting. 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.
Ankur
/ June 3, 2020Hi 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
Richard M. Hicks
/ June 4, 2020I 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.
Ankur
/ June 4, 2020Thanks 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
Richard M. Hicks
/ June 8, 2020I’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.
urs egli
/ June 9, 2020Is DH Group 21 supported, as a customr would like to use that? Are there any drawbacks to use DH21?
Richard M. Hicks
/ June 9, 2020I 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.
bueschu
/ June 9, 2020Is DH Group 21 supported and are there any drawbacks using it. A customer whises to use DH 21.
Many thannks
Richard M. Hicks
/ June 9, 2020I 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.
bueschu
/ June 9, 2020Many 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
Richard M. Hicks
/ June 10, 2020Not at the moment. Considering it though. Might have something late this year, you never know. 🙂
fabioandreteles
/ June 18, 2020Hello 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!
Richard M. Hicks
/ June 18, 2020If 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/.
Fabio Teles
/ June 19, 2020Hello 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!
Richard M. Hicks
/ June 22, 2020I’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. 🙂
fabioandreteles
/ June 22, 2020Thank 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!
Richard M. Hicks
/ June 22, 2020My pleasure! 🙂
fabioandreteles
/ June 25, 2020Sorry 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.
Richard M. Hicks
/ June 29, 2020Disabling 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.
fabioandreteles
/ June 29, 2020Hello 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.
Richard M. Hicks
/ June 29, 2020I 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.
Rob M
/ June 23, 2020Hi 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.
Richard M. Hicks
/ June 23, 2020Not 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.
Shaun Danz
/ June 30, 2020I 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?
Richard M. Hicks
/ July 1, 2020Different 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?
TB
/ July 29, 2020Hello, 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!
Richard M. Hicks
/ July 29, 2020Not 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.
Nat Hazlett
/ October 27, 2020Hi 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
Richard M. Hicks
/ October 27, 2020Indeed, that is quite maddening for sure! Why the syntax change I have no idea! 🙂
Urs Egli
/ November 18, 2020We 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?
Richard M. Hicks
/ November 24, 2020These 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.
Urs Egli
/ November 24, 2020Does 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
Richard M. Hicks
/ November 30, 2020You 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.
Urs Egli
/ December 7, 2020Many Thanks for your help and the fantastic blog
Best regards – urs egli
Richard M. Hicks
/ December 7, 2020My pleasure!
Andrew
/ January 4, 2021Hi 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
Richard M. Hicks
/ January 6, 2021That’s really strange. No idea what could be causing that. :/
andrew
/ January 7, 2021Many thanks, It turned out to be ESP was blocked on a router incoming everything works a perfectly now
James A
/ January 10, 2021I’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.
Richard M. Hicks
/ January 18, 2021It might be worth deleting the connection completely and trying again. Use this script to remove it completely. It also deletes some of the artifacts that get left behind, which can cause problems. 🙂
https://github.com/richardhicks/aovpn/blob/master/Remove-AovpnConnection.ps1
VBSingh
/ January 19, 2021Hi 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.
Richard M. Hicks
/ January 21, 2021Have a look at this: https://github.com/richardhicks/aovpn/blob/master/Remove-VpnConnections.ps1. 🙂
Shaun Danz
/ January 23, 2021The RemoveVPNConnections script was exactly what I was looking for.
Jonatan Kragh Hovgaard
/ January 25, 2021I 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?
Richard M. Hicks
/ January 26, 2021Yes, this is a known issue with Microsoft Windows 10 that hasn’t yet been resolved by Microsoft. Details here: https://directaccess.richardhicks.com/2019/01/07/always-on-vpn-ikev2-connection-failure-error-code-800/.
Fabio
/ January 27, 2021Hello 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!
Richard M. Hicks
/ January 27, 2021For 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.
fabioandreteles
/ February 4, 2021Thank 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!
Richard M. Hicks
/ February 5, 2021Not 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. 🙂
fabioandreteles
/ February 8, 2021Thank 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!
Richard M. Hicks
/ February 10, 2021Sweet! Glad it worked out for you! 🙂
DLH
/ January 29, 2021I’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?
Richard M. Hicks
/ January 29, 2021That’s surprising. Can you reach out to me directly so we can talk in more detail please?
DLH
/ February 4, 2021I sent a message through your contact form a few days ago. Let me know if you didn’t receive it.
Richard M. Hicks
/ February 5, 2021Received. Thanks!
Kieran
/ February 28, 2021We 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?
Richard M. Hicks
/ March 1, 2021Not 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.
Ludde
/ March 3, 2021Hi! 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?
Richard M. Hicks
/ March 3, 2021You 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.
Bob Clark
/ April 13, 2021Our 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??
Richard M. Hicks
/ April 13, 2021You should always define the root CA here.
Simon Knaggs
/ May 9, 2021Hi 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.
Richard M. Hicks
/ May 14, 2021Thanks 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!
davidwinslow
/ May 12, 2021First – 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.
Richard M. Hicks
/ May 14, 2021That’s correct. One of the user authentication protocols must be “certificate” in order to configure those additional parameters such as root certificate to accept.
Q
/ May 27, 2021Is 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?
Richard M. Hicks
/ May 27, 2021Absolutely. You can (and should!) define your root CA for IPsec using Set-VpnAuthProtocol -RootCertificateNameToAccept. Enforcing CRL checks involves setting a registry key, and possibly installing an update. Details here: https://directaccess.richardhicks.com/2019/06/20/always-on-vpn-device-tunnel-and-certificate-revocation/.
Chris
/ May 4, 2022Can you also use multiple Root Certs for Set-VpnAuthProtocol? If so do you know how?
Richard M. Hicks
/ May 5, 2022No. It will only accept a single root CA certificate.
Matthias
/ June 17, 2021I 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?
Richard M. Hicks
/ June 17, 2021The 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. 🙂
Matthias
/ June 18, 2021Sadly 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?
Richard M. Hicks
/ June 18, 2021If 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, 2021sorry, 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.
Richard M. Hicks
/ June 18, 2021Did 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, 2021We`ve disabled basic and strong (but not strongest). Tried to activate basic + strong. But same result. Think i give up on this
Richard M. Hicks
/ June 22, 2021Try 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.
Chris
/ July 2, 2021Hi 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.
Richard M. Hicks
/ July 6, 2021You 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.
Carmen D.
/ July 21, 2021Hi 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!
Richard M. Hicks
/ July 21, 2021It 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. 🙂
Carmen D.
/ July 23, 2021Richard,
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 !
Richard M. Hicks
/ July 23, 2021Great to hear. Enjoy! 🙂
Dave
/ July 28, 2021Thanks 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.
Richard M. Hicks
/ July 29, 2021Great! Cheers to you as well! 🙂
John D.
/ October 30, 2021Thanks, by updating to AES256 I was able to get a MAC IKEv2 VPN connected however we’re having a problem were the the MAC VPN disconnects exactly at 8 minutes. Any ideas?
Policy that we used to get the MAC IKEv2 VPN connected.
Set-VpnServerConfiguration -CustomPolicy -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES256 -DHGroup Group14 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -PFSgroup PFS2048 -SALifeTimeSeconds 28800 -MMSALifeTimeSeconds 86400 -SADataSizeForRenegotiationKilobytes 1024000
Richard M. Hicks
/ November 2, 2021No idea. Is there any timeout settings on the MAC VPN client that you can adjust?
John D.
/ November 2, 2021Unfortunately none that I’m aware of. The macOS GUI doesn’t have any settings that you can change at all. We have also narrowed the problem to the Monterey macOS. iPhone and PC do not disconnect but our sample size is small.
John D.
/ February 19, 2022Turns out that the mac OS does NOT appear to support PFS so you have to turn that off. Issues have been resolved with this policy:
Set-VpnServerConfiguration -CustomPolicy -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES256 -DHGroup Group14 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -PFSgroup None -SALifeTimeSeconds 28800 -MMSALifeTimeSeconds 86400 -SADataSizeForRenegotiationKilobytes 1024000
Richard M. Hicks
/ February 22, 2022Good to know. Thanks for the update!
bueschu
/ January 18, 2022If we use DH group 20 are we forced to use an ECC384 certificate or can we also use an ECC 256 certificate – I know strange question.
Richard M. Hicks
/ January 20, 2022Yes, you can. 🙂
bueschu
/ January 20, 2022Thank you for the answer and the very helpfull blog.
Richard M. Hicks
/ January 21, 2022My pleasure! 🙂
bueschu
/ February 2, 2022Just for information. We had to use an ECDSA_384 Certificate when using DHGroup20. After implementing and activating an ECDSA_256 certificate on the VPN-Server everything worked fine, till the ECDSA_384 certificate expired. This certificate was still in the store, but not activated on the RAS Server. So VPN connections with IKEv2 (DHGroup) and ECDSA_256 Certificate was working fine and we were conviced it would stay that way. And then the old certificate expired….
Simon
/ January 25, 2022The command Set-VpnAuthProtocol -RootCertificateNameToAccept $RootCACert -Pass Thru ONLY works IF you have Allow Machine Certificate authentication for Ikev2 set in the RRAS Security TAB authentication methods.
If you are ONLY using EAP and NPS the command won’t work but returns The Parameter is Incorrect
Question Is this a BUG or by design (RRAS on server 2019)
Richard M. Hicks
/ January 25, 2022This is by design. The -RootCertificateNameToAccept option only applies to IKEv2 when using device certificate authentication. So, if ‘Certificate’ authentication isn’t enabled there’s no need to enable this setting.
Seiji
/ February 24, 2022Thank you for all those good articles Richard. Just one question/topic:
As mentioned, setting the security configuration in the XML via is only possible when the is set to IKEv2. If the tunnel type is set to Automatic, the settings are ignored and the default security settings are applied.
This is fine for a device tunnel, as this is IKEv2 only. But how about a user tunnel? We want to have the user tunnel set to Automatic, so that fallback to SSTP is possible. This works fine, if the tunnel is deployed and afterwards Set-VpnConnectionIPsecConfiguration is used. Then we have a VPN tunnel, that has the IKEv2 custom configuration but can also use SSTP.
Any idea how to do achieve that in a script that runs in system context?
Richard M. Hicks
/ March 1, 2022First, ‘Automatic’ prefers SSTP, but will fall back to IKEv2. If you want IKEv2 with SSTP fallback, I would suggest deploying the profile as IKEv2, then updating the VpnStrategy setting in rasphone.pbk to ’14’ after provisioning. When you do this, SSTP will be preferred but the custom cryptography settings will still be honored.
Mikael
/ March 12, 2022I’m experiencing some strange behavior with some SSTP connections, and can’t figure out why its not working. So I’m reaching out and looking for some troubleshooting help.
I’ve setup authentication to use User – PEAP – Certificate.
The scenario is:
Im testing SSTP connections with 3 user accounts on the same win10 client, 2 users can connect with SSTP while ONE user cannot.
The faulting user is actually successfully authenticated at NPS.
Im getting the following 2 errors on the VPN server each time the connection fails:
—
CoId={}:The initial Secure Socket Tunneling Protocol request could not be successfully sent to the server. This can be due to network connectivity issues or certificate (trust) issues. The detailed error message is provided below. Correct the problem and try again.
The parameter is incorrect.
—
CoId={25D634F0-3658-0001-8C5E-D6255836D801}: The Remote Access Server’s attempt to callback user [email protected] on port VPN1-1020 at 46703907448 failed because of the following error: The parameter is incorrect.
—
The client reports a timeout error, rasclient error code 638.
Looking at a wireshark capture I see client&server hellos, client requests a cipher change and it is ACK’ed, then some application data being sent back and forth, but then the client sends a reset packet within 0.4seconds.
Don’t really know why or how to interpret it, I’m novice at reading packets.
—-
Other notes:
The user that cannot connect to SSTP CAN connect with IKEv2 just fine.
I’ve tried netsh reset ip/winsock.
Deleted user certificate, auto-enroll brings back a new one.
Deleted the VPN to have it auto-deployed back.
Uninstalled all of the WAN Miniports.
I’ve ran the Optimize-VpnServerTlsConfiguration.ps1 script, tried both security and and scalability settings.
The public HTTPS endpoint has “A” class security, checked with SSL Labs.
Any ideas?
Richard M. Hicks
/ March 13, 2022Very strange! It doesn’t sound like a communication issue because you said you observed the TLS handshake. Have you tried deleting the user profile entirely? I’m wondering if it is a corrupt user profile somehow. Can the user connect on another device?
Mikael
/ March 13, 2022Hi Richard,
I found the solution to my problem just a few hours ago but couldn’t find my comment to answer it myself, so thank you for replying to it.
The AD user’s Dial-in option to “Always call back to….” was enabled and thats why it wasn’t connecting. Apparently this only affects SSTP and not IKEv2.
After setting it to No callback the user was able to connect just fine.
Also much appreciated for all of the documentation you’ve assembled on here, it has helped me a ton!
Richard M. Hicks
/ March 15, 2022Thanks for the update. Glad you got it sorted out!
bueschu
/ February 20, 2023We have problems with IKEv2 and CGNAT also known as CGN or large -scale NAT (LSN). VPN does work with sstp but not with IKEv2. Is there any workaround for IKEv2 with CGNAT otherwise we had to disable the IKEv2 protocol
Richard M. Hicks
/ February 27, 2023Although you can’t fix this completely, there are a few things you can do that might help. First, disable IKE mobility on the VPN client. Also, ensure your IPsec SA parameters on the RRAS server are set to their values to the lowest settings (idle timeout = 5, network outage time – 2). In addition, add the following registry key to your RRAS server.
HKLM\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters\IkeNumEstablishedForInitialQuery DWORD = 50000
Finally, make sure your edge firewall and/or load balancer is passing the client’s original source IP address to the RRAS server.
Hope that helps!
bueschu
/ February 27, 2023Thank you for the support
Richard M. Hicks
/ February 28, 2023My pleasure!
bueschu
/ May 14, 2023You helped mit with an AoV configuration using DHGroup ECP384, which was a requirement from a customer. Everything worked fine using User Tunnel with Ikev2. Now when trying configuring device tunnel with machine certificate authentication the authentication does not work. We get the error 13806 on the client, saying there is no certificate. When using DHGroup 14 everything works just fine.
Can you give me an advice using ECP384 and machine certificates?
Richard M. Hicks
/ May 15, 2023For the device tunnel, you must issue EC certificates to both the VPN server and the device. Don’t forget to include the ‘IP security IKE intermediate’ EKU on the VPN server’s certificate. Once that’s done you’ll also need to update the cryptography settings the server and client to use ECP384 instead of RSA.
Let me know how it goes!
bueschu
/ May 16, 2023This means we have to build a new or additional CA for issuing EC Certificates?
Richard M. Hicks
/ May 16, 2023Not necessarily. You can issue a certificate with an EC key from a CA with an RSA key. However, you might need a full EC chain for compliance reasons.
bueschu
/ May 17, 2023I asked Bing (ChatGPT) how to setup two chains or in our case one addtional chan for CNG Keys- Is this approach ok?
Here are the steps to set up two certificate chains in an enterprise CA with RSA and CNG keys:
Create two certificate templates for the RSA and CNG certificates.
Create two certificate authorities (CA) for the RSA and CNG certificates.
Issue a root CA certificate for each of the RSA and CNG CAs.
Issue an intermediate CA certificate for each of the RSA and CNG CAs.
Issue an end-entity RSA certificate from the RSA CA.
Issue an end-entity CNG certificate from the CNG CA.
The root CA certificates should be installed on all computers that will trust the certificates issued by the enterprise CA1.
Richard M. Hicks
/ May 17, 2023Configuring PKI for Suite B is a little more complicated than that. Unfortunately, the link to the Microsoft guidance for this no longer works. :/ If you reach out to me directly via email I’ll share a copy with you.
bueschu
/ May 18, 2023Thanks for your help but can’t find you email address.
Richard M. Hicks
/ May 19, 2023https://directaccess.richardhicks.com/contact/
Zack
/ November 8, 2023We’re looking to set these settings through intune for VPN Server 2022 and Windows 11 clients. This article is fairly old, do you still recommend the same encryption settings?
Richard M. Hicks
/ November 8, 2023Actually, no. 🙂 Now that we’re way past Windows 10 1803 and Windows Server 2019 we can use the following settings.
Set-VpnConnectionIPsecConfiguration -ConnectionName $connection -AuthenticationTransformConstants GCMAES128 -CipherTransformConstants GCMAES128 -DHGroup Group14 -EncryptionMethod GCMAES128 -IntegrityCheckMethod SHA256 -PFSgroup ECP256 -Force
I’ll update the blog post to reflect these changes soon. 🙂