Always On VPN administrators may encounter a scenario in which Windows 10 clients are unable to establish an IKEv2 VPN connection to a Windows Server Routing and Remote Access Service (RRAS) server or a third-party VPN device under the following conditions.
- The VPN connection is configured using ProfileXML.
- ProfileXML includes the <CryptographySuite> element.
- The VPN server is configured to use a custom IPsec policy.
- The VPN server supports only IKEv2.
- The <NativeProtocolType> in ProfileXML is set to Automatic.
When these specific conditions are met, the client will be unable to connect to the VPN server using IKEv2. The error message states:
The remote connection was not made because the attempted VPN tunnels failed. The VPN server might be unreachable. If this connection is attempting to use an L2TP/IPsec tunnel, the security parameters required for IPsec negotiation might not be configured properly.
In addition, the event log will include an error message from the RasClient source with event ID 20227 that includes the following error message.
The user [username] dialed a connection named [connection name] which has failed. The error code returned on failure is 800.
A manually configured VPN connection using IKEv2 will connect successfully under these same conditions, however.
IKEv2 Error Code 800
Error code 800 translates to ERROR_AUTOMATIC_VPN_FAILED, which is somewhat ambiguous. The error description is:
Unable to establish the VPN connection. The VPN server may be unreachable, or security parameters may not be configured properly for this connection.
Digging Deeper
A network trace of the IKEv2 VPN connection reveals the true source of the problem, which is a failure of the client and server to successfully negotiate an IKEv2 security association (SA). During the SA initiation process, the parameters offered by the client are unacceptable to the server, resulting in a NO_PROPOSAL_CHOSEN notification being returned by the server.
Custom Cryptography Settings Ignored
It appears that the Always On VPN connection ignores the custom cryptography settings defined in the CryptographySuite element in ProfileXML. However, this only occurs when the NativeProtocolType is set to Automatic. Presumably, this is a bug. 🙂
Workaround
As a workaround, set the NativeProtocolType to IKEv2. When NativeProtocolType is set to IKEv2, the VPN connection recognizes the IKEv2 parameters defined in the CryptographySuite element and the VPN connection will be established successfully.
Additional Information
Always On VPN IKEv2 Security Configuration
Always On VPN Certificate Requirements for IKEv2
Always On VPN IKEv2 Load Balancing with the KEMP LoadMaster Load Balancer
Flo
/ January 24, 2019Hey Richard.
Nice Article, thx
Hoe do you trace ipsec „adapters“ on windows?
Richard M. Hicks
/ January 24, 2019Depends. If I’m interested in seeing the tunnel connection itself I capture on the interface using Wireshark, Network Monitor, or netsh. If I want to see *inside* the encrypted tunnel (traffic going through the VPN) then I use Microsoft Message Analyzer.
Andreas
/ March 7, 2019Hi Richard, thanks for your great blog.
I’ve a general question to you. Could it be that the always on VPN is more buggy with Windows 1803/1809? We started with Windows 10 1709 and the always on VPN experiance was awesome. Today our company use Windows 10 1803 and we have problems over problems with this VPN solution. Example: Microsoft didn’t fix the bug that you can’t start the vpn from Taskbar -> VPN. If you go to Settings -> VPN and press connect it works.
Richard M. Hicks
/ March 8, 2019I can’t argue with your experience, but generally speaking it seems to be getting better with each new release. Also, Microsoft just released some important updates for Always On VPN in Windows 10 1803 and 1809. I’ll be posting something about that next week. I’d suggest installing the latest updates and see if things get any better for you.
Regarding the UI behavior, I would agree it is annoying that you can’t launch some VPN connections (those that use a plug-in provider) without having to open another window and click on something else. They could definitely streamline that, for sure. 🙂
Andreas
/ March 11, 2019Then I am reassured that you have made good experiences with the product.
We have installed the latest updates. I read your post about fragmantation yesterday. That’s a point we could figure out if this had something to do with our problems.
Thanks a lot for your great blog and work for the community.
Richard M. Hicks
/ March 12, 2019My pleasure!
Georg
/ August 27, 2019Hi Richard, is this Bug in all Win10 Version? I just did a test with 1809 and get exact this behavior. Is this fixed in 1903?
Richard M. Hicks
/ August 27, 2019Yes, it is. Still not fixed by Microsoft. No ETA either. :/ My advice is to deploy ProfileXML with the protocol type set to IKEv2, then change it back to Automatic post deployment by updating the entry in rasphone.pbk (using PowerShell or group policy).
Kaido
/ September 20, 2019Could you please provide instructions how to change protocol with PowerShell?
Richard M. Hicks
/ September 21, 2019After you import ProfileXML with the protocol type set to IKEv2, you can then use the Set-VpnConnection -Name [ConnectionName] -TunnelType Automatic. Hope that helps!
Daniel
/ December 5, 2019Would it be a workaround, to set the IPsecConfiguration simply with the Set-VpnConnectionIPsecConfiguration cmdlet after creating a connection with the TunnelType Automatic?
Richard M. Hicks
/ December 5, 2019That would work too. In that case you would leave the protocol type set to Automatic, ProfileXML would be loaded without the updated cryptography settings for IPsec, then you’d update those setting afterward using the Set-VpnConnectionIpsecConfiguration PowerShell command.
Christian Albrecht
/ August 26, 2020Does setting NativeProtocolType in the User ProfilXML to IKEv2 mean that it will ignore the VPNStrategy from rasphone.pbk?
So if set to IKEv2 a fallback to SSTP would not be possible even if it is configured in rasphone.pbk?
Richard M. Hicks
/ August 26, 2020No. When you select IKEv2 as the NativeProtocolType, VpnStrategy is set to “7”. If you changed this yourself to “8” it would attempt to try SSTP if IKEv2 failed, but it wouldn’t work because SSTP doesn’t support machine certificate authentication.
Nathan
/ August 6, 2021Hi Richard, have you ever seen this with SSTP tunnels at all? We’ve had some users who have been working fine coming into the RRAS servers via our Kemp Loadmaster. This morning some of them cant get their AOVPN tunnels connected and both error back with the 800 error. The User tunnel is set to VPNStrategy 6 to use SSTP so i’m a bit confused why this error is happening for that tunnel.
If we send them to one of our RRAS servers outside the Load Balancer it then reconnects and works fine.
Richard M. Hicks
/ August 6, 2021I’ve not seen this happen with SSTP user tunnel connections myself. However, if the load balancer isn’t passing the client’s original source IP address, that could cause the problem. The issue is more prevalent with IKEv2, but it can cause problems for SSTP. Details here: https://directaccess.richardhicks.com/2020/04/13/always-on-vpn-ikev2-load-balancing-and-nat/.