Troubleshooting IKEv2 VPN Connections

Applies To: Windows Server 2008 R2

If you deploy virtual private network (VPN) connections by using Routing and Remote Access services (RRAS) on Windows Server 2008 R2, then you should be aware of the following potential issues:

VPN connections that use IKEv2

Internet Key Exchange version 2 (IKEv2) support was added in Windows Server 2008 R2 and Windows 7 to accommodate a new VPN type that supports VPN Reconnect. VPN Reconnect refers to the ability of a VPN connection to survive short interruptions in network connectivity, such as when you move from one wireless access point to another, or when you switch from a wired to a wireless network adapter. By taking advantage of features in IKEv2, even changes in IP address at the client do not drop the VPN connection or require any user actions. As soon as connectivity to the RRAS VPN server is restored, then the VPN tunnel is automatically reestablished.

IKEv2 client computers validate the machine certificate sent by the VPN server

If the remote access server is not configured to use the right IKEv2 certificate, or if the client does not trust the root certification authority (CA) for the IKEv2 certificate, then the VPN connection fails. When this happens, the client logs one of the following events to indicate that it could not validate the certificate presented by the remote VPN server:

• Error 13801 occurs on the client when:

  • The certificate is expired.

  • The trusted root for the certificate is not present on the client.

  • The subject name of the certificate does not match the remote computer.

  • The certificate does not have the required Enhanced Key Usage (EKU) values assigned.

• Error 13806 occurs on the server when:

  • The server does not have a certificate installed that is suitable for use with IKEv2.

  • The certificate on the server does not have the Key Usage field set to “Digital Signature”.

If the client is configured with a multi-tunnel VPN strategy, such as when the tunnel type is configured as Automatic, then the client will automatically fall back to try other VPN tunnel types, such as Secure Socket Tunneling Protocol (SSTP). Although the connection is successful, the user might experience a delay in the connection due to the multiple tunnel attempts.

To avoid this problem:

• The certificate installed on the remote access server should have the following values for fields in the certificate:

  • Certificate Name (CN): This field should contain the fully qualified DNS name or IP address of the remote access server. If the server is located behind a network address translating (NAT) router, then the certificate must contain the fully qualified DNS name or IP address of the external connection of the NAT router (the address that the client computer sees as the address of the server).

  • EKU: For a certificate to be used to authenticate an IKEv2 connection, then the certificate must specify an EKU field that includes Server Authentication. If there is more than one server authentication certificate, then additionally include the IP security IKE intermediate EKU. Only one certificate should have both EKU options, otherwise IPsec cannot determine which certificate to use, and might not pick the certificate you intended.

• The root CA certificate corresponding to the server certificate must be installed on the client computers in the Trusted Root Certification Authorities per-computer certificate store. The client computer must be able to validate the server certificate as being signed by a trusted root CA.

• If you are already using SSTP connections, then you can use the same certificate for both SSTP and IKEv2, as long as the certificate meets the CN and EKU requirements identified previously. Because root CA certificates are required on client computers when using SSTP, adding a certificate for IKEv2 that was created by the same CA as an SSTP certificate means that no client changes are needed.