IOS IKEv1/IKEv2 Selection Rules for Keyrings and Profiles - Troubleshooting Guide

Available Languages

Download Options

PDF (115.5 KB)
View with Adobe Reader on a variety of devices
ePub (96.0 KB)
View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle) (108.7 KB)
View on Kindle device or Kindle app on multiple devices

Updated:April 28, 2016

Document ID:117259

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Introduction

This document describes the use of multiple keyrings for multiple Internet Security Association and Key Management Protocol (ISAKMP) profiles in a Cisco IOS^® software LAN-to-LAN VPN scenario. It covers the behavior of Cisco IOS Software Release 15.3T as well as potential problems when multiple keyrings are used.

Two scenarios are presented, based upon a VPN tunnel with two ISAKMP profiles on each router. Each profile has a different keyring with the same IP address attached. The scenarios demonstrate that the VPN tunnel can be initiated only from one side of the connection because of profile selection and verification.

The next sections of the document summarize the selection criteria for the keyring profile for both the Internet Key Exchange (IKE) initiator and IKE responder. When different IP addresses are used by the keyring on the IKE responder, the configuration works correctly, but use of the same IP address creates the problem presented in the first scenario.

Subsequent sections explain why the presence of both a default keyring (global configuration) and specific keyrings might lead to problems and why use of the Internet Key Exchange Version 2 (IKEv2) protocol avoids that problem.

The final sections present the selection criteria for the IKE profile for both for IKE initiator and responder, along with the typical errors that occur when an incorrect profile is selected.

Configuration

Notes:

The Cisco CLI Analyzer (registered customers only) supports certain show commands. Use the Cisco CLI Analyzer in order to view an analysis of show command output.

Refer to Important Information on Debug Commands before you use debug commands.

Topology

Router1 (R1) and Router2 (R2) use Virtual Tunnel Interface (VTI) (Generic Routing Encapsulation [GRE]) interfaces in order to access its loopbacks. That VTI is protected by Internet Protocol Security (IPSec).

Both R1 and R2 have two ISAKMP profiles, each with different keyring. All keyrings have the same password.

R1 Network and VPN

The configuration for the R1 network and VPN is:

crypto keyring keyring1
  pre-shared-key address 192.168.0.2 key cisco
crypto keyring keyring2
  pre-shared-key address 192.168.0.2 key cisco
!
crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
 group 2

crypto isakmp profile profile1
   keyring keyring1
   match identity address 192.168.0.102 255.255.255.255 !non existing host
crypto isakmp profile profile2
   keyring keyring2
   match identity address 192.168.0.2 255.255.255.255 !R2
!
crypto ipsec transform-set TS esp-aes esp-sha256-hmac
 mode tunnel
!
crypto ipsec profile profile1
 set transform-set TS
 set isakmp-profile profile2
!
interface Loopback0
 description Simulate LAN
 ip address 192.168.100.1 255.255.255.0
!
interface Tunnel1
 ip address 10.0.0.1 255.255.255.0
 tunnel source Ethernet0/0
 tunnel destination 192.168.0.2
 tunnel protection ipsec profile profile1
!
interface Ethernet0/0
 ip address 192.168.0.1 255.255.255.

ip route 192.168.200.0 255.255.255.0 10.0.0.2

R2 Network and VPN

The configuration for the R2 network and VPN is:

crypto keyring keyring1
  pre-shared-key address 192.168.0.1 key cisco
crypto keyring keyring2
  pre-shared-key address 192.168.0.1 key cisco
!
crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
 group 2

crypto isakmp profile profile1
   keyring keyring1
   match identity address 192.168.0.1 255.255.255.255 !R1
crypto isakmp profile profile2
   keyring keyring2
   match identity address 192.168.0.100 255.255.255.255 !non existing host
!
crypto ipsec transform-set TS esp-aes esp-sha256-hmac
 mode tunnel
!
crypto ipsec profile profile1
 set transform-set TS
 set isakmp-profile profile1
!
interface Loopback0
 ip address 192.168.200.1 255.255.255.0
!
interface Tunnel1
 ip address 10.0.0.2 255.255.255.0
 tunnel source Ethernet0/0
 tunnel destination 192.168.0.1
 tunnel protection ipsec profile profile1
!
interface Ethernet0/0
 ip address 192.168.0.2 255.255.255.0

ip route 192.168.100.0 255.255.255.0 10.0.0.1

All keyrings use the same peer IP address and use the password ' cisco.'

On R1, profile2 is used for the VPN connection. Profile2 is the second profile in the configuration, which uses the second keyring in the configuration. As you will see, the keyring order is critical.

Example Scenarios

In the first scenario, R1 is the ISAKMP initiator. The tunnel is negotiating correctly, and traffic is protected as expected.

The second scenario uses the same topology, but has R2 as the ISAKMP initiator when phase1 negotiation is failing.

Internet Key Exchange Version 1 (IKEv1) needs a pre-shared key for skey calculation, which is used in order to decrypt/encrypt Main Mode packet 5 (MM5) and subsequent IKEv1 packets. The skey is derived from the Diffie-Hellman (DH) computation and the pre-shared key. That pre-shared key needs to be determined after MM3 (responder) or MM4 (initiator) is received, so that the skey, which is used in MM5/MM6, can be computed.

For the ISAKMP responder in MM3, the specific ISAKMP profile is not yet determined because that happens after the IKEID is received in MM5. Instead, all keyrings are searched for a pre-shared key, and the first or best matching keyring from the global configuration is selected. That keyring is used in order to calculate the skey that is used for decryption of MM5 and encryption of MM6. After the decryption of MM5 and after the ISAKMP profile and associated keyring are determined, the ISAKMP responder performs verification if the same keyring has been selected; if the same keyring is not selected, the connection is dropped.

Thus, for the ISAKMP responder, you should use a single keyring with multiple entries whenever possible.

R1 As IKE Initiator (Correct)

This scenario describes what occurs when R1 is the IKE initiator:

Use these debugs for both R1 and R2:

R1# debug crypto isakmp
R1# debug crypto ipsec
R1# debug crypto isakmp aaa

R1 initiates the tunnel, sends the MM1 packet with policy proposals, and receives MM2 in response. MM3 is then prepared:

R1#ping 192.168.200.1 source lo0 repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 192.168.200.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.100.1

*Jun 19 10:04:24.826: IPSEC(sa_request): ,
  (key eng. msg.) OUTBOUND local= 192.168.0.1:500, remote= 192.168.0.2:500,
    local_proxy= 192.168.0.1/255.255.255.255/47/0,
    remote_proxy= 192.168.0.2/255.255.255.255/47/0,
    protocol= ESP, transform= esp-aes esp-sha256-hmac  (Tunnel),
    lifedur= 3600s and 4608000kb,
    spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x0
*Jun 19 10:04:24.826: ISAKMP:(0): SA request profile is profile2
*Jun 19 10:04:24.826: ISAKMP: Found a peer struct for 192.168.0.2, peer 
    port 500
*Jun 19 10:04:24.826: ISAKMP: Locking peer struct 0xF483A970, refcount 1 
    for isakmp_initiator
*Jun 19 10:04:24.826: ISAKMP: local port 500, remote port 500
*Jun 19 10:04:24.826: ISAKMP: set new node 0 to QM_IDLE
*Jun 19 10:04:24.826: ISAKMP:(0):insert sa successfully sa = F474C2E8
*Jun 19 10:04:24.826: ISAKMP:(0):Can not start Aggressive mode, trying 
    Main mode.
*Jun 19 10:04:24.826: ISAKMP:(0):Found ADDRESS key in keyring keyring2
*Jun 19 10:04:24.826: ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID
*Jun 19 10:04:24.826: ISAKMP:(0): constructed NAT-T vendor-07 ID
*Jun 19 10:04:24.826: ISAKMP:(0): constructed NAT-T vendor-03 ID
*Jun 19 10:04:24.826: ISAKMP:(0): constructed NAT-T vendor-02 ID
*Jun 19 10:04:24.826: ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, 
    IKE_SA_REQ_MM
*Jun 19 10:04:24.826: ISAKMP:(0):Old State = IKE_READY  New State = 
    IKE_I_MM1

*Jun 19 10:04:24.826: ISAKMP:(0): beginning Main Mode exchange
*Jun 19 10:04:24.826: ISAKMP:(0): sending packet to 192.168.0.2 my_port 
    500 peer_port 500 (I) MM_NO_STATE
*Jun 19 10:04:24.826: ISAKMP:(0):Sending an IKE IPv4 Packet.
*Jun 19 10:04:24.827: ISAKMP (0): received packet from 192.168.0.2 dport 
    500 sport 500 Global (I) MM_NO_STATE
*Jun 19 10:04:24.827: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
*Jun 19 10:04:24.827: ISAKMP:(0):Old State = IKE_I_MM1  New State = 
    IKE_I_MM2

*Jun 19 10:04:24.827: ISAKMP:(0): processing SA payload. message ID = 0
*Jun 19 10:04:24.827: ISAKMP:(0): processing vendor id payload
*Jun 19 10:04:24.827: ISAKMP:(0): vendor ID seems Unity/DPD but major 69 
    mismatch
*Jun 19 10:04:24.827: ISAKMP (0): vendor ID is NAT-T RFC 3947
*Jun 19 10:04:24.827: ISAKMP:(0):Found ADDRESS key in keyring keyring2
*Jun 19 10:04:24.827: ISAKMP:(0): local preshared key found
*Jun 19 10:04:24.827: ISAKMP : Looking for xauth in profile profile2
*Jun 19 10:04:24.827: ISAKMP:(0):Checking ISAKMP transform 1 against 
    priority 10 policy
*Jun 19 10:04:24.827: ISAKMP:      encryption 3DES-CBC
*Jun 19 10:04:24.827: ISAKMP:      hash MD5
*Jun 19 10:04:24.827: ISAKMP:      default group 2
*Jun 19 10:04:24.827: ISAKMP:      auth pre-share
*Jun 19 10:04:24.827: ISAKMP:      life type in seconds
*Jun 19 10:04:24.827: ISAKMP:      life duration (VPI) of  0x0 0x1 0x51 0x80
*Jun 19 10:04:24.827: ISAKMP:(0):atts are acceptable. Next payload is 0
*Jun 19 10:04:24.827: ISAKMP:(0):Acceptable atts:actual life: 0
*Jun 19 10:04:24.827: ISAKMP:(0):Acceptable atts:life: 0
*Jun 19 10:04:24.827: ISAKMP:(0):Fill atts in sa vpi_length:4
*Jun 19 10:04:24.827: ISAKMP:(0):Fill atts in sa life_in_seconds:86400
*Jun 19 10:04:24.827: ISAKMP:(0):Returning Actual lifetime: 86400
*Jun 19 10:04:24.827: ISAKMP:(0)::Started lifetime timer: 86400.

*Jun 19 10:04:24.827: ISAKMP:(0): processing vendor id payload
*Jun 19 10:04:24.827: ISAKMP:(0): vendor ID seems Unity/DPD but major 69 
    mismatch
*Jun 19 10:04:24.827: ISAKMP (0): vendor ID is NAT-T RFC 3947
*Jun 19 10:04:24.827: ISAKMP:(0):Input = IKE_MESG_INTERNAL, 
    IKE_PROCESS_MAIN_MODE
*Jun 19 10:04:24.827: ISAKMP:(0):Old State = IKE_I_MM2  New State = 
    IKE_I_MM2 

*Jun 19 10:04:24.828: ISAKMP:(0): sending packet to 192.168.0.2 my_port 
    500 peer_port 500 (I) MM_SA_SETUP

From the outset, R1 knows that ISAKMP profile2 should be used because it is bound under the IPSec profile used for that VTI.

Thus, the correct keyring (keyring2) has been selected. The pre-shared key from keyring2 is used as the keying material for DH calculations when the MM3 packet is being prepared.

When R2 receives that MM3 packet, it still does not know which ISAKMP profile should be used, but it needs a pre-shared key for DH generation. That is why R2 searches all keyrings in order to find the pre-shared key for that peer:

*Jun 19 10:04:24.828: ISAKMP (0): received packet from 192.168.0.1 dport 
    500 sport 500 Global (R) MM_SA_SETUP
*Jun 19 10:04:24.828: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
*Jun 19 10:04:24.828: ISAKMP:(0):Old State = IKE_R_MM2  New State = 
    IKE_R_MM3

*Jun 19 10:04:24.828: ISAKMP:(0): processing KE payload. message ID = 0
*Jun 19 10:04:24.831: ISAKMP:(0): processing NONCE payload. message ID = 0
*Jun 19 10:04:24.831: ISAKMP:(0):found peer pre-shared key matching 
    192.168.0.1

The key for 192.168.0.1 has been found in the first defined keyring (keyring1).

R2 then prepares the MM4 packet with DH calculations and with the 'cisco' key from keyring1:

*Jun 19 10:04:24.831: ISAKMP:(1011): processing vendor id payload
*Jun 19 10:04:24.831: ISAKMP:(1011): vendor ID is DPD
*Jun 19 10:04:24.831: ISAKMP:(1011): processing vendor id payload
*Jun 19 10:04:24.831: ISAKMP:(1011): speaking to another IOS box!
*Jun 19 10:04:24.831: ISAKMP:(1011): processing vendor id payload
*Jun 19 10:04:24.831: ISAKMP:(1011): vendor ID seems Unity/DPD but major 
    32 mismatch
*Jun 19 10:04:24.831: ISAKMP:(1011): vendor ID is XAUTH
*Jun 19 10:04:24.831: ISAKMP:received payload type 20
*Jun 19 10:04:24.831: ISAKMP (1011): His hash no match - this node 
    outside NAT
*Jun 19 10:04:24.831: ISAKMP:received payload type 20
*Jun 19 10:04:24.831: ISAKMP (1011): No NAT Found for self or peer
*Jun 19 10:04:24.831: ISAKMP:(1011):Input = IKE_MESG_INTERNAL, 
    IKE_PROCESS_MAIN_MODE
*Jun 19 10:04:24.831: ISAKMP:(1011):Old State = IKE_R_MM3  New State = 
    IKE_R_MM3

*Jun 19 10:04:24.831: ISAKMP:(1011): sending packet to 192.168.0.1 my_port 
    500 peer_port 500 (R) MM_KEY_EXCH
*Jun 19 10:04:24.831: ISAKMP:(1011):Sending an IKE IPv4 Packet.

When R1 receives MM4, it prepares the MM5 packet with IKEID and with the correct key selected earlier (from keyring2):

*Jun 19 10:04:24.831: ISAKMP (0): received packet from 192.168.0.2 dport 
    500 sport 500 Global (I) MM_SA_SETUP
*Jun 19 10:04:24.831: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
*Jun 19 10:04:24.831: ISAKMP:(0):Old State = IKE_I_MM3  New State = 
    IKE_I_MM4

*Jun 19 10:04:24.831: ISAKMP:(0): processing KE payload. message ID = 0
*Jun 19 10:04:24.837: ISAKMP:(0): processing NONCE payload. message ID = 0
*Jun 19 10:04:24.837: ISAKMP:(0):Found ADDRESS key in keyring keyring2
*Jun 19 10:04:24.837: ISAKMP:(1011): processing vendor id payload
*Jun 19 10:04:24.837: ISAKMP:(1011): vendor ID is Unity
*Jun 19 10:04:24.837: ISAKMP:(1011): processing vendor id payload
*Jun 19 10:04:24.837: ISAKMP:(1011): vendor ID is DPD
*Jun 19 10:04:24.837: ISAKMP:(1011): processing vendor id payload
*Jun 19 10:04:24.837: ISAKMP:(1011): speaking to another IOS box!
*Jun 19 10:04:24.837: ISAKMP:received payload type 20
*Jun 19 10:04:24.838: ISAKMP (1011): His hash no match - this node 
    outside NAT
*Jun 19 10:04:24.838: ISAKMP:received payload type 20
*Jun 19 10:04:24.838: ISAKMP (1011): No NAT Found for self or peer
*Jun 19 10:04:24.838: ISAKMP:(1011):Input = IKE_MESG_INTERNAL, 
    IKE_PROCESS_MAIN_MODE
*Jun 19 10:04:24.838: ISAKMP:(1011):Old State = IKE_I_MM4  New State = 
    IKE_I_MM4 

*Jun 19 10:04:24.838: ISAKMP:(1011):Send initial contact
*Jun 19 10:04:24.838: ISAKMP:(1011):SA is doing pre-shared key 
    authentication using id type ID_IPV4_ADDR
*Jun 19 10:04:24.838: ISAKMP (1011): ID payload
        next-payload : 8
        type         : 1
        address      : 192.168.0.1
        protocol     : 17
        port         : 500
        length       : 12
*Jun 19 10:04:24.838: ISAKMP:(1011):Total payload length: 12
*Jun 19 10:04:24.838: ISAKMP:(1011): sending packet to 192.168.0.2 my_port 
    500 peer_port 500 (I) MM_KEY_EXCH

The MM5 packet, which contains the IKEID of 192.168.0.1, is received by R2. At this point, R2 knows to which ISAKMP profile that traffic should be bound (the match identity addresscommand):

*Jun 19 10:04:24.838: ISAKMP (1011): received packet from 192.168.0.1 dport 
    500 sport 500 Global (R) MM_KEY_EXCH
*Jun 19 10:04:24.838: ISAKMP:(1011):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
*Jun 19 10:04:24.838: ISAKMP:(1011):Old State = IKE_R_MM4  New State = 
    IKE_R_MM5

*Jun 19 10:04:24.838: ISAKMP:(1011): processing ID payload. message ID = 0
*Jun 19 10:04:24.838: ISAKMP (1011): ID payload
        next-payload : 8
        type         : 1
        address      : 192.168.0.1
        protocol     : 17
        port         : 500
        length       : 12
*Jun 19 10:04:24.838: ISAKMP:(0):: peer matches profile1 profile
*Jun 19 10:04:24.838: ISAKMP:(1011):Found ADDRESS key in keyring keyring1
*Jun 19 10:04:24.838: ISAKMP:(1011): processing HASH payload. message ID = 0
*Jun 19 10:04:24.838: ISAKMP:(1011): processing NOTIFY INITIAL_CONTACT 
    protocol 1
        spi 0, message ID = 0, sa = 0xF46295E8
*Jun 19 10:04:24.838: ISAKMP:(1011):SA authentication status:
        authenticated
*Jun 19 10:04:24.838: ISAKMP:(1011):SA has been authenticated with 
    192.168.0.1
*Jun 19 10:04:24.838: ISAKMP:(1011):SA authentication status:
        authenticated

R2 now performs verification if the keyring that was been blindly selected for the MM4 packet is the same as the keyring configured for ISAKMP profile now chosen. Because keyring1 is the first one in the configuration, it was selected previously, and it is selected now. The validation is successful, and the MM6 packet can be sent:

*Jun 19 10:04:24.838: ISAKMP:(1011):SA is doing pre-shared key 
    authentication using id type ID_IPV4_ADDR
*Jun 19 10:04:24.838: ISAKMP (1011): ID payload
        next-payload : 8
        type         : 1
        address      : 192.168.0.2
        protocol     : 17
        port         : 500
        length       : 12
*Jun 19 10:04:24.838: ISAKMP:(1011):Total payload length: 12
*Jun 19 10:04:24.838: ISAKMP:(1011): sending packet to 192.168.0.1 
    my_port 500 peer_port 500 (R) MM_KEY_EXCH
*Jun 19 10:04:24.838: ISAKMP:(1011):Sending an IKE IPv4 Packet.
*Jun 19 10:04:24.838: ISAKMP:(1011):Input = IKE_MESG_INTERNAL, 
    IKE_PROCESS_COMPLETE
*Jun 19 10:04:24.838: ISAKMP:(1011):Old State = IKE_R_MM5  New State = 
    IKE_P1_COMPLETE

R1 receives MM6 and does not need to perform verification of the keyring because it was known from the first packet; the initiator always know which ISAKMP profile to use and what keyring is associated with that profile. The authentication is successful, and Phase1 finishes correctly:

*Jun 19 10:04:24.838: ISAKMP (1011): received packet from 192.168.0.2 
    dport 500 sport 500 Global (I) MM_KEY_EXCH
*Jun 19 10:04:24.838: ISAKMP:(1011): processing ID payload. message ID = 0
*Jun 19 10:04:24.838: ISAKMP (1011): ID payload
        next-payload : 8
        type         : 1
        address      : 192.168.0.2
        protocol     : 17
        port         : 500
        length       : 12
*Jun 19 10:04:24.838: ISAKMP:(1011): processing HASH payload. message ID = 0
*Jun 19 10:04:24.838: ISAKMP:(1011):SA authentication status:
        authenticated
*Jun 19 10:04:24.838: ISAKMP:(1011):SA has been authenticated with 
    192.168.0.2
*Jun 19 10:04:24.838: ISAKMP AAA: Accounting is not enabled
*Jun 19 10:04:24.838: ISAKMP:(1011):Input = IKE_MESG_FROM_PEER, 
    IKE_MM_EXCH
*Jun 19 10:04:24.839: ISAKMP:(1011):Old State = IKE_I_MM5  New State = 
    IKE_I_MM6

*Jun 19 10:04:24.839: ISAKMP:(1011):Input = IKE_MESG_INTERNAL, 
    IKE_PROCESS_MAIN_MODE
*Jun 19 10:04:24.839: ISAKMP:(1011):Old State = IKE_I_MM6  New State = 
    IKE_I_MM6

*Jun 19 10:04:24.843: ISAKMP:(1011):Input = IKE_MESG_INTERNAL, 
    IKE_PROCESS_COMPLETE
*Jun 19 10:04:24.843: ISAKMP:(1011):Old State = IKE_I_MM6  New State = 
    IKE_P1_COMPLETE

*Jun 19 10:04:24.843: ISAKMP:(1011):beginning Quick Mode exchange, M-ID 
    of 2816227709

Phase2 starts normally and is successfully completed.

This scenario works correctly only because of the correct order of keyrings defined on R2. The profile that should be used for the VPN session uses the keyring that was first in the configuration.

R2 As IKE Initiator (Incorrect)

This scenario describes what occurs when R2 initiates the same tunnel and explains why the tunnel will not be established. Some logs have been removed in order to focus on the differences between this and the previous example:

R2 initiates the tunnel:

R2#ping 192.168.100.1 source lo0 repeat 1

Since R2 is the initiator, the ISAKMP profile and keyring are known. The pre-shared key from keyring1 is used for DH computations and is sent in MM3. R2 is receiving MM2 and is preparing MM3 based on that key:

*Jun 19 12:28:44.256: ISAKMP (0): received packet from 192.168.0.1 dport 
    500 sport 500 Global (I) MM_NO_STATE
*Jun 19 12:28:44.256: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
*Jun 19 12:28:44.256: ISAKMP:(0):Old State = IKE_I_MM1  New State = 
    IKE_I_MM2

*Jun 19 12:28:44.256: ISAKMP:(0): processing SA payload. message ID = 0
*Jun 19 12:28:44.256: ISAKMP:(0): processing vendor id payload
*Jun 19 12:28:44.256: ISAKMP:(0): vendor ID seems Unity/DPD but major 
    69 mismatch
*Jun 19 12:28:44.256: ISAKMP (0): vendor ID is NAT-T RFC 3947
*Jun 19 12:28:44.256: ISAKMP:(0):Found ADDRESS key in keyring keyring1
*Jun 19 12:28:44.256: ISAKMP:(0): local preshared key found
*Jun 19 12:28:44.256: ISAKMP : Looking for xauth in profile profile1
*Jun 19 12:28:44.256: ISAKMP:(0):Checking ISAKMP transform 1 against 
    priority 10 policy
*Jun 19 12:28:44.256: ISAKMP:      encryption 3DES-CBC
*Jun 19 12:28:44.256: ISAKMP:      hash MD5
*Jun 19 12:28:44.256: ISAKMP:      default group 2
*Jun 19 12:28:44.256: ISAKMP:      auth pre-share
*Jun 19 12:28:44.256: ISAKMP:      life type in seconds
*Jun 19 12:28:44.256: ISAKMP:      life duration (VPI) of  0x0 0x1 
    0x51 0x80
*Jun 19 12:28:44.256: ISAKMP:(0):atts are acceptable. Next payload is 0
*Jun 19 12:28:44.256: ISAKMP:(0):Acceptable atts:actual life: 0
*Jun 19 12:28:44.257: ISAKMP:(0):Acceptable atts:life: 0
*Jun 19 12:28:44.257: ISAKMP:(0):Fill atts in sa vpi_length:4
*Jun 19 12:28:44.257: ISAKMP:(0):Fill atts in sa life_in_seconds:86400
*Jun 19 12:28:44.257: ISAKMP:(0):Returning Actual lifetime: 86400
*Jun 19 12:28:44.257: ISAKMP:(0)::Started lifetime timer: 86400.

*Jun 19 12:28:44.257: ISAKMP:(0): processing vendor id payload
*Jun 19 12:28:44.257: ISAKMP:(0): vendor ID seems Unity/DPD but major 
    69 mismatch
*Jun 19 12:28:44.257: ISAKMP (0): vendor ID is NAT-T RFC 3947
*Jun 19 12:28:44.257: ISAKMP:(0):Input = IKE_MESG_INTERNAL, 
    IKE_PROCESS_MAIN_MODE
*Jun 19 12:28:44.257: ISAKMP:(0):Old State = IKE_I_MM2  New State = 
    IKE_I_MM2 

*Jun 19 12:28:44.257: ISAKMP:(0): sending packet to 192.168.0.1 my_port 
    500 peer_port 500 (I) MM_SA_SETUP

R1 receives MM3 from R2. At this stage, R1 does not know which ISAKMP profile to use, so it does not know which keyring to use. R1 thus uses the first keyring from the global configuration, which is keyring1. R1 use that pre-shared key for DH computations and sends MM4:

*Jun 19 12:28:44.263: ISAKMP:(0):found peer pre-shared key matching 
    192.168.0.2
*Jun 19 12:28:44.263: ISAKMP:(1012): processing vendor id payload
*Jun 19 12:28:44.263: ISAKMP:(1012): vendor ID is DPD
*Jun 19 12:28:44.263: ISAKMP:(1012): processing vendor id payload
*Jun 19 12:28:44.263: ISAKMP:(1012): speaking to another IOS box!
*Jun 19 12:28:44.263: ISAKMP:(1012): processing vendor id payload
*Jun 19 12:28:44.263: ISAKMP:(1012): vendor ID seems Unity/DPD but major 
    151 mismatch
*Jun 19 12:28:44.263: ISAKMP:(1012): vendor ID is XAUTH
*Jun 19 12:28:44.263: ISAKMP:received payload type 20
*Jun 19 12:28:44.263: ISAKMP (1012): His hash no match - this node 
    outside NAT
*Jun 19 12:28:44.263: ISAKMP:received payload type 20
*Jun 19 12:28:44.263: ISAKMP (1012): No NAT Found for self or peer
*Jun 19 12:28:44.263: ISAKMP:(1012):Input = IKE_MESG_INTERNAL, 
    IKE_PROCESS_MAIN_MODE
*Jun 19 12:28:44.263: ISAKMP:(1012):Old State = IKE_R_MM3  New State = 
    IKE_R_MM3
*Jun 19 12:28:44.263: ISAKMP:(1012): sending packet to 192.168.0.2 my_port
    500 peer_port 500 (R) MM_KEY_EXC

R2 receives MM4 from R1, uses the pre-shared key from keyring1 in order to compute DH, and prepares the MM5 packet and the IKEID:

*Jun 19 12:28:44.269: ISAKMP:(0):Found ADDRESS key in keyring keyring1
*Jun 19 12:28:44.269: ISAKMP:(1012): processing vendor id payload
*Jun 19 12:28:44.269: ISAKMP:(1012): vendor ID is Unity
*Jun 19 12:28:44.269: ISAKMP:(1012): processing vendor id payload
*Jun 19 12:28:44.269: ISAKMP:(1012): vendor ID is DPD
*Jun 19 12:28:44.269: ISAKMP:(1012): processing vendor id payload
*Jun 19 12:28:44.269: ISAKMP:(1012): speaking to another IOS box!
*Jun 19 12:28:44.269: ISAKMP:received payload type 20
*Jun 19 12:28:44.269: ISAKMP (1012): His hash no match - this node 
    outside NAT
*Jun 19 12:28:44.269: ISAKMP:received payload type 20
*Jun 19 12:28:44.269: ISAKMP (1012): No NAT Found for self or peer
*Jun 19 12:28:44.269: ISAKMP:(1012):Input = IKE_MESG_INTERNAL, 
    IKE_PROCESS_MAIN_MODE
*Jun 19 12:28:44.269: ISAKMP:(1012):Old State = IKE_I_MM4  New State = 
    IKE_I_MM4

*Jun 19 12:28:44.270: ISAKMP:(1012):SA is doing pre-shared key 
    authentication using id type ID_IPV4_ADDR
*Jun 19 12:28:44.270: ISAKMP (1012): ID payload
        next-payload : 8
        type         : 1
        address      : 192.168.0.2
        protocol     : 17
        port         : 500
        length       : 12
*Jun 19 12:28:44.270: ISAKMP:(1012):Total payload length: 12
*Jun 19 12:28:44.270: ISAKMP:(1012): sending packet to 192.168.0.1 
    my_port 500 peer_port 500 (I) MM_KEY_EXCH

R1 receives MM5 from R1. Because the IKEID equals 192.168.0, profile2 has been selected. Keyring2 has been configured in profile2 so keyring2 is selected. Previously, for the DH computation in MM4, R1 selected the first configured keyring, which was keyring1. Even though the passwords are exactly the same, the validation for the keyring fails because these are different keyring objects:

*Jun 19 12:28:44.270: ISAKMP (1012): received packet from 192.168.0.2 
    dport 500 sport 500 Global (R) MM_KEY_EXCH
*Jun 19 12:28:44.270: ISAKMP:(1012):Input = IKE_MESG_FROM_PEER, 
    IKE_MM_EXCH
*Jun 19 12:28:44.270: ISAKMP:(1012):Old State = IKE_R_MM4  New State = 
    IKE_R_MM5

*Jun 19 12:28:44.270: ISAKMP:(1012): processing ID payload. message ID = 0
*Jun 19 12:28:44.270: ISAKMP (1012): ID payload
        next-payload : 8
        type         : 1
        address      : 192.168.0.2
        protocol     : 17
        port         : 500
        length       : 12
*Jun 19 12:28:44.270: ISAKMP:(0):: peer matches profile2 profile
*Jun 19 12:28:44.270: ISAKMP:(1012):Found ADDRESS key in keyring keyring2
*Jun 19 12:28:44.270: ISAKMP:(1012):Key not found in keyrings of profile ,
    aborting exchange
*Jun 19 12:28:44.270: ISAKMP (1012): FSM action returned error: 2

Debugs for Different Pre-Shared Key

The previous scenarios used the same key ('cisco'). Thus, even when the incorrect keyring was used, the MM5 packet could be decrypted correctly and dropped later because of keyring validation failure.

In scenarios where different keys are used, MM5 cannot be decrypted, and this error message appears:

*Jul 16 20:21:25.317: ISAKMP (1004): received packet from 192.168.0.2 dport 
    500 sport 500 Global (R) MM_KEY_EXCH
*Jul 16 20:21:25.317: ISAKMP: reserved not zero on ID payload!
*Jul 16 20:21:25.317: %CRYPTO-4-IKMP_BAD_MESSAGE: IKE message from 192.168.0.2 
    failed its sanity check or is malformed

Keyring Selection Criteria

This is a summary of the keyring selection criteria. See the next sections for additional details.

	Initiator	Responder
Multiple keyrings with different IP addresses	Configured. If not explicitly configured the most specific from the configuration	The most specific match
Multiple keyrings with the same IP addresses	Configured. If not explicitly configured configuration becomes unpredictable and not supported. One should not configure two keys for the same IP address.	Configuration becomes unpredictable and not supported. One should not configure two keys for the same IP address.

This section also describes why the presence of both a default keyring (global configuration) and specific keyrings might lead to problems and explains why use of the IKEv2 protocol avoids such problems.

Keyring Selection Order on IKE Initiator

For configuration with a VTI, the initiator uses a specific tunnel interface that points to specific IPSec profile. Because the IPSec profile uses a specific IKE profile with a specific keyring, there is no confusion over which keyring to use.

Crypto-map, which also points to a specific IKE profile with a specific keyring, functions in the same way.

However, it is not always possible to determine from the configuration which keyring to use. For example, this occurs when there is no IKE profile configured - that is, the IPSec profile is not configured in order to use IKE profile:

crypto keyring keyring1
  pre-shared-key address 192.168.0.0 255.255.255.0 key cisco
crypto keyring keyring2
  pre-shared-key address 192.168.0.2 key cisco

crypto ipsec transform-set TS esp-aes esp-sha256-hmac
 mode tunnel

crypto ipsec profile profile1
 set transform-set TS

interface Tunnel1
 ip address 10.0.0.1 255.255.255.0
 tunnel source Ethernet0/0
 tunnel destination 192.168.0.2
 tunnel protection ipsec profile profile1

If this IKE initiator tries to send MM1, it will choose the most specific keyring:

*Oct  7 08:13:58.413: ISAKMP: Locking peer struct 0xF4803B88, refcount 1 for 
    isakmp_initiator
*Oct  7 08:13:58.413: ISAKMP:(0):Can not start Aggressive mode, trying Main mode.
*Oct  7 08:13:58.413: ISAKMP:(0):key for 192.168.0.2 not available in default
*Oct  7 08:13:58.413: ISAKMP:(0):key for 192.168.0.2 found in keyring1
*Oct  7 08:13:58.413: ISAKMP:(0):ISAKMP: Selecting  192.168.0.0,255.255.255.0 
    as  key
*Oct  7 08:13:58.413: ISAKMP:(0):key for 192.168.0.2 found in keyring2
*Oct  7 08:13:58.413: ISAKMP:(0):ISAKMP: Selecting  192.168.0.2,255.255.255.255
    as final key
*Oct  7 08:13:58.413: ISAKMP:(0):found peer pre-shared key matching 192.168.0.2

Since the initiator has no IKE profiles configured when it receives MM6, it will not hit a profile and will complete with successful authentication and Quick Mode (QM):

Oct  7 08:13:58.428: ISAKMP:(0):: peer matches *none* of the profiles
*Oct  7 08:13:58.428: ISAKMP:(1005): processing HASH payload. message ID = 0
*Oct  7 08:13:58.428: ISAKMP:(1005):SA authentication status:
        authenticated
*Oct  7 08:13:58.432: ISAKMP:(1005):Input = IKE_MESG_INTERNAL, 
    IKE_PROCESS_COMPLETE

Keyring Selection Order on IKE Responder - Different IP Addresses

The problem with keyring selection is on the responder. When keyrings use different IP addresses, the selection order is simple.

Assume the IKE responder has this configuration:

crypto keyring keyring1
  pre-shared-key address 192.168.0.0 255.255.0.0 key cisco
crypto keyring keyring2
  pre-shared-key address 192.168.0.2 key cisco2

When this responder receives the MM1 packet from the IKE initiator with IP address 192.168.0.2, it will choose the best (most specific) match, even when the order in the configuration is different.

The criteria for selection order are:

Only keys with an IP address are considered.
The virtual routing and forwarding (VRF) of the incoming packet is checked (front end VRF [fVRF]).
If the packet is in the default VRF, the global keyring is checked first. The most precise key (netmask length) is selected.
If no key is found in the default keyring, all keyrings that match this fVRF are concatenated.
The most precise key (longest netmask) is matched. For example, a /32 is preferred over a /24.

The debugs confirm the selection:

R1#debug crypto isakmp detail
Crypto ISAKMP internals debugging is on

*Oct  2 11:57:13.301: ISAKMP:(0):key for 192.168.0.2 not available in default
*Oct  2 11:57:13.301: ISAKMP:(0):key for 192.168.0.2 found in keyring1
*Oct  2 11:57:13.301: ISAKMP:(0):ISAKMP: Selecting  192.168.0.0,255.255.255.0 
    as  key
*Oct  2 11:57:13.301: ISAKMP:(0):key for 192.168.0.2 found in keyring2
*Oct  2 11:57:13.301: ISAKMP:(0):ISAKMP: Selecting  192.168.0.2,255.255.255.255
    as final key

Keyring Selection Order on IKE Responder - Same IP Addresses

When keyrings uses the same IP addresses, problems occur. Assume the IKE responder has this configuration:

crypto keyring keyring1
  pre-shared-key address 192.168.0.2 key cisco
crypto keyring keyring2
  pre-shared-key address 192.168.0.2 key cisco

This configuration becomes unpredictable and not supported. One should not configure two keys for the same IP address or the problem described in R2 As IKE Initiator (Incorrect) will occur.

Keyring Global Configuration

ISAKMP keys defined in the global configuration belong to the default keyring:

crypto keyring keyring1
  pre-shared-key address 192.168.0.0 255.255.0.0 key cisco
crypto keyring keyring2
  pre-shared-key address 192.168.0.2 key cisco2
crypto isakmp key cisco3 address 0.0.0.0

Even though the ISAKMP key is last in the configuration, it is processed as the first on the IKE responder:

R1#show crypto isakmp key 
Keyring      Hostname/Address                            Preshared Key

default      0.0.0.0        [0.0.0.0]                    cisco3

keyring1     192.168.0.0    [255.255.0.0]                cisco

keyring2     192.168.0.2                                 cisco2

Thus, the use of both global configuration and specific keyrings is very risky and might lead to the problems.

Keyring on IKEv2 - Problem Does Not Occur

Although the IKEv2 protocol uses similar concepts to IKEv1, keyring selection does not cause similar problems.

In simple cases, there are just four packets exchanged. The IKEID that determines which IKEv2 profile should be selected on the responder is sent by the initiator in the third packet. The third packet is already encrypted.

The biggest difference in the two protocols is that IKEv2 uses only the DH result for skey computation. The pre-shared key is no longer necessary in order to compute the skey used for encryption/decryption.

The IKEv2 RFC (5996, section 2.14) , states:

The shared keys are computed as follows. A quantity called SKEYSEED is calculated from the nonces exchanged during the IKE_SA_INIT exchange and the Diffie-Hellman shared secret established during that exchange.

In the same section, the RFC also notes:

SKEYSEED = prf(Ni | Nr, g^ir)

All of the necessary information is sent in the first two packets, and there is no need to use a pre-shared key when SKEYSEED is calculated.

Compare this with the IKE RFC (2409, section 3.2) , which states:

SKEYID is a string derived from secret material known only to the active players in the exchange.

That "secret material known only to the active players" is the pre-shared key. In section 5, the RFC also notes:

For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b | Nr_b)

This explains why the IKEv1 design for pre-shared keys causes so many problems. These problems do not exist in IKEv1 when certificates are used for authentication.

IKE Profile Selection Criteria

This is a summary of the IKE profile selection criteria. See the next sections for additional details.

	Initiator	Responder
Profile selection	It should be configured (set in IPSec profile or in crypto map). If not configured, first match from the configuration. Remote peer should match only one specific ISAKMP profile, if the peer identity is matched in two ISAKMP profiles, the configuration is invalid.	First match from the configuration. Remote peer should match only one specific ISAKMP profile, if the peer identity is matched in two ISAKMP profiles, the configuration is invalid.

Initiator

Responder

Profile selection

It should be configured (set in IPSec profile or in crypto map). If not configured, first match from the configuration.

Remote peer should match only one specific ISAKMP profile, if the peer identity is matched in two ISAKMP profiles, the configuration is invalid.

First match from the configuration.

Remote peer should match only one specific ISAKMP profile, if the peer identity is matched in two ISAKMP profiles, the configuration is invalid.

This section also describes the typical errors that occur when an incorrect profile was selected.

IKE Profile Selection Order on IKE Initiator

The VTI interface usually points to a specific IPSec profile with a specific IKE profile. The router then knows which IKE profile to use.

Similarly, the crypto-map points to a specific IKE profile, and the router knows which profile to use because of the configuration.

However, there might be scenarios where the profile is not specified and where it is not possible to determine directly from the configuration which profile to use; in this example, no IKE profile is selected in the IPSec profile:

crypto isakmp profile profile1
   keyring keyring
   match identity address 192.168.0.0 255.255.255.0
crypto isakmp profile profile2
   keyring keyring
   match identity address 192.168.0.2 255.255.255.255

crypto ipsec transform-set TS esp-aes esp-sha256-hmac
 mode tunnel

crypto ipsec profile profile1
 set transform-set TS

interface Tunnel1
 ip address 10.0.0.1 255.255.255.0
 tunnel source Ethernet0/0
 tunnel destination 192.168.0.2
 tunnel protection ipsec profile profile1

When this initiator tries to send an MM1 packet to 192.168.0.2, the most specific profile is selected:

*Oct  7 07:53:46.474: ISAKMP:(0): SA request profile is profile2

IKE Profile Selection Order on IKE Responder

The profile selection order on an IKE responder is similar to the keyring selection order, where the most specific takes precedence.

Assume this configuration:

crypto isakmp profile profile1
   keyring keyring
   match identity address 192.168.0.0 255.255.255.0
crypto isakmp profile profile2
   keyring keyring
   match identity address 192.168.0.1 255.255.255.255

When a connection from 192.168.0.1 is received, profile2 will be selected.

The order of configured profiles does not matter. The show runnning-config command places each new configured profile at the end of the list.

Sometimes the responder might have two IKE profiles that use the same keyring. If an incorrect profile is selected on the responder but the selected keyring is correct, the authentication will finish correctly:

*Oct  7 06:46:39.893: ISAKMP:(1003): processing ID payload. message ID = 0
*Oct  7 06:46:39.893: ISAKMP (1003): ID payload
        next-payload : 8
        type         : 1
        address      : 192.168.0.1
        protocol     : 17
        port         : 500
        length       : 12
*Oct  7 06:46:39.893: ISAKMP:(0):: peer matches profile2 profile
*Oct  7 06:46:39.893: ISAKMP:(0):key for 192.168.0.1 not available in default
*Oct  7 06:46:39.893: ISAKMP:(0):key for 192.168.0.1 found in keyring
*Oct  7 06:46:39.893: ISAKMP:(0):ISAKMP: Selecting  192.168.0.1,255.255.255.255
    as final key

*Oct  7 06:46:39.893: ISAKMP:(1003):SA authentication status:
        authenticated
*Oct  7 06:46:39.893: ISAKMP:(1003):SA has been authenticated with 192.168.0.1
*Oct  7 06:46:39.893: ISAKMP:(1003):SA authentication status:
        authenticated

*Oct  7 06:46:39.893: ISAKMP:(1003):Old State = IKE_R_MM5  New State = 
    IKE_P1_COMPLETE

The responder receives and accepts the QM proposal and tries to generate the IPSec Security Parameter Indexes (SPIs). In this example, some debugs were removed for clarity:

*Oct  7 06:46:39.898: ISAKMP:(1003):Checking IPSec proposal 1
*Oct  7 06:46:39.898: ISAKMP:(1003):atts are acceptable.
*Oct  7 06:46:39.898: IPSEC(validate_proposal_request): proposal part #1

At this point, the responder fails and reports that the correct ISAKMP profile did not match:

 (key eng. msg.) INBOUND local= 192.168.0.2:0, remote= 192.168.0.1:0,
    local_proxy= 192.168.0.2/255.255.255.255/47/0,
    remote_proxy= 192.168.0.1/255.255.255.255/47/0,
    protocol= ESP, transform= NONE  (Tunnel),
    lifedur= 0s and 0kb,
    spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x0
*Oct  7 06:46:39.898: map_db_check_isakmp_profile profile did not match
*Oct  7 06:46:39.898: Crypto mapdb : proxy_match
        src addr     : 192.168.0.2
        dst addr     : 192.168.0.1
        protocol     : 47
        src port     : 0
        dst port     : 0
*Oct  7 06:46:39.898: map_db_check_isakmp_profile profile did not match
*Oct  7 06:46:39.898: Crypto mapdb : proxy_match
        src addr     : 192.168.0.2
        dst addr     : 192.168.0.1
        protocol     : 47
        src port     : 0
        dst port     : 0
*Oct  7 06:46:39.898: map_db_check_isakmp_profile profile did not match
*Oct  7 06:46:39.898: map_db_find_best did not find matching map
*Oct  7 06:46:39.898: IPSEC(ipsec_process_proposal): proxy identities not 
    supported
*Oct  7 06:46:39.898: ISAKMP:(1003): IPSec policy invalidated proposal with 
    error 32
*Oct  7 06:46:39.898: ISAKMP:(1003): phase 2 SA policy not acceptable! 
    (local 192.168.0.2 remote 192.168.0.1)
*Oct  7 06:46:39.898: ISAKMP: set new node 1993778370 to QM_IDLE
R2#
*Oct  7 06:46:39.898: ISAKMP:(1003):Sending NOTIFY PROPOSAL_NOT_CHOSEN 
    protocol 3

Because of the incorrect IKE profile selection, error 32 is returned, and the responder sends the message PROPOSAL_NOT_CHOSEN.

Summary

For IKEv1, a pre-shared key is used with DH results in order to calculate the skey used for encryption that starts at MM5. After it receives MM3, the ISAKMP receiver is not yet able to determine which ISAKMP profile (and associated keyring) should be used because the IKEID is sent in MM5 and MM6.

The result is that the ISAKMP responder tries to search through all the globally defined keyrings in order to find the key for specific peer. For different IP addresses, the best matching keyring (the most specific) is selected; for the same IP address, the first matching keying from the configuration is used. The keyring is used in order to calculate the skey that is used for decryption of MM5.

After it receives MM5, the ISAKMP initiator determines the ISAKMP profile and associated keyring. The initiator performs verification if this is the same keyring that was selected for MM4 DH computation; otherwise, the connection fails.

The order of the keyrings configured in global configuration is critical. Thus, for the ISAKMP responder, use a single keyring with multiple entries whenever possible.

The pre-shared keys that are defined in global configuration mode belong to a predefined keyring called default. The same rules apply then.

For IKE profile selection for the responder, the most specific profile is matched. For the initiator, the profile from the configuration is used, or, if that cannot be determined, the best match is used.

A similar problem occurs in scenarios that use different certificates for different ISAKMP profiles. Authentication might fail because of 'ca trust-point' profile validation when a different certificate is chosen. This problem will be covered in a separate document.

The issues described in this article are not Cisco-specific problems, but are related to the limitations of IKEv1 protocol design. IKEv1 used with certificates does not have these limitations, and IKEv2 used for both pre-shared keys and certificates does not have these limitations.

Related Information

Contributed by Cisco Engineers

Michal Garcarz
Cisco TAC Engineer
Piotr Kupisiewicz
Cisco TAC Engineer

Was this Document Helpful?

Feedback

Contact Cisco

Open a Support Case
(Requires a Cisco Service Contract)

This Document Applies to These Products

IPSec Negotiation/IKE Protocols