Issue with multiple crypto isakmp policies

[Travis LaRose]

Hey folks,

I'm having an issue setting up multiple crypto isakmp policies on my 1921 router. Whenever I have only one crypto isakmp policy set up like so:

crypto isakmp policy 1
 encr aes 256
 group 5
 

It works perfectly fine with my certificate tunnel group in my ASA. When I debug crypto ipsec & debug crypto isakmp and watch the connection, I see this:

ISAKMP transform 1 against priority 1 policy
*Oct  7 20:04:09.263: ISAKMP:      encryption AES-CBC
*Oct  7 20:04:09.263: ISAKMP:      keylength of 256
*Oct  7 20:04:09.263: ISAKMP:      hash SHA
*Oct  7 20:04:09.263: ISAKMP:      default group 5
*Oct  7 20:04:09.263: ISAKMP:      auth RSA sig
*Oct  7 20:04:09.263: ISAKMP:      life type in seconds
*Oct  7 20:04:09.263: ISAKMP:      life duration (VPI) of  0x0 0x1 0x51 0x80
*Oct  7 20:04:09.263: ISAKMP:(0):atts are acceptable. Next payload is 0

This is showing me that the handshake is verifying the policy with the "auth RSA sig" type, which is what I expected and is what I want.

Here is where my issue actually comes up. When I add another crypto isakmp policy (2) the "authorization pre-share" over rides the "authorization rsa-sig" of policy 1. Here is what I have set up:

crypto isakmp policy 1
 encr aes 256
 group 5
!
crypto isakmp policy 2
 encr aes 256
 authorization pre-share
 group 5

This is showing me that crypto isakmp policy 1 is set with the default authorization type of rsa-sig (in fact if I manually enter that command under the policy 1 configuration mode and it doesn't print in the show run output), and the crypto isakmp policy 2 is set to authorization pre-share.

When I debug crypto ipsec & debug crypto isakmp with this configuration, this is what I'm getting:

56:46.259: ISAKMP:(0): PKI->IKE Got configured TrustPoints state (I) MM_NO_STATE (peer 199.46.128.5)
*Oct  7 19:56:46.263: ISAKMP:(0):Checking ISAKMP transform 2 against priority 1 policy
*Oct  7 19:56:46.263: ISAKMP:      encryption AES-CBC
*Oct  7 19:56:46.263: ISAKMP:      keylength of 256
*Oct  7 19:56:46.263: ISAKMP:      hash SHA
*Oct  7 19:56:46.263: ISAKMP:      default group 5
*Oct  7 19:56:46.263: ISAKMP:      auth pre-share
*Oct  7 19:56:46.263: ISAKMP:      life type in seconds
*Oct  7
19:56:46.263: ISAKMP:      life duration (VPI) of  0x0 0x1 0x51 0x80
*Oct  7 19:56:46.263: ISAKMP:(0):Authentication method offered does not match policy!
*Oct  7 19:56:46.263: ISAKMP:(0):atts are not acceptable. Next payload is 0
*Oct  7 19:56:46.263: ISAKMP:(0):Checking ISAKMP transform 2 against priority 2 policy
*Oct  7 19:56:46.263: ISAKMP:      encryption AES-CBC
*Oct  7 19:56:46.263: ISAKMP:      keylength of 256
*Oct  7 19:56:46.263: ISAKMP:      hash SHA
*Oct  7 19:56:46.263: ISAKMP:
default group 5
*Oct  7 19:56:46.263: ISAKMP:      auth pre-share
*Oct  7 19:56:46.263: ISAKMP:      life type in seconds
*Oct  7 19:56:46.263: ISAKMP:      life duration (VPI) of  0x0 0x1 0x51 0x80

It looks like the first policy is being verified against "auth pre-share" and fails because "Authentication method offered does not match policy!". My question is, does anyone know how to correct this so that the first policy is set to authenticate via rsa-sig and the second policy is authenticated via pre-shared keys? Is there a bug that will not differentiate the authorization types between the two policies?

Just an FYI, here is the version information of the router:

Cisco IOS Software, C1900 Software (C1900-UNIVERSALK9-M), Version 15.2(4)M3, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2013 by Cisco Systems, Inc.
Compiled Tue 26-Feb-13 02:11 by prod_rel_team

ROM: System Bootstrap, Version 15.0(1r)M16, RELEASE SOFTWARE (fc1)

System returned to ROM by power-on
System image file is "usbflash0:c1900-universalk9-mz.SPA.152-4.M3.bin"
Last reload type: Normal Reload
Last reload reason: power-on

This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export@cisco.com.

Cisco CISCO1921/K9 (revision 1.0) with 491520K/32768K bytes of memory.
Processor board ID FTX171385L4
2 Gigabit Ethernet interfaces
1 terminal line
1 Virtual Private Network (VPN) Module
DRAM configuration is 64 bits wide with parity disabled.
255K bytes of non-volatile configuration memory.
249840K bytes of USB Flash usbflash0 (Read/Write)

License Info:

License UDI:

-------------------------------------------------
Device#   PID                   SN
-------------------------------------------------
*0        CISCO1921/K9         

Technology Package License Information for Module:'c1900'

-----------------------------------------------------------------
Technology    Technology-package           Technology-package
              Current       Type           Next reboot
------------------------------------------------------------------
ipbase        ipbasek9      Permanent      ipbasek9
security      securityk9    Permanent      securityk9
data          None          None           None

Configuration register is 0x2102

[Walter Astori]

i think that the number of the instruction crypto isakmp policy "number" must be equal to the instruction crypto map "name" "number" set ........

[Richard Burts]

It is not true that the number of the ISAKMP policy must match the crypto map number. There is no relationship between these numbers.

I believe that what is happening is that when you are doing the ISAKMP negotiation the device that initiated the connection offers ISAKMP policies (in the order that they appear on that device) and the receiving devices checks the offered policy against all of its policies and if there is a match then that policy is selected and used. So if the other device is the initiator and if that device has pre shared key policy with a lower number than rsa sig then it will offer pre shared key before it offers rsa sig and your device will match on pre shared key.

HTH

Rick

[Travis LaRose]

Thanks Rich. Actually on both devices pre-shared key authentication is lowest on the priority list for connection. Both devices are "preferring" an rsa-sig authentication. I'm not sure what is doing it, but just by adding the line "authorization pre-share" on crypto isakmp policy 2 ONLY, it changes the behavior of the connection so that the authorization of crypto isakmp policy 1 is now being checked against pre-shared key authorizaiton... This causes certificate authentication to fail, pre-shared authentication works and the tunnel comes up with that.

If you see the output of the two debugs in the original post, I show that with only one crypto policy defined the "auth RSA sig" is clearly set for that policy. However, by adding a second policy and setting that specific policy to authenticate with pre-share the subsequent debugs of both crypto isakmp and crypto ipsec show that the router is attempting to authenticate BOTH policies via "auth pre-share"...

[Travis LaRose]

Thanks for the input Walter. That isn't it though. I have plenty of sites with crypto map <name> 1 which map to crypto isakmp policy 2 settings. The debug is showing that the behavior is to try to authenticate through policy 1 first, and then progress to any other policies until there is a match. Since there is a match with policy 2 settings, the tunnel comes up.

My real question is, why would it change from "auth RSA sig" in the first debug out put to the "auth pre-share" in the second debug output. Judging by the config on the router, it appears to me that the line for "authorization pre-share" under policy 2 SHOULD only apply to policy 2 and SHOULD NOT override the "authorization rsa-sig" of policy 1.

Again, when I debug crypto ipsec & debug crypto isakmp, it shows clearly that the first policy is being verified, however the "auth" is now "pre-share" and no longer "RSA sig":

56:46.259: ISAKMP:(0): PKI->IKE Got configured TrustPoints state (I) MM_NO_STATE (peer 199.46.128.5)
*Oct  7 19:56:46.263: ISAKMP:(0):Checking ISAKMP transform 2 against priority 1 policy
*Oct  7 19:56:46.263: ISAKMP:      encryption AES-CBC
*Oct  7 19:56:46.263: ISAKMP:      keylength of 256
*Oct  7 19:56:46.263: ISAKMP:      hash SHA
*Oct  7 19:56:46.263: ISAKMP:      default group 5
*Oct  7 19:56:46.263: ISAKMP:      auth pre-share     <---This should read "auth RSA sig"
*Oct  7 19:56:46.263: ISAKMP:      life type in seconds
*Oct  7
19:56:46.263: ISAKMP:      life duration (VPI) of  0x0 0x1 0x51 0x80
*Oct  7 19:56:46.263: ISAKMP:(0):Authentication method offered does not match policy!
*Oct  7 19:56:46.263: ISAKMP:(0):atts are not acceptable. Next payload is 0
*Oct  7 19:56:46.263: ISAKMP:(0):Checking ISAKMP transform 2 against priority 2 policy
*Oct  7 19:56:46.263: ISAKMP:      encryption AES-CBC
*Oct  7 19:56:46.263: ISAKMP:      keylength of 256
*Oct  7 19:56:46.263: ISAKMP:      hash SHA
*Oct  7 19:56:46.263: ISAKMP:
default group 5
*Oct  7 19:56:46.263: ISAKMP:      auth pre-share
*Oct  7 19:56:46.263: ISAKMP:      life type in seconds
*Oct  7 19:56:46.263: ISAKMP:      life duration (VPI) of  0x0 0x1 0x51 0x80