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
The monitoring of DirectAccess machine and user activity presents some unique challenges for security administrators. All DirectAccess client communication destined for the internal corporate network is translated by the DirectAccess server and appears to originate from the DirectAccess server’s internal IPv4 address. Also, the public IPv4 address for DirectAccess clients using the IP-HTTPS IPv6 transition protocol is 
