Previous Page
Next Page

ISAKMP/IKE Phase 1 Connections

In the first part of this chapter I'll focus on troubleshooting ISAKMP/IKE Phase 1 connections. If you recall from Chapter 3, "IPsec," the management connections built during Phase 1 are used to pass IPsec management traffic; no data traverses these connections. These connections are important, however, because they are used to build the data connections for Phase 2.

I've broken this part of the chapter into three areas. In the first part, I discuss the commands used to troubleshoot ISAKMP/IKE Phase 1 connections; the two sections following this are specific to L2L and remote access implementations, respectively.

Overview of the Phase 1 Commands

You can use the following router commands to troubleshoot ISAKMP/IKE Phase 1 connections:

  • show crypto isakmp sa Displays the status of all management connections.

  • debug crypto isakmp Displays the steps taken to build a management connection and data connections via the management connection.

  • debug crypto pki {messages| transactions}: Displays the interaction between the router and CA for certificate enrollment and authentication functions.

  • debug crypto engine Displays events related to encrypting and decrypting packets, and applies to both Phase 1 and Phase 2 connections.

  • clear crypto isakmp [SA_ID_#] Deletes all of the specified management SAs.

The show crypto isakmp sa Command

Example 19-1 illustrates the use of the show crypto isakmp sa command. I discussed this command in Chapter 16, "Router ISAKMP/IKE Phase 1 Connectivity." Table 16-1 in that chapter explained the states. If you recall, QM_IDLE indicates the successful setup of the connection to the associated peer. If you're seeing MM_NO_STATE or AG_NO_STATE, this indicates that there is a problem with the initial setup of the connection.

Example 19-1. The show crypto isakmp sa Command
spoke1# show crypto isakmp sa
dst             src             state          conn-id slot
192.1.1.40      192.1.1.42      QM_IDLE              2    0

The two most common problems that might cause a management connection from being set up are:

  • You forgot to activate the crypto map or profile on the remote peer router's interface.

  • There is no matching ISAKMP/IKE Phase 1 policy on the remote peer.

If you see a state of MM_KEY_EXCH or AG_INIT_EXCH, probably device authentication failed. For pre-shared keys or RSA encrypted nonces, make sure you've configured the pre-shared keys correctly. For certificates, make sure:

  • The certificates haven't expired.

  • The date and time are correct on the two peers.

  • The certificates haven't been revoked.

Tip

You can use the debug crypto isakmp command for more detailed troubleshooting of the building of the management connection based on the output of the show crypto isakmp sa command.


The debug crypto isakmp Command

In most instances, you'll use the debug crypto isakmp command to assist in detailed troubleshooting of building ISAKMP/IKE Phase 1 management connections. Deciphering the output of this command is not simple. The following two sections will take a look at a few examples of L2L and remote access sessions being built.

L2L Sessions

To understand how a session is set up successfully, view the output from the debug crypto isakmp command in Example 19-2. In this example, the output is from a simple L2L configuration where the router is accepting a session from a remote peer. I've added steps to the right of some of the output, like "(1)." This is explained after the example.

Example 19-2. Successfully Building an IPsec L2L Session
ISAKMP (0:0): received packet from 192.1.1.42 dport 500 sport     (1)
      500 Global (N) NEW SA
ISAKMP: Created a peer struct for 192.1.1.42, peer port 500
ISAKMP: Locking peer struct 0x64DB0004, IKE refcount 1 for
     crypto_isakmp_process_block
ISAKMP: local port 500, remote port 500 insert sa successfully
     sa = 651706A4
ISAKMP:(0:0:N/A:0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
ISAKMP:(0:0:N/A:0):Old State = IKE_READY New State =
     IKE_R_MM1
ISAKMP:(0:0:N/A:0): processing SA payload. message ID = 0
output omitted
ISAKMP:(0:0:N/A:0):Looking for a matching key for 192.1.1.42      (2)
     in default
ISAKMP:(0:0:N/A:0): : success
ISAKMP:(0:0:N/A:0):found peer pre-shared key matching
     192.1.1.42
ISAKMP:(0:0:N/A:0): local preshared key found
ISAKMP : Scanning profiles for xauth ...
ISAKMP:(0:0:N/A:0):Checking ISAKMP transform 1 against            (3)
     priority 1 policy
ISAKMP:      encryption AES-CBC
ISAKMP:      keylength of 128
ISAKMP:      hash SHA
ISAKMP:      default group 1
ISAKMP:      auth pre-share
ISAKMP:      life type in seconds
ISAKMP:      life duration (VPI) of 0x0 0x1 0x51 0x80
ISAKMP:(0:0:N/A:0):atts are acceptable. Next payload is 0         (4)
output omitted
ISAKMP:(0:1:SW:1): sending packet to 192.1.1.42 my_port 500
     peer_port 500 (R) MM_SA_SETUP
ISAKMP (0:134217729): received packet from 192.1.1.42 dport 500   (5)
     sport 500 Global (R) MM_SA_SETUP
ISAKMP:(0:1:SW:1):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
ISAKMP:(0:1:SW:1):Old State = IKE_R_MM2 New State = IKE_R_MM3
ISAKMP:(0:1:SW:1): processing KE payload. message ID = 0
ISAKMP:(0:1:SW:1): processing NONCE payload. message ID = 0
ISAKMP:(0:0:N/A:0):Looking for a matching key for 192.1.1.42
     in default
ISAKMP:(0:0:N/A:0): : success
ISAKMP:(0:1:SW:1):found peer pre-shared key matching 192.1.1.42
ISAKMP:(0:1:SW:1):SKEYID state generated                          (6)
ISAKMP:(0:1:SW:1): processing vendor id payload
ISAKMP:(0:1:SW:1): vendor ID is Unity
ISAKMP:(0:1:SW:1): processing vendor id payload
ISAKMP:(0:1:SW:1): vendor ID is DPD
ISAKMP:(0:1:SW:1): processing vendor id payload
ISAKMP:(0:1:SW:1): speaking to another IOS box!
ISAKMP:(0:1:SW:1):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
ISAKMP:(0:1:SW:1):Old State = IKE_R_MM3 New State = IKE_R_MM3
ISAKMP:(0:1:SW:1): sending packet to 192.1.1.42 my_port 500 peer_
     port 500 (R) MM_KEY_EXCH
ISAKMP:(0:1:SW:1):Input = IKE_MESG_INTERNAL,
     IKE_PROCESS_COMPLETE
ISAKMP:(0:1:SW:1):Old State = IKE_R_MM3 New State = IKE_R_MM4
ISAKMP (0:134217729): received packet from 192.1.1.42 dport 500   (7)
     sport 500 Global (R) MM_KEY_EXCH
ISAKMP:(0:1:SW:1):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
ISAKMP:(0:1:SW:1):Old State = IKE_R_MM4 New State = IKE_R_MM5
ISAKMP:(0:1:SW:1): processing ID payload. message ID = 0
ISAKMP (0:134217729): ID payload
        next-payload : 8
        type         : 1
        address      : 192.1.1.42
        protocol     : 17
        port         : 500
        length       : 12
ISAKMP:(0:1:SW:1):: peer matches *none* of the profiles
ISAKMP:(0:1:SW:1): processing HASH payload. message ID = 0
ISAKMP:received payload type 17
ISAKMP:(0:1:SW:1): processing NOTIFY INITIAL_CONTACT protocol 1
        spi 0, message ID = 0, sa = 651706A4
ISAKMP:(0:1:SW:1):SA authentication status:                       (8)
        authenticated
ISAKMP:(0:1:SW:1): Process initial contact, bring down existing
     phase 1 and 2 SA's with local 192.1.1.40
     remote 192.1.1.42 remote port 500
ISAKMP:(0:1:SW:1):SA authentication status:
        authenticated
ISAKMP:(0:1:SW:1):SA has been authenticated with 192.1.1.42
ISAKMP: Trying to insert a peer 192.1.1.40/192.1.1.42/500/,
     and inserted successfully 64DB0004.
ISAKMP:(0:1:SW:1):IKE_DPD is enabled, initializing timers
ISAKMP:(0:1:SW:1):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
ISAKMP:(0:1:SW:1):Old State = IKE_R_MM5 New State = IKE_R_MM5
ISAKMP:(0:1:SW:1):SA is doing pre-shared key authentication
     using id type ID_IPV4_ADDR
output omitted
ISAKMP:(0:1:SW:1):Input = IKE_MESG_INTERNAL,
     IKE_PROCESS_COMPLETE
ISAKMP:(0:1:SW:1):Old State = IKE_R_MM5 New State =
     IKE_P1_COMPLETE
ISAKMP:(0:1:SW:1):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE  (9)
ISAKMP:(0:1:SW:1):Old State = IKE_P1_COMPLETE New State =
     IKE_P1_COMPLETE
ISAKMP (0:134217729): received packet from 192.1.1.42 dport 500   (10)
     sport 500 Global (R) QM_IDLE
ISAKMP: set new node 482536716 to QM_IDLE
ISAKMP:(0:1:SW:1): processing HASH payload. message ID =
     482536716
ISAKMP:(0:1:SW:1): processing SA payload. message ID = 482536716
ISAKMP:(0:1:SW:1):Checking IPsec proposal 1                       (11)
ISAKMP: transform 1, ESP_AES
ISAKMP:   attributes in transform:
ISAKMP:      encaps is 1 (Tunnel)
ISAKMP:      SA life type in seconds
ISAKMP:      SA life duration (basic) of 3600
ISAKMP:      SA life type in kilobytes
ISAKMP:      SA life duration (VPI) of 0x0 0x46 0x50 0x0
ISAKMP:      authenticator is HMAC-SHA
ISAKMP:      key length is 128
ISAKMP:(0:1:SW:1):atts are acceptable.                            (12)
output omitted
ISAKMP:(0:1:SW:1): Creating IPsec SAs                             (13)
         inbound SA from 192.1.1.42 to 192.1.1.40 (f/i) 0/ 0
        (proxy 192.168.3.0 to 192.168.2.0)
         has spi 0x705B8268 and conn_id 0 and flags 2
         lifetime of 3600 seconds
         lifetime of 4608000 kilobytes
         has client flags 0x0
         outbound SA from 192.1.1.40 to 192.1.1.42 (f/i) 0/0
        (proxy 192.168.2.0 to 192.168.3.0)
         has spi 1221163868 and conn_id 0 and flags A
         lifetime of 3600 seconds
         lifetime of 4608000 kilobytes
         has client flags 0x0
ISAKMP:(0:1:SW:1): sending packet to 192.1.1.42 my_port 500
     peer_port 500 (R) QM_IDLE
ISAKMP:(0:1:SW:1):Node 482536716, Input = IKE_MESG_FROM_IPSEC,
     IKE_SPI_REPLY
ISAKMP:(0:1:SW:1):Old State = IKE_QM_SPI_STARVE New State =
     IKE_QM_R_QM2
ISAKMP: Locking peer struct 0x64DB0004, IPSEC refcount 2 for
     from create_transforms
ISAKMP: Unlocking IPSEC struct 0x64DB0004 from create_
     transforms, count 1
ISAKMP (0:134217729): received packet from 192.1.1.42 dport 500
     sport 500 Global (R) QM_IDLE
ISAKMP:(0:1:SW:1):deleting node 482536716 error FALSE reason
     "QM done (await)"
ISAKMP:(0:1:SW:1):Node 482536716, Input = IKE_MESG_FROM_PEER,
     IKE_QM_EXCH
ISAKMP:(0:1:SW:1):Old State = IKE_QM_R_QM2 New State = IKE_QM_    (14)
     PHASE2_COMPLETE

Here's a brief description of these steps (the output is very verbose, so I've omitted some of it):

1.
Main mode exchange is beginning; no policies have been shared yet and the routers are still in an MM_NO_STATE.

2.
The router first verifies that there is a pre-shared key that matches an address of the remote peer (no authentication is done at this point).

3.
The comparison of ISAKMP/IKE policies begins here.

4.
This message indicates that a matching policy has been found.

5.
This is where authentication begins with pre-shared keys; remember that authentication occurs on both routers, and thus you'll see two sets of corresponding authentication processes.

6.
The router generates an authentication nonce to send to the remote peer.

7.
The router receives the nonce for authentication from the remote peer.

8.
The received nonce is validated and the peer is authenticated.

9.
Phase 1 is complete.

10.
Phase 2 (quick mode) begins.

11.
The router looks for a matching data transform for the data connections.

12.
A matching data transform is found for the data connections.

13.
The SAs for the data connections are built.

14.
Phase 2 completes.

Now that you have an understanding of the debug output that you'll see when an L2L IPsec session is established successfully with a peer, I'll look at some examples of output from the debug crypto isakmp command where problems exist that prevent the management connection from being established successfully.

If there is a mismatch in the ISAKMP/IKE Phase 1 policies between the peers, your debug output will look like that in Example 19-3. Likewise, in the output of the show crypto isakmp sa command, the state will be MM_NO_STATE. I've omitted a lot of the output from the debug crypto isakmp command and kept the most important parts.

Example 19-3. Mismatch ISAKMP/IKE Phase 1 Policies
output omitted
ISAKMP:(0:0:N/A:0):Checking ISAKMP transform 1 against priority   (1)
     1 policy
ISAKMP:      encryption AES-CBC
ISAKMP:      keylength of 128
ISAKMP:      hash SHA
ISAKMP:      default group 1
ISAKMP:      auth pre-share
ISAKMP:      life type in seconds
ISAKMP:      life duration (VPI) of 0x0 0x1 0x51 0x80
ISAKMP:(0:0:N/A:0):Hash algorithm offered does not match policy!
ISAKMP:(0:0:N/A:0):atts are not acceptable. Next payload is 0     (2)
ISAKMP:(0:0:N/A:0):Checking ISAKMP transform 1 against priority   (3)
      65535 policy
ISAKMP:      encryption AES-CBC
ISAKMP:      keylength of 128
ISAKMP:      hash SHA
ISAKMP:      default group 1
ISAKMP:      auth pre-share
ISAKMP:      life type in seconds
ISAKMP:      life duration (VPI) of 0x0 0x1 0x51 0x80
ISAKMP:(0:0:N/A:0):Encryption algorithm offered does not
     match policy!
ISAKMP:(0:0:N/A:0):atts are not acceptable. Next payload is 0     (4)
ISAKMP:(0:0:N/A:0):no offers accepted!
ISAKMP:(0:0:N/A:0): phase 1 SA policy not acceptable!
     (local 192.1.1.40 remote 192.1.1.42)
ISAKMP:(0:0:N/A:0):incrementing error counter on sa: construct_
     fail_ag_init
ISAKMP:(0:0:N/A:0): sending packet to 192.1.1.42 my_port 500
     peer_port 500 (R) MM_NO_STATE
ISAKMP:(0:0:N/A:0):peer does not do paranoid keepalives.
ISAKMP:(0:0:N/A:0):deleting SA reason "Phase1 SA policy      (5)
     proposal not accepted" state (R) MM_NO_STATE
     (peer 192.1.1.42)
output omitted

Here's an explanation of the debug information in Example 19-3:

1.
The router is checking the remote peer's policy 1 against the local policy 1.

2.
There is no match in the first policy comparison.

3.
The router is checking the remote peer's policy 1 against the router's local default policy.

4.
Again, there is no match with the peer's policy.

5.
The management connection is being terminated because there is no matching policy between the peers (MM_NO_STATE).

If there is a mismatch in a key used for pre-shared key authentication, the output of the debug crypto isakmp command will look like that found in Example 19-4.

Example 19-4. Mismatched Pre-Shared Key Illustration
output omitted
ISAKMP:(0:0:N/A:0):atts are acceptable. Next payload is 0         (1)
ISAKMP:(0:1:SW:1): processing vendor id payload
ISAKMP:(0:1:SW:1): vendor ID seems Unity/DPD but major
     245 mismatch
ISAKMP (0:134217729): vendor ID is NAT-T v7
ISAKMP:(0:1:SW:1): processing vendor id payload
ISAKMP:(0:1:SW:1): vendor ID seems Unity/DPD but major
     157 mismatch
ISAKMP:(0:1:SW:1): vendor ID is NAT-T v3
ISAKMP:(0:1:SW:1): processing vendor id payload
ISAKMP:(0:1:SW:1): vendor ID seems Unity/DPD but major
     123 mismatch
ISAKMP:(0:1:SW:1): vendor ID is NAT-T v2
ISAKMP:(0:1:SW:1):Input = IKE_MESG_INTERNAL, IKE_PROCESS_
     MAIN_MODE
ISAKMP:(0:1:SW:1):Old State = IKE_R_MM1 New State = IKE_R_MM1
ISAKMP:(0:1:SW:1): constructed NAT-T vendor-07 ID
ISAKMP:(0:1:SW:1): sending packet to 192.1.1.42 my_port 500
     peer_port 500 (R) MM_SA_SETUP
ISAKMP:(0:1:SW:1):Input = IKE_MESG_INTERNAL, IKE_
     PROCESS_COMPLETE
ISAKMP:(0:1:SW:1):Old State = IKE_R_MM1 New State = IKE_R_MM2
ISAKMP (0:134217729): received packet from 192.1.1.42 dport 500   (2)
     sport 500 Global (R) MM_SA_SETUP
ISAKMP:(0:1:SW:1):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
ISAKMP:(0:1:SW:1):Old State = IKE_R_MM2 New State = IKE_R_MM3
ISAKMP:(0:1:SW:1): processing KE payload. message ID = 0
ISAKMP:(0:1:SW:1): processing NONCE payload. message ID = 0
ISAKMP:(0:0:N/A:0):Looking for a matching key for 192.1.1.42 in   (3)
     default
ISAKMP:(0:0:N/A:0): : success
ISAKMP:(0:1:SW:1):found peer pre-shared key matching 192.1.1.42
ISAKMP:(0:1:SW:1):SKEYID state generated                          (4)
output omitted
ISAKMP:(0:1:SW:1): sending packet to 192.1.1.42 my_port 500       (5)
     peer_port 500 (R) MM_KEY_EXCH
ISAKMP:(0:1:SW:1):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
ISAKMP:(0:1:SW:1):Old State = IKE_R_MM3 New State = IKE_R_MM4
ISAKMP (0:134217729): received packet from 192.1.1.42 dport 500
     sport 500 Global (R) MM_KEY_EXCH
ISAKMP: reserved not zero on ID payload!                          (6)
%CRYPTO-4-IKMP_BAD_MESSAGE: IKE message from 192.1.1.42
        failed its sanity check or is malformed
ISAKMP:(0:1:SW:1):incrementing error counter on sa: PAYLOAD_
     MALFORMED
output omitted

Here's an explanation of the abbreviated output:

1.
A matching Phase 1 policy is found.

2.
Pre-shared key authentication begins by receiving the nonce (created with the pre-shared key) from the remote peer.

3.
A matching crypto isakmp key command is found for the remote peer (the IP address of the peer).

4.
The router generates a nonce to validate the authentication.

5.
This router sends its nonce information to the remote peer.

6.
Verification of the nonce fails and the keying is retried multiple times.

7.
The retry threshold is reached and the peers give up building the management connection.

When you look at the output of the show crypto isakmp sa command, the state will be MM_KEY_EXCH. The key message to look for in the output is the highlighted one in the debug output from Example 19-4, which typically indicates an authentication failure.

Tip

One of the problems I've seen with the output of Cisco debug commands is that the nomenclature and verbiage has a tendency of changing from one IOS release to another (my debug output was from a 3640 router running IOS 12.3(14)T). Therefore, you have to scrutinize the output carefully to determine the exact problem. In certain cases, you might want to look at the debug output from a connection that works from the same IOS revision that you're using and compare that to a connection that fails. You can use the successful connection output as a baseline when comparing this debug output to the debug output from a failed connection attempt to pinpoint the problem.


Remote Access Sessions

The router debug output from setting up a remote access session can be very verbose about 20 pages in length! Remember that remote access sessions, using Easy VPN, go through more steps in setting up a session than an L2L session. Example 19-5 shows the output of the debug crypto isakmp command, where I've omitted much of the output to keep it brief.

Example 19-5. Successfully Building an IPsec Remote Access Session to an Easy VPN Server
ISAKMP (0:0): received packet from 192.168.1.100 dport 500
     sport 500 Global (N) NEW SA
output omitted
ISAKMP (0:0): ID payload                                          (1)
        next-payload : 13
        type         : 11
        group id     : admin
        protocol     : 17
        port         : 500
        length       : 13
output omitted
ISAKMP:(0:0:N/A:0): Authentication by
     xauth preshared
ISAKMP:(0:0:N/A:0):Checking ISAKMP                                (2)
     transform 1 against priority 10 policy
ISAKMP:      encryption AES-CBC
ISAKMP:      hash SHA
ISAKMP:      default group 2
ISAKMP:      auth XAUTHInitPreShared
ISAKMP:      life type in seconds
ISAKMP:      life duration (VPI) of 0x0 0x20 0xC4 0x9B
ISAKMP:      keylength of 256
ISAKMP:(0:0:N/A:0):Hash algorithm offered does not match policy!
ISAKMP:(0:0:N/A:0):atts are not acceptable. Next payload is 3
output omitted
ISAKMP:(0:0:N/A:0):Checking ISAKMP transform 6 against priority
     10 policy
ISAKMP:      encryption AES-CBC
ISAKMP:      hash MD5
ISAKMP:      default group 2
ISAKMP:      auth XAUTHInitPreShared
ISAKMP:      life type in seconds
ISAKMP:      life duration (VPI) of 0x0 0x20 0xC4 0x9B
ISAKMP:      keylength of 128
ISAKMP:(0:0:N/A:0):atts are acceptable.                           (3)
ISAKMP:(0:2:SW:1): processing KE payload. message ID = 0
ISAKMP:(0:2:SW:1): processing NONCE payload. message ID = 0
output omitted
ISAKMP:(0:2:SW:1):SKEYID state generated
ISAKMP:(0:2:SW:1):SA is doing pre-shared key authentication       (4)
    plus XAUTH using id type ID_IPV4_ADDR
ISAKMP (0:134217730): ID payload next-payload : 10
        type         : 1
        address      : 192.1.1.40
        protocol     : 17
output omitted
ISAKMP (0:134217730): received packet from 192.168.1.100
     dport 500 sport 500 Global (R) AG_INIT_EXCH
ISAKMP:(0:2:SW:1): processing HASH payload. message ID = 0
ISAKMP:(0:2:SW:1): processing NOTIFY INITIAL_CONTACT protocol 1
        spi 0, message ID = 0, sa = 652680F0
ISAKMP:(0:2:SW:1):SA authentication status:                       (5)
        authenticated
output omitted
ISAKMP:(0:2:SW:1):SA has been authenticated with 192.168.1.100
output omitted
ISAKMP:(0:2:SW:1):IKE_DPD is enabled, initializing timers         (6)
output omitted
ISAKMP:(0:2:SW:1):Need XAUTH                                            (7)
ISAKMP: set new node -753458994 to CONF_XAUTH
ISAKMP/xauth: request attribute XAUTH_USER_NAME_V2
ISAKMP/xauth: request attribute XAUTH_USER_PASSWORD_V2
ISAKMP:(0:2:SW:1): initiating peer config to 192.168.1.100.
     ID= -753458994
ISAKMP:(0:2:SW:1): sending packet to 192.168.1.100 my_port 500
     peer_port 500 (R) CONF_XAUTH
output omitted
ISAKMP (0:134217730): received packet from 192.168.1.100          (8)
     dport 500 sport 500 Global (R) CONF_XAUTH
ISAKMP:(0:2:SW:1):processing transaction payload from
     192.168.1.100. message ID = -753458994
ISAKMP: Config payload REPLY
ISAKMP/xauth: reply attribute XAUTH_USER_NAME_V2
ISAKMP/xauth: reply attribute XAUTH_USER_PASSWORD_V2
ISAKMP:(0:2:SW:1):deleting node -753458994 error FALSE reason
     "Done with xauth request/reply exchange"
output omitted
ISAKMP: Config payload ACK
ISAKMP:(0:2:SW:1):       (blank) XAUTH ACK Processed              (9)
ISAKMP:(0:2:SW:1):deleting node 147119650 error FALSE reason
     "Transaction mode done"
ISAKMP:(0:2:SW:1):Input = IKE_MESG_FROM_PEER, IKE_CFG_ACK
ISAKMP:(0:2:SW:1):Old State = IKE_XAUTH_SET_SENT New State =
     IKE_P1_COMPLETE
output omitted
*Mar 1 05:06:03.199: ISAKMP (0:134217730): received packet       (10)
    from 192.168.1.100 dport 500 sport 500 Global (R) QM_IDLE
*Mar 1 05:06:03.203: ISAKMP: set new node -1691114311 to QM_IDLE
*Mar 1 05:06:03.203: ISAKMP:(0:2:SW:1):processing transaction
    payload from 192.168.1.100. message ID = -1691114311
*Mar 1 05:06:03.203: ISAKMP: Config payload REQUEST
output omitted
ISAKMP/author: Author request for group admin successfully
     sent to AAA
output omitted
ISAKMP:(0:2:SW:1):allocating address 192.168.0.222               (11)
ISAKMP: Sending private address: 192.168.0.222
ISAKMP: Sending subnet mask: 255.255.255.0
ISAKMP: Sending IP4_DNS server address: 192.168.0.10
ISAKMP: Sending IP4_NBNS server address: 192.168.0.12
ISAKMP: Sending ADDRESS_EXPIRY seconds left to use the address:
    86395
ISAKMP (0/134217730): Unknown Attr: UNKNOWN (0x7000)
ISAKMP: Sending save password reply value 0
Sending DEFAULT_DOMAIN default domain name: cisco.com
ISAKMP: Sending split include name splitremote network
     192.168.0.0 mask 255.255.255.0 protocol 0, src port 0,
     dst port 0
ISAKMP: Sending SPLIT_DNS domain name: cisco.com
output omitted
ISAKMP:(0:2:SW:1):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE (12)
ISAKMP:(0:2:SW:1):Old State = IKE_P1_COMPLETE New State = IKE_
     P1_COMPLETE
ISAKMP (0:134217730): received packet                            (13)
     from 192.168.1.100 dport 500 sport 500 Global (R) QM_IDLE
output omitted
ISAKMP:(0:2:SW:1): processing SA payload.
ISAKMP:(0:2:SW:1):Checking IPsec proposal 1
ISAKMP: transform 1, ESP_AES
ISAKMP:   attributes in transform:
ISAKMP:      authenticator is HMAC-MD5
ISAKMP:      key length is 256
ISAKMP:      encaps is 1 (Tunnel)
ISAKMP:      SA life type in seconds
ISAKMP:      SA life duration (VPI) of 0x0 0x20 0xC4 0x9B
ISAKMP:(0:2:SW:1):atts are acceptable.                           (14)
output omitted
ISAKMP:(0:2:SW:1): Creating IPsec SAs                            (15)
         inbound SA from 192.168.1.100 to 192.1.1.40 (f/i) 0/ 0
        (proxy 192.168.0.222 to 0.0.0.0)
         has spi 0x213909D3 and conn_id 0 and flags 2
         lifetime of 2147483 seconds
         has client flags 0x0
         outbound SA from 192.1.1.40 to 192.168.1.100 (f/i) 0/0
        (proxy 0.0.0.0 to 192.168.0.222)
         has spi 2072708995 and conn_id 0 and flags A
         lifetime of 2147483 seconds
         has client flags 0x0
output omitted
*Mar 1 05:06:03.367: ISAKMP:(0:2:SW:1):Old State = IKE_QM_R_     (16)
    QM2 New State = IKE_QM_ PHASE2_COMPLETE
output omitted

Here's an explanation of the debug output from Example 19-5:

1.
The Easy VPN Remote (client) establishes a connection to an Easy VPN Server (the router) and specifies that it wants to access the "admin" group.

2.
The first policy for Phase 1 didn't match the Remote's list of policies.

3.
After a few comparisons of Phase 1 policies, a match was found.

4.
Group authentication begins for the "admin" group using pre-shared keys.

5.
The group authentication is successful.

6.
DPD is enabled.

7.
XAUTH has been enabled on the Easy VPN Server and the Server prompts the user for a username and password.

8.
The Server receives the username and password from the Remote.

9.
User authentication is successful; if it wasn't successful, you would see a debug line with retransmitting Phase 2 CONF_XAUTH in it, where the Server is retransmitting the XAUTH username and password query.

10.
The Remote initiates IKE Mode Config.

11.
The Remote is assigned his policies, of which one is his IP address: 192.168.0.222. If the user can't be assigned an IP address, you'll see the following debug message: deleting SA reason"Failed to allocate ip address."

12.
This completes ISAKMP/IKE Phase 1.

13.
In Phase 2, a matching data transform is searched.

14.
A matching data transform is found.

15.
The two IPsec SAs (inbound and outbound) are created for the data connections.

16.
Phase 2 has completed.

The debug crypto pki Command

The debug crypto pki command is used to troubleshoot the interaction between a CA and a router. You must specify one of two parameters: messages or transactions. The messages parameter basically prints a dump of the message contents sent between the router and CA and is of use only to Cisco personnel. The transactions parameter, however, is useful, because it displays the events that occur. Example 19-6 illustrates the use of this command. In this example, an administrator is requesting the root certificate (the crypto ca authenticate command) and then the identity certificate (the crypto ca enroll command) for his router. As you can see from the URI, the CA server is a Microsoft product. I've used this command to troubleshoot date/time issues when validating a certificate the router receives from the CA.

Example 19-6. Troubleshooting the Certificate Enrollment Process
RTRA(config)# crypto ca authenticate caserver
Certificate has the following attributes:
Fingerprint:A5DE3C51 AD8B0207 B60BED6D 9356FB00
00:44:00:CRYPTO_PKI:Sending CA Certificate Request:
GET /certsrv/mscep/mscep.dll/pkiclient.exe?operation=GetCACert&
     message=caserver HTTP/1.0
00:44:00:CRYPTO_PKI:http connection opened
00:44:01:CRYPTO_PKI:HTTP response header:
  HTTP/1.1 200 OK
  Server:Microsoft-IIS/5.0
  Date:Fri, 17 Apr 2005 19:50:59 GMT
  Content-Length:2693
  Content-Type:application/x-x509-ca-ra-cert
  Content-Type indicates we have received CA and RA certificates.
00:42:01:CRYPTO_PKI:WARNING:A certificate chain could not be
     constructed while selecting certificate status
00:42:01:CRYPTO_PKI:WARNING:A certificate chain could not be
     constructed while selecting certificate status
00:42:01:CRYPTO_PKI:Name:CN = caserverRA, O = Cisco System, C = US
00:42:01:CRYPTO_PKI:Name:CN = caserverRA, O = Cisco System, C = US
00:42:01:CRYPTO_PKI:transaction GetCACert completed
00:42:01:CRYPTO_PKI:CA certificate received.
% Do you accept this certificate? [yes/no]:yes
Router(config)# crypto ca enroll caserver
% Start certificate enrollment ..
% Create a challenge password. You will need to verbally provide this
   password to the CA Administrator in order to revoke your certificate.
   For security reasons your password will not be saved in the configuration.
   Please make a note of it.
Password:
Re-enter password:
% The subject name in the certificate will be:Router.cisco.com
% Include the router serial number in the subject name? [yes/no]: no
% Include an IP address in the subject name? [yes/no]:no
Request certificate from CA? [yes/no]:yes
% Certificate request sent to Certificate Authority
% The certificate request fingerprint will be displayed.
% The 'show crypto ca certificate' command will also show the fingerprint.
Fingerprint: 2CFC6265 77BA6496 3AEFCB50 29BC2BF2
00:43:39:CRYPTO_PKI:transaction PKCSReq completed
00:43:39:CRYPTO_PKI:status:
00:43:39:CRYPTO_PKI:http connection opened
00:43:39:CRYPTO_PKI: received msg of 1924 bytes
00:43:39:CRYPTO_PKI:HTTP response header:
 HTTP/1.1 200 OK
Server:Microsoft-IIS/5.0
Date:Fri, Apr Nov 2005 19:51:28 GMT
Content-Length:1778
Content-Type:application/x-pki-message
00:45:29:CRYPTO_PKI:signed attr:pki-message-type:
00:45:29:13 01 33
00:45:29:CRYPTO_PKI:signed attr:pki-status:
00:45:29:13 01 30
00:45:29:CRYPTO_PKI:signed attr:pki-recipient-nonce:
00:45:29:04 10 B4 C8 2A 12 9C 8A 2A 4A E1 E5 15 DE 22 C2 B4 FD
00:45:29:CRYPTO_PKI:signed attr:pki-transaction-id:
00:45:29:13 20 34 45 45 41 44 42 36 33 38 43 33 42 42 45 44 45 39 46
00:45:29:34 38 44 33 45 36 39 33 45 33 43 37 45 39
00:45:29:CRYPTO_PKI:status = 100:certificate is granted
00:45:29:CRYPTO__PKI:All enrollment requests completed.
00:45:29:%CRYPTO-6-CERTRET:Certificate received from
  Certificate Authority

The debug crypto engine Command

The debug crypto engine command displays messages about performing encryption processes on the routernot just information about encrypting data packets, but all encryption processes. Actually, this command is applicable to both Phase 1 and 2 connections. Example 19-7 illustrates the use of this command.

Example 19-7. Using the debug crypto engine Command
*Mar 1 04:03:17.338: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
*Mar 1 04:03:17.454: CryptoEngine0: generate alg parameter
*Mar 1 04:03:17.554: CRYPTO_ENGINE: Dh phase 1 status: 0         (1)
*Mar 1 04:03:17.682: CryptoEngine0: generate alg parameter
*Mar 1 04:03:17.810: CryptoEngine0: create ISAKMP SKEYID         (2)
    for conn id 14
*Mar 1 04:03:17.818: CryptoEngine0: generate hmac context
    for conn id 14
*Mar 1 04:03:17.838: CryptoEngine0: generate hmac context
    for conn id 14
*Mar 1 04:03:17.842: CryptoEngine0: clear dh number for          (3)
    conn id 1
*Mar 1 04:03:17.850: CryptoEngine0: generate hmac context
    for conn id 14
*Mar 1 04:03:17.878: CryptoEngine0: generate hmac context
    for conn id 14
*Mar 1 04:03:17.878: CryptoEngine0: validate proposal            (4)
*Mar 1 04:03:17.878: CryptoEngine0: validate proposal request
*Mar 1 04:03:17.882: CryptoEngine0: generate hmac context
    for conn id 14
*Mar 1 04:03:17.882: CryptoEngine0: ipsec allocate flow          (5)

Here is an explanation of the important messages in the debug output from Example 19-7 output:

1.
Diffie-Hellman (DH) is successful based on this and the next message.

2.
Device authentication begins and the pre-shared key is encrypted using nonces.

3.
DH is no longer necessary and the temporary DH connection is removed.

4.
A matching transform is searched for the ISAKMP/IKE Phase 2 data connections.

5.
The two data connections are successfully built.

Here are some items to look for if you can't complete a session attempt to a remote IPsec peer:

  • If there is a mismatch in the ISAKMP/IKE Phase 1 policy, you'll see no output from this command.

  • If there is a problem with device authentication, the output will stop at the first line that states CryptoEngine0: generate hmac context for conn id.

  • If the two peers can't find a matching data transform for the Phase 2 connection, you won't see the messages that have ipsec allocate flow in them; instead, you'll see a message like this: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Quick mode failed with peer at 192.1.1.40.

Tip

Actually, reading the output of this command is easier than the debug crypto isakmp command; many times I'll start with this command first when troubleshooting Phase 1 or 2 connections instead of other debug commands.



Previous Page
Next Page