Exploring use of Windows 10 VPN client to access Cisco AnyConnect IPsec/IKEv2

The Cisco AnyConnect client supports two VPN transports: SSL (TLS plus optionally DTLS) and IPsec/IKEv2. The IPsec/IKEv2 connection transport is standard and AnyConnect seemingly just differs from the Windows VPN client in so far as it supports a Cisco specific EAP (Extensible Authentication Protocol) mechanism.

 If the Windows VPN client could be used (with a custom EAP implementation) to connect to an AnyConnect server via IPsec/IKEv2, one could avoid installing a full VPN stack (parallel to the Windows stack) and also avoid the policies that are enforced by the AnyConnect client.

Unfortunately, there are some small but fatal obstacles to implementing this idea. This article describes where the problems lie.

IKEv2 Vendor ID Payload

RFC 7296, in section 3.12 says:

   The Vendor ID payload, denoted V in this document, contains a vendor-
   defined constant.  The constant is used by vendors to identify and
   recognize remote instances of their implementations.  This mechanism
   allows a vendor to experiment with new features while maintaining
   backward compatibility.

   A Vendor ID payload MAY announce that the sender is capable of

   accepting certain extensions to the protocol, or it MAY simply
   identify the implementation as an aid in debugging.

There does not seem to be any way to influence the Vendor ID payloads included in IKEv2 messages under Windows. Reading “[MS-IKEE]: Internet Key Exchange Protocol Extensions” seems to confirm this belief – the Microsoft IKEv2 implementation only sends particular Vendor ID payloads and not arbitrary payloads provided by an external component.

The IKE_SA_INIT message needs to include a Vendor ID payload with the value "CISCO-ANYCONNECT-EAP" in order to indicate that the client supports AnyConnect EAP, otherwise the Cisco VPN server will reject a subsequent attempt to use that EAP mechanism. A Cisco AnyConnect client also includes other Cisco Vendor ID payloads, but the absence of these payloads does not prevent an AnyConnect EAP connection from being established.

IKEv2 Identification Payload

The Cisco VPN server expects a particular (configurable) value for the Identification payload to be present in the first IKE_AUTH message; by default, the expected payload should contain an ID Type of 201 (the first “Private use” ID Type value) and the Identification Data "*$AnyConnectClient$*". If the client does not send the correct Identification payload, the connection attempt is aborted.

The Microsoft IKEv2 implementation does defer the contents of the Identification payload to an external component and calls out to the RasMan service, but there is no API to specify what RasMan should return. By default, it returns an ID_IPV4_ADDR ID Type but it can be persuaded (by setting the value “ExtendedIDiSupport” in the registry and meeting other requirements) to return an ID_FQDN ID Type. It is not possible to specify an arbitrary ID Type and Identification Data.

IKEv2 Fragmentation

The individual AnyConnect EAP messages can be large (especially if certificate authentication is used) and can (and do) easily exceed the size of the MTU for the path to the AnyConnect server. Windows only allows EAP messages to be up to MTU minus 100 bytes in size and suggests that a fragmentation mechanism be incorporated into the EAP mechanism if longer messages are needed.

AnyConnect Certificate Authentication

The mechanism used by AnyConnect to prove knowledge of the certificate private key depends on access to IKEv2 managed data (IKEv2 messages and derived keys), which is not available to EAP implementations under Windows.

 

IKEv2 Authentication Payload

The AnyConnect EAP mechanism is not key-generating, so the Authentication payloads should be computed (using the notation of RFC 7296) as:

AUTH = prf( prf(SK_pi, "Key Pad for IKEv2"), <InitiatorSignedOctets>)

AUTH = prf( prf(SK_pr, "Key Pad for IKEv2"), <ResponderSignedOctets>)

The Microsoft IKEv2 implementation seems to use a different computation for the Authentication payloads.

IKEv2 Extensible Authentication Protocol (EAP) Payload

Windows provides two frameworks to handle the EAP payloads in IKEv2 messages: the legacy EAP methods and the EAPHost Framework. The AnyConnect EAP method is not trivial but it is relatively straightforward and could easily be implemented using either framework.

Summary

With some serious hacking (which needs updating each time the relevant Microsoft DLL changes), it is possible to overcome each of these problems and the resulting VPN tunnel works well. It is however unlikely that this approach would ever be a viable option for connecting to an AnyConnect VPN server. The EAP fragmentation problem could be addressed be just letting the EAP method depend on IP fragmentation, if it chooses to do so. Mechanisms for setting IKEv2 Vendor Id and Identification payloads could be added to the Windows EAP frameworks. The Authentication payload problems looks like a bug that could be fixed. However the AnyConnect certificate authentication method seems to be irreconcilable with any reasonable compartmentalization of the IKEv2 and EAP implementations.