As promised, this post provides the second part of my experiences using the AnyConnect® 3.0 client with IKE version 2. This research was conducted using an ASA5520 with OS version 8.4(1) and ASDM version 6.4(1). Rather than illustrate a “how to” guide for a successful implementation (which is what I did in Part I), this follow-up will provide troubleshooting and research into an (as-of-yet) unsupported capability of the IKEv2 protocol.
In Part I, I briefly mentioned the optional choice of the “Standard Authentication” option checkbox illustrated in the screenshot below, obtained from using the embedded Profile Editor in ASDM. The objective in this exercise was to choose a standard non-certificate method (EAP-MD5) and experiment with it to see if I could get it to function.
As the next Wireshark® screenshot shows, the client tried several times to unsuccessfully authenticate. The details below the highlighted and expanded packet indicates that the payload was encrypted, meaning the troubleshooting had to focus on system log messages or debug traces on one of the endpoints. The ASA seemed the most logical choice.
As a portion of the rather verbose output of the debug command executed on the ASA (shown in bold font) shows, the ASA seemed to be presented with a packet type it didn’t recognize.
debug crypto ikev2 protocol 16
IKEv2-PROTO-5: Parse Vendor Specific Payload: (CUSTOM) VID Next payload: IDi, reserved: 0x0, length: 20
IKEv2-PROTO-1: Header length 8 is Invalid for payload ID
Decrypted packet:Data: 492 bytes
IKEv2-PROTO-1: (6): Detected an invalid value in the packet
IKEv2-PROTO-1: (6): Failed to parse the packet
IKEv2-PROTO-3: (6): Send error response
In my research as to why the ASA had a seemingly inexplicable problem recognizing a configurable option using “its own” embedded AnyConnect Client Profile Editor, I found the following note in the AnyConnect Secure Mobility Client Release Notes:
As stated above, the “Standards-based” authentication is planned for implementation on the IOS® router, not the ASA. This begs the question of why include the capability of supporting a feature in an editor launched through the ASA GUI, which the ASA itself doesn’t support? The simple answer is that the Profile Editor interface needs to be the same across ALL client-based SSL VPN platforms, as it’s used to create profiles for the client independent of the termination point (ASA or router).
One noteworthy technical tidbit: RFC 5998, entitled An Extension for EAP-Only Authentication in IKEv2 is dated September 2010. The recent nature of this proposal would strongly suggest that the specifications for how this will be implemented are still emerging.