FlexVPN Remote Access AnyConnect

This topic is to discuss the following lesson:

Hi Rene and the NWL Team,

I managed to resolve nearly all issues by using the same anyconnect version utilised in the lesson (4.8.03052)

However once I click connect anyway after the self-signed certificate warning, anyconnect requests the local AAA credentials upon entering those credentials

“The IPsec VPN connection was terminated due to an authentication failure or timeout”?

Any help would be much appreciated.

P.S I am using IOS 15.7(3)(M3)

Hello Taha

Keep in mind that the AnyConnect client depending upon its version can support various different configurations. You may have configured the ASA exactly the same way as in the lesson, but the client may or may not support certain configurations.

You may also find that depending upon your operating system or connecting device (Windows 10, Windows 7/8, Android, iOS, Mac etc…) you will have different capabilities. The following Cisco community thread describes some of these issues that have resulted in the same error as you are getting here. Hopefully this will shed some light on the problems you are facing:

Let us know how your troubleshooting is coming along…

I hope this has been helpful!

Laz

1 Like

After consistently spending time in the lab troubleshooting/reading/learning the fundamentals of IKEV2. I was able to use the false positive debug information to track the root cause of this “passed authentication and failed authorization” issue.

I have finally managed to resolve this issue and I hope this small write-up will help others in future too.

I was using the same version of anyconnect 4.8 in the article and IOS 15.7.

Authorization Failure:
The article really helped! however it left out a small issue:

From the article I learned that:

A VPN with Ikev2 requires the following:

IKEv2 proposal

IKEv2 policy

IKEv2 Authorization Policy (missing from the article and caused small confusion)

IKEv2 profile

IKEv2 keyring

IPSec:

IPSec transform-set

IPSec profile

When you are configuring the profile in IKEv2
and you are declaring 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 to you if you are using a radius or local authentication!

for example aaa authorization group anyconnect-eap list 'AAA_AUTHORIZATION_NETWORK' 'IKEV2_AUTHORIZATION_POLICY'

even if you are using a policy derived from radius you must use a “dummy” authorization policy!

A populated authorization policy example:

crypto ikev2 authorization policy IKEV2_AUTHORIZATION_POLICY
pool VPN_POOL
dns 1.1.1.1
def-domain NWL.LAB
route set remote ipv4 1.1.1.1 255.255.255.255

a “dummy” authorization policy:

crypto ikev2 authorization policy IKEV2_AUTHORIZATION_POLICY

(EMPTY)

The issue with “Smart Defaults”
The main issue with smart defaults IS even IF you don’t configure it and you let “smart defaults” predefine a “default” authorization policy, that authorization policy name will be required to be called in the profile! otherwise authentication will pass but authorization will FAIL!( my experience). If you don’t call and name a authorization policy I’m not sure how we can specify it in the profile!

Cryptographic Errors when using anyconnect 4.9+

AnyConnect 4.9.00086 disables certain cryptography encryption/hash and groups DES, 3DES, MD5, and DH groups 2,5, 14, and 24

Workaround:

SOLUTION 1: Simply specify all encryption and hash in the proposal

crypto ikev2 proposal MY_IKEV2_PROPOSAL
encryption aes-cbc-256 aes-cbc-192 aes-cbc-128 3des
integrity sha512 sha384 sha256 sha1
group 21 20 19 16 14 5 2

crypto ikev2 policy MY_IKEV2_POLICY
proposal MY_IKEV2_PROPOSAL

Solution 2:
Write separate proposals and specify them in the ikev2 Policy(not to be confused with the “authorization policy”)

crypto ikev2 proposal HIGH
encryption aes-cbc-256 aes-cbc-192 aes-cbc-128
integrity sha512 sha384 sha256
group 21 20 19
crypto ikev2 proposal MEDIUM
encryption aes-cbc-256 aes-cbc-192 aes-cbc-128
integrity sha256 sha1
group 16 14
crypto ikev2 proposal LOW
encryption aes-cbc-128 3des
integrity sha1 md5
group 5 2
crypto ikev2 policy MY_IKEV2_POLICY
proposal HIGH
proposal MEDIUM
proposal LOW

Solution 3: Use “anyconnect version pre 4.9”
NOTE: You are then resorting to utilising depreciated cryptography “encryption/hash and groups”

Remember both these issue apply if you are using radius ISE OR local database for AAA

I hope that makes sense, please leave me a comment for any further clarification.

Hello Taha

I suggest you go into the device and take a look at the syslogs. They should tell you the reason for the failure. If it is credentials, if it is a mismatch in authentication parameters, or if it is actually a timeout. Looking at the logs will give you a clearer picture so that you can more correctly approach the troubleshooting process…

I hope this has been helpful!

Laz

1 Like

Hi Lazaros

I have been using debug crypto ikev2.

This really helped, unfortunately didn’t point me in the right direction, but it made a difference. I could see the client was replying back to the server with authen credentials! It gave me the exact line that was failing. So I knew where to start

Taha

Hello Taha!

Thanks so much for your post above, it really adds to the value and relevance of the forum. Your contribution is much appreciated! I’ll let Rene know so he can consider including some of that information in the lesson for clarification.

Thanks again for your contribution!

Laz

Hi Laz,

I am extremely flattered by your compliments thank you. I am novice in the cisco world.
I think very highly of any individual who has acquired a CCIE. I see them as a role-model!

As of late networking and virtualization has become a hobby activity, subsequently this aids ones ability to learn rather quickly.

The issue came to my attention, after reading cisco article on IKEv2:

Under the proposal section it states:

“Manually configured IKEv2 proposals must be linked with an IKEv2 policy; otherwise, the proposals are not used in the negotiation”

consequently when a proposal is manually configured, this must be called/linked to a policy for example:

> Crypto IKEv2 proposal nwlesson_Proposal
> {Encryption Algorithm} e.g aes-cbc256 etc
*> {Integrity Algorithm} any hash of your choice e.g SHA etc *
> {Pseudo-Random function (PRF)} The PRF algorithm is the same as integrity algorithm, subesquently this does not to separately configured
{Diffie-Hellman(DH) Group}

I discovered yesterday in the lab, if you want this proposal to be utilised in the IKEv2 negotiation it MUST be called/linked by a policy for example:

Crypto IKEv2 Policy nwlesson_Policy
proposal nwlesson_Proposal (our proposal we configured above)

During a friday night dinner out with the family. I kept thinking, what happens if we don’t link the proposal to a policy?

Subsequently from 10pm untill 1am in the lab, I tested this theory. The configured proposal(encryption, Integrity, PRF algorithm and DH group) is not utilised in the SA_INIT exchange of the IKEv2 negotiation, if there isn’t a policy!

subsequently the question becomes, what proposal is being utilised if the one we configured isn’t being used in the exchange?

The answer: the default proposal!(remember smart defaults?)

now on this fantastic article by Rene that allowed me to learn about FlexVPN in general, I am very appreciative of this tutorial! it’s simply outstanding!

You will notice there is no policy that links the proposal, just a authorization policy which technically is completely different. Subsequently we are not using those proposal declared in the tutorial for the negotiation we are simply using default values provided by IOS:

in order to utilise the proposa(IKEV2_PROPOSAL)l that was declared in the lesson we must include the following in the tutorial guide:

Crypto IKEv2 Policy nwlesson_Policy
proposal IKEV2_PROPOSAL

many thanks again!

Taha

Hello Taha

Well, credit where credit is due. Being curious about “what happens if…” is part of being good at networking, especially when it comes to complex interactions of various features on a device.

Thanks for adding these details, it helps all of us get better at what we do.

Laz

1 Like

Hi @ReneMolenaar ,

It’s an absolute pleasure to meet you :raising_hand_man:

I apologise I opened up multiple topics regarding this issue, as I was experiencing multiple issues with the lesson. Lets use this forum as I have included details on how I came to conclusions with some of the issues above.

I would like to state the article is wonderful. Between each step you provide details on a) why we are performing the the particular step b)How we will perform this config.
With this type of break-down one is able to fully comprehend and understand the config, subsequently this allows you to manipulate the code to satisfy individualised criteria.

I was further able to troubleshoot some of the issues, which I raised with @lagapides

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
or
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 ‘AAA_AUTHORIZATION_NETWORK' 'IKEV2_AUTHORIZATION_POLICY

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.

For example:
Here is the current attribute populated authorization policy :

crypto ikev2 authorization policy IKEV2_AUTHORIZATION_POLICY
pool VPN_POOL
dns 1.1.1.1
def-domain NWL.LAB
route set remote ipv4 1.1.1.1 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

(EMPTY)

in the tutorial we are using LOCAL derived attributes, however if both are configured(ISE and Local) LOCAL will take preference.
The IKEv2 authorization policy serves as a container of IKEv2 local AAA group authorization parameters.

The issue was the tutorial’s authorization policy was configured with attributes. However it was NOT linked to the profile. Consequently this was causing the authorization error, in the AAA part of the negotiations.

I managed to troubleshoot most of these issues using:

debug crypto IKEv2
debug aaa authorization
debug aaa authentication

Update: I noticed you managed to update the tutorials to address some of these issues I raised, that is absolutely brilliant!

Many thanks again!
Taha

1 Like