There was thee major issues which caused the config to not function, or caused compatibility issues with other versions of anyconnect and IOS.
I will outline those technical details below:
1. Manually configured IKEv2 proposals must be linked with an IKEv2 policy; otherwise, the proposals are not used in the negotiation.
However in the original There was no policy declared, I learned from Cisco’s official IKEv2. That a policy must be configured derived from the manually declared IKEv2 proposal.
IF there isn’t “CRYPTO IKEv2 POLICY” that will link back to the propsal, consequently the manually configured propsal in the lesson was not being utilised during the IKEv2_INIT part of the IKEv2 negoation.
2.The Default proposal must be disabled in order to utilise the manually configured proposal
This subsequent issue we run into is a direct consequence of the above configuration.
Now that we have declared a policy that will be linked with a manually configured proposal, we must disable the default policy. Otherwise the config will still prioritise the default policy, this will result in the default proposal being utilised.
When you have configured a custom IKEv2 Proposal and Policy you can and should disable the defaults.
no crypto ikev2 proposal default
no crypto ikev2 policy default
Because the default policy was being utilised, this was initiating the default proposal. This resulted in IKEv2 using depreciated cryptography, integrity and Diffie-Hellman group in the IKEv2_INIT part of the negation. Consequently only anyconnect <4.8 was supported by the server.
3. IKEv2 Authorization Policy needs to be linked to the IKEv2 Profile.
When you are configuring the profile in IKEv2, You must declare the aaa authorization group anyconnect-eap list ‘NAME OF YOUR AAA AUTHORIZATION NETWORK You must FOLLOW this up with the KEv2 Authorization Policy
This applies even if are using a radius server(i.e ISE) or local authentication!
for example in the profile in
aaa authorization group anyconnect-eap list it must be linked with authorization policy e.g ‘
During my time in the lab, I learned even if you are a using authorization policy attributes deriving from radius(e.g ISE), that you must use a “dummy” authorization policy!(strange I know)
This is not mentioned by cisco, which I found rather strange.Cisco
Configuring Internet Key Exchange Version 2 (IKEv2) [Support]
Here is the current attribute populated authorization policy :
crypto ikev2 authorization policy IKEV2_AUTHORIZATION_POLICY pool VPN_POOL dns 22.214.171.124 def-domain NWL.LAB route set remote ipv4 126.96.36.199 255.255.255.255
Here is a “dummy” authorization policy that needs to be declared, this applies even if attributes is to derived from ISE.
crypto ikev2 authorization policy IKEV2_AUTHORIZATION_POLICY