cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
571
Views
10
Helpful
1
Replies

DMVPN authentication issues with PSK (Preferred ISAKMP Policy not getting matched)

Hello,

We are moving our DMVPN authentication back to PSK from certificates and finding that the the isakmp is still authenticating with RSA sig rather than the newly configured PSK.

Our idea was to configure a new crypto isakmp policy to use PSK. This was configured with a better priority than the existing policy that uses certificates.

The intention (and this worked in a lab environment) was to then lower the life time of the existing policy and then once timed out we would gracefully move over to PSK authentication.

This is not working in our live environment. The lifetime expires and the authentication still uses certificates rather than PSKs.

We are seeing the below debug:

May 23 09:48:08.679: ISAKMP:(0): IKE->PKI Get configured TrustPoints state (I) MM_NO_STATE (peer x.x.x.x)

May 23 09:48:08.679: ISAKMP:(0): PKI->IKE Got configured TrustPoints state (I) MM_NO_STATE (peer x.x.x.x)

May 23 09:48:08.679: ISAKMP:(0):Checking ISAKMP transform 1 against priority 2 policy

May 23 09:48:08.679: ISAKMP:      encryption AES-CBC

May 23 09:48:08.679: ISAKMP:      keylength of 192

May 23 09:48:08.679: ISAKMP:      hash SHA

May 23 09:48:08.679: ISAKMP:      default group 2

May 23 09:48:08.679: ISAKMP:      auth RSA sig

May 23 09:48:08.679: ISAKMP:      life type in seconds

May 23 09:48:08.679: ISAKMP:      life duration (basic) of 120

May 23 09:48:08.679: ISAKMP:(0):Authentication method offered does not match policy!

May 23 09:48:08.679: ISAKMP:(0):atts are not acceptable. Next payload is 0

May 23 09:48:08.679: ISAKMP:(0):Checking ISAKMP transform 1 against priority 10 policy

May 23 09:48:08.679: ISAKMP:      encryption AES-CBC

May 23 09:48:08.679: ISAKMP:      keylength of 192

May 23 09:48:08.679: ISAKMP:      hash SHA

May 23 09:48:08.679: ISAKMP:      default group 2

May 23 09:48:08.679: ISAKMP:      auth RSA sig

May 23 09:48:08.679: ISAKMP:      life type in seconds

May 23 09:48:08.679: ISAKMP:      life duration (basic) of 120

May 23 09:48:08.679: ISAKMP:(0):atts are acceptable. Next payload is 0

May 23 09:48:08.679: ISAKMP:(0):Acceptable atts:actual life: 0

May 23 09:48:08.679: ISAKMP:(0):Acceptable atts:life: 0

May 23 09:48:08.679: ISAKMP:(0):Basic life_in_seconds:120

May 23 09:48:08.679: ISAKMP:(0): IKE->PKI Start PKI Session state (I) MM_NO_STATE (peer x.x.x.x)

May 23 09:48:08.679: ISAKMP:(0): PKI->IKE Started PKI Session state (I) MM_NO_STATE (peer x.x.x.x)

May 23 09:48:08.679: ISAKMP:(0):Returning Actual lifetime: 120

May 23 09:48:08.679: ISAKMP:(0)::Started lifetime timer: 120.

I am trying to understand what "Checking ISAKMP transform 1 against priority 2 policy" means and how we can get it to match our ISAKMP policy 5

crypto isakmp policy 5
encr aes 256
authentication pre-share
group 2
!
crypto isakmp policy 10
encr aes 192
group 2
crypto isakmp key XXXXXXXXXXXXXXXXXXXXXXXXXX address 0.0.0.0
crypto isakmp keepalive 240 4

Thanks

Nick

1 Reply 1

taylor.robert
Level 1
Level 1

Hello Nicholas

Having lab'd this scenario up for you (which worked a treat!) and going on the basis that your key is correct, I would recommend raising a TAC case in the first instance.

I suspect that either the Hub router needs a kick or you have identified a bug in the software.

Let's see what Cisco come back with.

Let me know how you get on. :)