Common Configuration Issues with IPsec VPNs






Common Configuration Issues with IPsec VPNs

There are many parameters and features to understand when deploying IPsec VPNs. In this section, we will discuss configuration issues presented when one or more IPsec VPN gateways are configured incorrectly. After discussing the nature of each of the above commonly experienced IPsec VPN configuration issues, we will discuss the methods used to effectively diagnose and remedy these issues.

IKE SA Proposal Mismatches

Unless IPsec session keys are manually defined, two crypto endpoints must agree upon an ISAKMP policy to use when negotiating the secure Internet Key Exchange (IKE) channel, or ISAKMP security association (SA). As such, when two VPN endpoints fail to agree upon a usable ISAKMP policy, IPsec SA negotiation cannot initiate, and traffic will continue to flow unencrypted.

Figure and Figure provide a brief description of ISAKMP policy negotiation process in main mode and aggressive mode respectively and the involved configuration on two VPN endpoints. Also remember from our discussions in Chapter 2 that ISAKMP policies are listed in order of priority (the lower number being the highest priority). The initiator will offer the highest priority proposal, and the responder will search its locally configured ISAKMP policies for a match. If there are none, the initiator will propose the next highest ISAKMP policy and define its local configuration. This process will continue until the initiator has no proposals left to offer the responder. The result, in this case, would be an ISAKMP SA proposal mismatch. Using the configurations provided in Figure and Figure, Router_A and Router_B will attempt to form an IKE SA between one another using the topology illustrated in Figure.

ISAKMP SA Negotiation Resulting in ISAKMP Proposal Mismatch


Figure provides the ISAKMP policies configured for Router_A in Figure. Note that, in this configuration, there are no ISAKMP proposals configured that match those configured on Router_B in Figure.

Figure. Crypto ISAKMP Policy Definition for Router_A in Figure (Mismatch with Router_B, Figure)

Router_A#show crypto isakmp policy

Global IKE policy
Protection suite of priority 10
        encryption algorithm:   Three key triple DES
        hash algorithm:         Message Digest 5
        authentication method:  Pre-Shared Key
        Diffie-Hellman group:   #2 (1024 bit)
        lifetime:               86400 seconds, no volume limit
Protection suite of priority 20
        encryption algorithm:   DES - Data Encryption Standard (56 bit keys).
        hash algorithm:         Secure Hash Standard
        authentication method:  Pre-Shared Key
        Diffie-Hellman group:   #2 (1024 bit)
        lifetime:               86400 seconds, no volume limit
Protection suite of priority 30
        encryption algorithm:   AES - Advanced Encryption Standard (128 bit keys).
        hash algorithm:         Secure Hash Standard
        authentication method:  Rivest-Shamir-Adleman Signature
        Diffie-Hellman group:   #1 (768 bit)
        lifetime:               86400 seconds, no volume limit
Default protection suite
        encryption algorithm:   DES - Data Encryption Standard (56 bit keys).
        hash algorithm:         Secure Hash Standard
        authentication method:  Rivest-Shamir-Adleman Signature
        Diffie-Hellman group:   #1 (768 bit)
        lifetime:               86400 seconds, no volume limit

Figure provides the ISAKMP policy configuration on Router_B of Figure. Router_B will use this policy when building an ISAKMP SA to Router_A, whose ISAKMP policy is provided in Figure. Because Router_B's ISAKMP configuration contains no matching proposals with Router_A's configuration provided in Figure, ISAKMP negotiation will fail.

Figure. Crypto ISAKMP Policy Definition for Router_B in Figure (Mismatch with Router_B, Figure)

Router_B#show crypto isakmp policy


Global IKE policy
Protection suite of priority 10
        encryption algorithm:   AES - Advanced Encryption Standard (128 bit keys).
        hash algorithm:         Message Digest 5
        authentication method:  Pre-Shared Key
        Diffie-Hellman group:   #5 (1536 bit)
        lifetime:               86400 seconds, no volume limit
Protection suite of priority 20
        encryption algorithm:   Three key triple DES
        hash algorithm:         Message Digest 5
        authentication method:  Rivest-Shamir-Adleman Signature
        Diffie-Hellman group:   #1 (768 bit)
        lifetime:               86400 seconds, no volume limit
Protection suite of priority 30
        encryption algorithm:   DES - Data Encryption Standard (56 bit keys).
        hash algorithm:         Secure Hash Standard
        authentication method:  Pre-Shared Key
        Diffie-Hellman group:   #2 (1024 bit)
        lifetime:               86400 seconds, no volume limit
Default protection suite
        encryption algorithm:   DES - Data Encryption Standard (56 bit keys).
        hash algorithm:         Secure Hash Standard
        authentication method:  Rivest-Shamir-Adleman Signature
        Diffie-Hellman group:   #1 (768 bit)
        lifetime:               86400 seconds, no volume limit

The following numbered sequence of events describes the ISAKMP proposal mismatch between the configurations provided in Figure for Router_A in Figure and Figure for Router_B in Figure.

1.
Router A sends its configured ISAKMP policies 10, 20, and 30 to Router B.

2.
Router B checks policy 10 obtained in step 1 against its own configured policies, beginning with the lowest numbered policy and ending with the highest.

3.
If Router B does not find a match in step 2, it checks policy 20 obtained in step 1 against its own configured policies, starting with the lowest numbered and ending with the highest.

4.
If Router B does not find a match in step 3, it checks policy 30 obtained in step 1 against its own configured policies, starting with the lowest numbered and ending with the highest.

5.
If Router B does not find a match in step 4, then a proposal mismatch has occurred, and the Phase 1 negotiation times out.

In order to confirm that IKE proposal mismatches have occurred in an IPsec VPN tunnel negotiation, we will inspect the output of the ISAKMP SA negotiation between Routers A and B. Routers A and B are using preshared IKE authentication in a site-to-site VPN, but have not been configured with matching ISAKMP policies. We will execute the command debug crypto isakmp on routers A and B to highlight that an IKE proposal mismatch is indeed the cause of ISAKMP SA negotiation failure. Figure displays debugging output as ISAKMP policies proposed by Router_A are checked against locally configured policies on Router_B.

In the diagnostic output shown in Figure, Router_B checks proposals sent from Router_A for potential matches. Router_B begins by checking the ISAKMP proposals sent from Router_A against its own configured ISAKMP proposals. It does this by checking all of the proposals received (starting with lowest numbered and ending with highest) against favored policy (lowest numbered). If there are no matches, it checks the received policies in the same order against its next-lowest-numbered policy. This process continues until a match is found or all policies have been checked and no match has been found. In this specific proposal, the encryption proposed for encrypting the IKE channel does not match (see Examples 4-2 and 4-3 for ISAKMP proposal information for Router_A and Router_B), and Router B continues to check other offered proposals against its locally configured ISAKMP policies. Figure, line 12, confirms that a proposal mismatch has occurred. Router_B finds that no ISAKMP proposals sent from Router_A match its own configured ISAKMP policies and therefore deletes the Phase1 SA and Phase1 negotiation times out on Router_A, as confirmed in Figure, line 18.

Isolating IKE Proposal Mismatches on the Initiating VPN Endpoint (Router A)

1  Router_B#debug crypto isakmp
2  Crypto ISAKMP debugging is on
3  !
4  !
5  *Feb 16 12:11:02.379: ISAKMP:(0:0:N/A:0):Checking ISAKMP transform 1 against priority
     10 policy
6  *Feb 16 12:11:02.379: ISAKMP:      encryption 3DES-CBC
7  *Feb 16 12:11:02.379: ISAKMP:      hash MD5
8  *Feb 16 12:11:02.379: ISAKMP:      default group 2
9  *Feb 16 12:11:02.379: ISAKMP:      auth pre-share
10 *Feb 16 12:11:02.379: ISAKMP:      life type in seconds
11 *Feb 16 12:11:02.379: ISAKMP:      life duration (VPI) of 0x0 0x1 0x51 0x80
12 *Feb 16 12:11:02.379: ISAKMP:(0:0:N/A:0):Encryption algorithm offered does not match
     policy!
13 !
14 !
15 *Feb 16 12:11:02.379: ISAKMP:(0:0:N/A:0):no offers accepted!
16 *Feb 16 12:11:02.379: ISAKMP:(0:0:N/A:0): phase 1 SA policy not acceptable! (local
     200.0.0.2 remote 200.0.0.1)
17 *Feb 16 12:11:02.379: ISAKMP:(0:0:N/A:0):peer does not do paranoid keepalives.
18 *Feb 16 12:11:02.379: ISAKMP:(0:0:N/A:0):deleting SA reason "Phase1 SA policy proposal
     not accepted" state (R) MM_NO_STATE (peer 200.0.0.1)

Until the two endpoints can agree on an ISAKMP policy to use when securing the IKE channel and negotiating a Diffie-Hellman key to use when encrypting the IKE exchanges and in the IPsec transform, IPsec VPN tunnel negotiation cannot continue. Another task that must be performed successfully for IPsec VPN tunnel negotiation to continue is IKE authentication.

IKE Authentication Failures and Errors

Recall from our previous discussions that, in Cisco IOS, there are three methods offered to authenticate peers wanting to negotiate an ISAKMP SA: preshared keys (PSKs), RSA signatures, or RSA encryption. As we had discussed in Chapter 2, all three authentication methods have distinct elements used when authenticating IKE Peers. We will discuss common IKE authentication failure issues within the context of each of these three authentication methods.

IKE Authentication Errors and PSKs

There are two conditions that must be met for two IPsec VPN endpoints to authenticate each other using IKE PSKs. First, matching keys must be configured on the two endpoints. Second, the endpoints must be configured to share these keys with the correct peer. Router_A and Router_B are now configured with matching ISAKMP policies for Phase 1 negotiation, but still have problems preventing them from authenticating one another. We will examine debugging output on the routers in Figure to highlight authentication failures directly attributable to mismatched keys and mismatched peers.

Troubleshooting IKE PSK Authentication


Figure provides the configuration of Router_A in Figure. Note that, unlike Router_A's configuration in Figure, Router_A is now configured with an ISAKMP policy that contains a matching proposal (Figure, priority 30) with Router_B (Figure, priority 10). In this case, however, IKE will still fail to negotiate due to a mismatched PSK on Router_A (Figure, line 32) and Router_B (Figure, line 32).

Figure. Mismatched IKE PSK on Router_A (Corresponds with Mismatched Key for Router_B in Figure)

1  Router_A#show crypto isakmp policy
2
3  Global IKE policy
4  #<--ISAKMP Policy 10 Matches Router_B's ISAKMP Proposal 30 (Figure below)-->
5  Protection suite of priority 10
6          encryption algorithm:   Three key triple DES
7          hash algorithm:         Message Digest 5
8          authentication method:  Pre-Shared Key
9          Diffie-Hellman group:   #2 (1024 bit)
10          lifetime:               86400 seconds, no volume limit
11 Protection suite of priority 20
12         encryption algorithm:   DES - Data Encryption Standard (56 bit keys).
13         hash algorithm:         Secure Hash Standard
14         authentication method:  Pre-Shared Key
15         Diffie-Hellman group:   #2 (1024 bit)
16         lifetime:               86400 seconds, no volume limit
17 Protection suite of priority 30
18         encryption algorithm:   AES - Advanced Encryption Standard (128 bit keys).
19         hash algorithm:         Secure Hash Standard
20         authentication method:  Pre-Shared Key
21         Diffie-Hellman group:   #5 (1536 bit)
22         lifetime:               86400 seconds, no volume limit
23 Default protection suite
24         encryption algorithm:   DES - Data Encryption Standard (56 bit keys).
25         hash algorithm:         Secure Hash Standard
26         authentication method:  Rivest-Shamir-Adleman Signature
27         Diffie-Hellman group:   #1 (768 bit)
28         lifetime:               86400 seconds, no volume limit
29 Router_A#show crypto isakmp key
30 Keyring               Hostname/Address                   PSK
31
32 default               200.0.0.2                          tarheels

Figure provides the configuration of Router_B in Figure. Note that Router_B's ISAKMP proposal listed with priority 10 (Figure, lines 5-10) will match Router_A's proposal listed with priority 30 (Figure, lines 17-22). However, IKE will still fail because of mismatched PSKs on Router_A (Figure, line 32) and Router_B (Figure, line 32).

Figure. Mismatched IKE PSK on Router_B (Corresponds with Mismatched Key for Router_A in Figure)

1  Router_B#show crypto isakmp policy
2
3  Global IKE policy
4  Protection suite of priority 10
5          encryption algorithm:   AES - Advanced Encryption Standard (128 bit keys).
6          hash algorithm:         Secure Hash Standard
7          authentication method:  Pre-Shared Key
8          Diffie-Hellman group:   #5 (1536 bit)
9          lifetime:               86400 seconds, no volume limit
10 Protection suite of priority 20
11         encryption algorithm:   Three key triple DES
12         hash algorithm:         Message Digest 5
13         authentication method:  Rivest-Shamir-Adleman Signature
14         Diffie-Hellman group:   #1 (768 bit)
15         lifetime:               86400 seconds, no volume limit
17  #<--ISAKMP Policy 30 Matches Router_A's ISAKMP Proposal 10 (Figure above)-->
17 Protection suite of priority 30
18         encryption algorithm:   AES - Advanced Encryption Standard (128 bit keys).
19         hash algorithm:         Secure Hash Standard
20         authentication method:  Pre-Shared Key
21         Diffie-Hellman group:   #2 (1024 bit)
22         lifetime:               86400 seconds, no volume limit
23 Default protection suite
24         encryption algorithm:   DES - Data Encryption Standard (56 bit keys).
25         hash algorithm:         Secure Hash Standard
26         authentication method:  Rivest-Shamir-Adleman Signature
27         Diffie-Hellman group:   #1 (768 bit)
28         lifetime:               86400 seconds, no volume limit
29 Router_A#show crypto isakmp key
30 Keyring               Hostname/Address                   PSK
31
32 default               200.0.0.1                          bluedevils

Mismatched Keys

Note that, in Figure and Figure, the Router_A fails to negotiate an IKE SA due to mismatched PSKs. The diagnostic output provided in Figure, line 13, confirms that the two crypto peers have agreed on an IKE proposal. However, Figure, line 18, confirms that the SA fails negotiation due to a PSK mismatch.

PSK Authentication Failure Between Two IKE Endpoints

1  Router_A#debug crypto isakmp
2  Crypto ISAKMP debugging is on
3  !
4  !
5  *Feb 16 14:20:44.991: ISAKMP (0:1): Checking ISAKMP transform 1 against priority
     30 policy
6  *Feb 16 14:20:44.991: ISAKMP:      encryption AES-CBC
7  *Feb 16 14:20:44.991: ISAKMP:      keylength of 128
8  *Feb 16 14:20:44.991: ISAKMP:      hash SHA
9  *Feb 16 14:20:44.991: ISAKMP:      default group 5
10 *Feb 16 14:20:44.991: ISAKMP:      auth pre-share
11 *Feb 16 14:20:44.991: ISAKMP:      life type in seconds
12 *Feb 16 14:20:44.995: ISAKMP:      life duration (VPI) of 0x0 0x1 0x51 0x80
13 *Feb 16 14:20:44.995: ISAKMP (0:1): atts are acceptable. Next payload is 0
14 !
15 !
16 *Feb 16 14:20:45.319: ISAKMP (0:1): received packet from 200.1.1.2 dport 500 sport
     500 Global (I) MM_KEY_EXCH
17 *Feb 16 14:20:45.319: ISAKMP: reserved not zero on NOTIFY payload!
18 *Feb 16 14:20:45.319: %CRYPTO-4-IKMP_BAD_MESSAGE: IKE message from 200.0.0.2     failed
     its sanity check or is malformed

Mismatched Peer Addresses in IKE PSK Definition

As we have discussed, there are two elements to troubleshoot in a PSK authentication scheme. Thus far, we've covered IKE failure due to PSK mismatches. Now, let's turn our attention to IKE issues surrounding peering specification on PSKs. Suppose that, in Figure, Router_A decides to source all peering sessions from its loopback interface (loopack 1, ip=201.0.0.1/32).

The default behavior of an IOS IPsec endpoint is to source the IPsec VPN tunnel from the IP address of the physical interface where the crypto map is applied. Figure changes IPsec peering behavior from the router's default settings by instructing the router to use a loopback interface for sourcing the IPsec VPN tunnel.

Router_A Sources IPsec VPNs from Its Loopback1 Interface (201.0.0.1)

!
crypto map Router____A____Map local-address Loopback1
!
interface Loopback1
 ip address 201.0.0.1 255.255.255.255

The administrators of Router_B must make two basic changes to accommodate this change on Router_A. They must first change their IPsec peering definition in their crypto map to point to Router_A's new source (its loopback address, 201.0.0.1). This change is illustrated in the configuration fragment provided in Figure.

Necessary Peering Changes Required on Router_B

!
crypto isakmp key tarheels address 201.0.0.1
!
crypto map Router____B____Map 10 IPsec-isakmp
 set peer 201.0.0.1

Assume, though, that the administrators of Router_B did not correctly modify the peer address on their PSK statement to accurately reflect the changes on Router_A. This too would result in an IKE authentication failure, ultimately causing IPsec VPN tunnel negotiation to stop before Phase 1 negotiation can complete. The debugging output in Figure can be inspected to confirm that, although IKE PSKs do match, they are not being shared with the correct peers. Due to the fact that the IPsec peer has been updated to point to 201.0.0.1 (Figure), the IKE engine will try to look for a key to use with that peer. In this case, the case described in Figure, the IKE PSK statement has not been updated, and the IKE Phase 1 negotiation subsequently fails to kick off. Note that the peer statement in Figure has been changed to 201.0.0.1, but the IKE PSK statement is still 200.0.0.1. The diagnostic output provided in Figure confirms this error, as IKE cannot find a matching key to use with the new IPsec peer statement in the crypto map (201.0.0.1).

IKE Authentication Failure Due to PSKs Not Being Shared with the Correct Peer Addresses

!
!
*Feb 16 14:30:00.595: ISAKMP:(0:0:N/A:0):Can not start Aggressive mode, trying Main mode.
*Feb 16 14:30:00.595: ISAKMP: Looking for a matching key for 201.0.0.1 in default
*Feb 16 14:30:00.595: ISAKMP:(0:0:N/A:0):No pre-shared key with 201.0.0.1!
!

Solving Key Mismatch and Peer Mismatch Issues on Router_A and Router_B

Indeed, the administrators of Router_B realize that they had made a mistake in selecting "bluedevils" as the IKE PSK and fix the problem. Additionally, all of the ISAKMP address information on PSK definitions on Router_A and Router_B have changed to be consistent. Now that Router_A and Router_B can agree on an ISAKMP policy and PSK with the appropriate peering information intact, an IKE can successfully be negotiated as evidenced by debugging output from IKE Phase 1 negotiation on Router_B (Figure). Figure, line 13, confirms that the two crypto peers have agreed on an ISAKMP proposal, and Figure line 22 confirms that the SA has been authenticated. Once Phase 1 negotiation is complete, the ISAKMP SA can be verified without debugging, using show commands, as illustrated in Figure, lines 2325.

Successful IKE Authentication Using PSKs (Router_B)

1  Router_B#debug crypto isakmp
2  Crypto ISAKMP debugging is on
3  !
4  !
5  *Feb 16 14:44:55.063: ISAKMP (0:1): Checking ISAKMP transform 1 against priority 30 policy
6  *Feb 16 14:44:55.063: ISAKMP:       encryption AES-CBC
7  *Feb 16 14:44:55.063: ISAKMP:       keylength of 128
8  *Feb 16 14:44:55.063: ISAKMP:       hash SHA
9  *Feb 16 14:44:55.063: ISAKMP:       default group 5
10 *Feb 16 14:44:55.063: ISAKMP:       auth pre-share
11 *Feb 16 14:44:55.063: ISAKMP:       life type in seconds
12 *Feb 16 14:44:55.063: ISAKMP:       life duration (VPI) of 0x0 0x1 0x51 0x80
13 *Feb 16 14:44:55.063: ISAKMP (0:1): atts are acceptable. Next payload is 3
14 !
15 !
16 *Feb 16 14:44:55.431: ISAKMP (0:1): SA authentication status:
17         Authenticated
18 *Feb 16 14:44:55.431: ISAKMP (0:1): Process initial contact,
19 bring down existing phase 1 and 2 SA's with local 200.1.1.2 remote 201.0.0.1 remote
     port 500
20 *Feb 16 14:44:55.431: ISAKMP (0:1): SA authentication status:
21         authenticated
22 *Feb 16 14:44:55.431: ISAKMP (0:1): SA has been authenticated with 201.0.0.1
23 Router_B#sh crypto isakmp sa
24 dst             src               state        conn-id slot
25 200.0.0.2       201.0.0.1         QM_IDLE            1    0

IKE Authentication Errors with RSA Encryption

As with the PSK method of authenticating IKE peers, IKE authentication failures using RSA encryption are commonly attributed to two categoriesmismatched keys or mismatched peers. As such, we will begin our RSA encryption discussion with a scenario in which RSA public keys are not matched correctly. Remember that RSA encryption algorithm is asymmetric, consisting of two keysthe public/decryption key and the private/encryption key. If the incorrect keys are provided to IPsec VPN peers using RSA Encryption, Phase 1 negotiation will time out due to IKE authentication errors. The endpoints in Figure are set up to do RSA encryption for IKE authentication.

IKE Authentication FailureMismatched RSA Public Keys


Figure provides the RSA key configuration of Router_A in Figure. The router uses RSA encryption as the IKE authentication method, requiring a public (encryption) key and a private (decryption) key to authenticate the SA. Router_A's private key is manually generated, and is listed in Figure, lines 3-9. The administrator of Router_A has manually entered Router_B's encryption key, as listed in Figure, lines 20-29.

Figure. Router_A's (Figure) RSA Key Configuration for IKE SA Establishment with Router_B

1  Router_A#show crypto key mypubkey rsa
2  % Key pair was generated at: 8:56:03 UTC Feb 17 2005
3  <-- Router_A's Private RSA Key used for decryption -->
4  Key name: Router_A.cisco.com
5   Usage: General Purpose Key
6   Key is not exportable.
7   Key Data:
8    305C300D 06092A86 4886F70D 01010105 00034B00 30480241 00BF6D28 71EE1FF2
9    415E4001 23F4D08C 62DFEAA8 4C0682A4 39D66B5D DC275EAB C95DE5A4 1C87700B
10    4A6AB4F3 8ACFFE4D 6B409C93 6BB3DAE3 D7D13398 3C48C7A1 B5020301 0001
11 % Key pair was generated at: 10:56:04 UTC Feb 17 2005
12 Key name: Router_A.cisco.com.server
13  Usage: Encryption Key
14  Key is exportable.
15  Key Data:
16   307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00B86AD5 F0E1D956
17   E29630DC 64D5FAE8 F6FA9E74 3894D9B9 0DCA97AE 454F4937 063499B2 2B84C46E
18   7D5D2647 22D3AC56 DC9017DC 5D6938AD A57C4629 098C2DA3 8F16376A DDD145DA
19   70712AD0 EB07850F 5B96A6E2 7CCA8D60 3783E7D9 30EE2DD8 3B020301 0001
20
21 <-- RSA Key used to encrypt data to Router_B (200.0.0.2) -->
22 Router_A#show crypto key pubkey-chain rsa add 200.0.0.2
23 Key address:         200.0.0.2
24  Usage: General Purpose Key
25  Source: Manually entered
26  Data:
27   30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 009F63BF
28   64DF17DF CD836EA2 FA556169 95A05572 FCF7F1E1 BA7DC493 18408EC0 F98B78BE
29   28FAE232 3132AF97 CE73D4B5 07F10A86 CFD038F3 FBC44FF2 2C323420 D1430162
30   C026DF34 DD6E4AB5 EA3BB45F 1F184393 DD4C0A3C C9DAD616 F876784B EC9A9AF4
31   5F2D692F 238F3B82 09C4AD90 2569E1B6 9AD98833 D6700467 A7880202 0D020301 0001

Figure provides the RSA key configuration of Router_B in Figure. Note that Router B has mistakenly been configured with Router_A's private key, rather than its public key.

Figure. Router_B's (Figure) RSA Key Configuration for IKE SA Establishment with Router_A

1  Router_B#show crypto key mypubkey rsa
2  % Key pair was generated at: 08:59:17 UTC Feb 17 2005
3  <-- Router_B's Private RSA Key used for decryption -->
4  Key name: Router_B.cisco.com
5   Usage: General Purpose Key
6   Key is not exportable.
7   Key Data:
8    30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 009F63BF
9    64DF17DF CD836EA2 FA556169 95A05572 FCF7F1E1 BA7DC493 18408EC0 F98B78BE
10    28FAE232 3132AF97 CE73D4B5 07F10A86 CFD038F3 FBC44FF2 2C323420 D1430162
11   C026DF34 DD6E4AB5 EA3BB45F 1F184393 DD4C0A3C C9DAD616 F876784B EC9A9AF4
12   5F2D692F 238F3B82 09C4AD90 2569E1B6 9AD98833 D6700467 A7880202 0D020301 0001
13 % Key pair was generated at: 09:59:18 UTC Feb 17 2005
14 Key name: Router_B.cisco.com.server
15  Usage: Encryption Key
16  Key is not exportable.
17  Key Data:
18   307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00CCB92C 23D6CA83
19   1BD6D9D3 7F569F4F 6AF576C8 AD682B20 3E9B054B 8C75CD54 4B6FDB7F 71524C5F
20   C117056E 15A86DA7 26AB1B92 23958CB9 1134C6A1 AF8ACDBE 8E1F8C30 0468E46B
21   36CFA390 0B0CE8BE 622B0266 E10342DF FD2D50E0 A6460363 37020301 0001
22
23 Router_B#show crypto key pubkey-chain rsa address 200.0.0.1
24 <-- RSA Key used to encrypt data to Router_A (200.0.0.1) -->
25 Key address:        200.0.0.1
26  Usage: General Purpose Key
27  Source: Manually entered
28  Data:
29   307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00B86AD5 F0E1D956
30   E29630DC 64D5FAE8 F6FA9E74 3894D9B9 0DCA97AE 454F4937 063499B2 2B84C46E
31   7D5D2647 22D3AC56 DC9017DC 5D6938AD A57C4629 098C2DA3 8F16376A DDD145DA
32   70712AD0 EB07850F 5B96A6E2 7CCA8D60 3783E7D9 30EE2DD8 3B020301 0001

Figure, line 5, confirms that ISAKMP SA negotiation is initiated with RSA Encryption for authentication. Output from Figure, line 8, indicates that IKE messages cannot be decrypted, because Router_B is mistakenly using Router_A's decryption key for encrypting IKE messages to Router_A, rather than using Router_A's proper encryption key to do so. Figure, lines 19-40, illustrate that the same key misconfiguration on Router_A is causing IKE SA authentication to fail on Router_B for the same reasons it failed earlier on Router_A.

Troubleshooting IKE Authentication Failures with RSA Encryption

1  Router_A#debug crypto isakmp
2  Crypto ISAKMP debugging is on
3  !
4  !
5  *Feb 17 10:58:20.066: ISAKMP (0:1): SA is doing RSA encryption authentication using
     id type ID_IPV4_ADDR
6  !
7  !
8  *Feb 17 10:58:20.554: %CRYPTO-6-IKMP_CRYPT_FAILURE: IKE (connection id 1) unable to
     decrypt (w/RSA private key) packet
9  !
10 !
11 *Feb 17 10:58:41.706: ISAKMP (0:1): retransmitting phase 1 MM_SA_SETUP...
12 *Feb 17 10:58:41.706: ISAKMP (0:1): incrementing error counter on sa: retransmit phase 1
13 !
14 !
15 *Feb 17 10:59:19.918: ISAKMP (0:1): deleting SA reason "gen_IPsec_isakmp_delete but
     doi isakmp" state (I) MM_SA_SETUP (peer 200.0.0.2) input queue 0
16 *Feb 17 10:59:19.918: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL
17 *Feb 17 10:59:19.918: ISAKMP (0:1): Old State = IKE_I_MM3 New State = IKE_DEST_SA
18
19 Router_B#debug crypto isakmp
20 Crypto ISAKMP debugging is on
21 !
22 !
23 *Feb 17 10:01:10.930: ISAKMP:(0:1:SW:1):SA is doing RSA encryption authentication
     using id type ID_IPV4_ADDR
24 !
25 !
26 *Feb 17 10:01:21.658: ISAKMP:(0:1:SW:1): retransmitting phase 1 MM_KEY_EXCH
27 *Feb 17 10:01:21.658: ISAKMP:(0:1:SW:1): sending packet to 200.1.1.1 my_port
     500 peer_port 500 (R) MM_KEY_EXCH
28 !
29 !
30 *Feb 17 10:01:55.466: ISAKMP: quick mode timer expired.
31 *Feb 17 10:01:55.466: ISAKMP:(0:1:SW:1):src 200.0.0.1 dst 200.0.0.2, SA is not
     authenticated
32 *Feb 17 10:01:55.466: ISAKMP:(0:1:SW:1):peer does not do paranoid keepalives.
33 !
34 !
35 *Feb 17 10:01:55.466: ISAKMP:(0:1:SW:1):deleting SA reason "QM_TIMER expired" state (R)
     MM_KEY_EXCH (peer 200.0.0.1)
36 *Feb 17 10:01:55.466: ISAKMP:(0:1:SW:1):deleting SA reason "QM_TIMER expired" state (R)
     MM_KEY_EXCH (peer 200.1.1.1)
37 *Feb 17 10:01:55.466: ISAKMP: Unlocking IKE struct 0x65C405A8 for isadb_mark_
     sa_deleted(), count 0
38 *Feb 17 10:01:55.466: ISAKMP: Deleting peer node by peer_reap for 200.1.1.1: 65C405A8
39 *Feb 17 10:01:55.466: ISAKMP:(0:1:SW:1):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL
40 *Feb 17 10:01:55.466: ISAKMP:(0:1:SW:1):Old State = IKE_R_MM4 New State = IKE_DEST_SA

Cisco IOS VPN endpoints can be instructed to use certain RSA public keys with certain peers, a similar functionality to standard PSK authentication. As such, it is important that each VPN endpoint is using the correct key for the correct peer. Consider once again the situation in which the administrators of Router_A choose to source the VPN tunnel endpoint from their loopback1 (201.0.0.1) interface. The administrators of Router_B have fixed the mismatching key problem in Figure through Figure, and have updated their IPsec configuration to peer with Router_A's loopback address. However, they have not updated the address that ISAKMP should use when authenticating the IKE channel with Router_B's public/encryption key (see configurations listed in Figure). Therefore, Router_B cannot select the appropriate public key to authenticate the IKE channel with Router_A. Once again, this leads to an IKE Authentication error, which eventually causes ISAKMP SA negotiation to time out.

RSA Encryption and ISAKMP Peer Mismatches


Figure provides the RSA key configuration for Router_A in Figure.

Figure. Router_A RSA Encryption Key Peer Mismatch with Router_B in Figure (Router_B Configuration Provided in Figure)

1  Router_A#show crypto key mypubkey rsa
2  % Key pair was generated at: 10:56:03 UTC Feb 17 2005
3  Key name: Router_A.cisco.com
4   Usage: General Purpose Key
5   Key is not exportable.
6   Key Data:
7    305C300D 06092A86 4886F70D 01010105 00034B00 30480241 00BF6D28 71EE1FF2
8    415E4001 23F4D08C 62DFEAA8 4C0682A4 39D66B5D DC275EAB C95DE5A4 1C87700B
9    4A6AB4F3 8ACFFE4D 6B409C93 6BB3DAE3 D7D13398 3C48C7A1 B5020301 0001
10 % Key pair was generated at: 11:56:05 UTC Feb 17 2005
11 Key name: Router_A.cisco.com.server
12  Usage: Encryption Key
13  Key is not exportable.
14  Key Data:
15   307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00A233B3 3A58DDB2
16   D578B1A4 0125E1CD 1594C9F2 24DACE5E 65A276C7 640E9A13 B8DC4EEC F332B8D8
17   80127FD6 07A579F6 A280DF7D 2ED2CA8B 3457F5DE 53DAB835 C2845EB6 42F89BB0
18   C7130F67 B10FD71E 30A1FB1E 812CA1A6 26F43DCA 7BDDA01D 65020301 0001
19
20 Router_A#show crypto key pubkey-chain rsa address 200.0.0.2
21 Key address:        200.0.0.2
22 Usage: General Purpose Key
23 Source: Manually entered
24 Data:
25  30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 009F63BF
26  64DF17DF CD836EA2 FA556169 95A05572 FCF7F1E1 BA7DC493 18408EC0 F98B78BE
27  28FAE232 3132AF97 CE73D4B5 07F10A86 CFD038F3 FBC44FF2 2C323420 D1430162
28  C026DF34 DD6E4AB5 EA3BB45F 1F184393 DD4C0A3C C9DAD616 F876784B EC9A9AF4
29  5F2D692F 238F3B82 09C4AD90 2569E1B6 9AD98833 D6700467 A7880202 0D020301 0001

Figure provides the RSA key configuration for Router_B in Figure. Note that, although the public and private keys have been correctly configured on Router_A and Router_B, Router_B is not configured with the correct peering information in its encryption key settings to be used with Router_A. This peer mismatch is illustrated in Figure, lines 22-23.

Figure. Router_B RSA Encryption Key Peer Mismatch with Router_A in Figure (Router_A Configuration Provided in Figure)

1  Router_B#show crypto key mypubkey rsa
2  % Key pair was generated at: 09:59:17 UTC Feb 17 2005
3  Key name: Router_B.cisco.com
4   Usage: General Purpose Key
5   Key is not exportable.
6   Key Data:
7    30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 009F63BF
8    64DF17DF CD836EA2 FA556169 95A05572 FCF7F1E1 BA7DC493 18408EC0 F98B78BE
9    28FAE232 3132AF97 CE73D4B5 07F10A86 CFD038F3 FBC44FF2 2C323420 D1430162
10   C026DF34 DD6E4AB5 EA3BB45F 1F184393 DD4C0A3C C9DAD616 F876784B EC9A9AF4
11   5F2D692F 238F3B82 09C4AD90 2569E1B6 9AD98833 D6700467 A7880202 0D020301 0001
12 % Key pair was generated at: 10:59:18 UTC Feb 17 2005
13 Key name: Router_B.cisco.com.server
14  Usage: Encryption Key
15  Key is not exportable.
16  Key Data:
17   307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00CA138A 38268367
18   9FB2BDA8 A5C4677B 06A0FA1C 7811BAA6 C6FA48A7 E3DE55D0 B6967E71 DF076209
19   1F3CCA1E A7F40179 B4013CC8 ADCB15DD FFDAFAC3 9210BEA7 894DEEDA 1BF59C4B
20   B0143E21 80559A4D 4F8A512E DB739E8B 576E61FD 650BDA6B 87020301 0001
21
22 Router_B#show crypto key pubkey-chain rsa address 200.0.0.1
23 Key address:             200.0.0.1
24  Usage: General Purpose Key
25  Source: Manually entered
26  Data:
27   305C300D 06092A86 4886F70D 01010105 00034B00 30480241 00BF6D28 71EE1FF2
28   415E4001 23F4D08C 62DFEAA8 4C0682A4 39D66B5D DC275EAB C95DE5A4 1C87700B
29   4A6AB4F3 8ACFFE4D 6B409C93 6BB3DAE3 D7D13398 3C48C7A1 B5020301 0001

Once the configuration on Router_B (Figure, lines 22-23) has been updated to use Router_A's public key with Router_A's new peering information (lo1=201.0.0.1), then the ISAKMP SA can be negotiated successfully using RSA Encryption as confirmed in Figure.

Updated Peer Configuration on Router_B, and ISAKMP SA Confirmation

1  Router_B#sh run
2  Building configuration...
3  crypto key pubkey-chain rsa
4   addressed-key 201.0.0.1
5    address 201.0.0.1
6    key-string
7     305C300D 06092A86 4886F70D 01010105 00034B00 30480241 00BF6D28 71EE1FF2
8     415E4001 23F4D08C 62DFEAA8 4C0682A4 39D66B5D DC275EAB C95DE5A4 1C87700B
9     4A6AB4F3 8ACFFE4D 6B409C93 6BB3DAE3 D7D13398 3C48C7A1 B5020301 0001
10   quit
11
12 Router_B#ping
13 !
14 !
15 Sending 5, 100-byte ICMP Echos to 202.1.1.1, timeout is 2 seconds:
16 Packet sent with a source address of 202.2.2.1
17 .!!!!
18 Success rate is 80 percent (4/5), round-trip min/avg/max = 40/43/44 ms
19 *Feb 17 11:21:41.570: %CRYPTO-5-SESSION_STATUS: Crypto tunnel is UP  . Peer
201.0.0.1:500       Id: 201.0.0.1
20 Router_B#show crypto isakmp sa
21 dst         src             state          conn-id      slot
22 201.0.0.1   200.1.1.2       QM_IDLE              1         0
23 Router_B#show crypto key pubkey-chain rsa
24 Codes: M - Manually configured, C - Extracted from certificate
25
26 Code Usage         IP-Address/VRF         Keyring           Name
27 M    General        201.0.0.1             default

Note

In the preceding examples pertaining to RSA encryption, Router_A (512 bit-mod) and Router_B (1024-bit mod) have been using mismatched key modulus. This will not cause IKE authentication errors, but does not provide the same strength in authentication as using 1024-bit keys on both sides.


Last, it is important to note that the configurations above use IP addresses (addressed-key) selecting public keys to use with their corresponding peer. Alternately, administrators can use hostnames to identify peers, instead of IP addresses. When using hostnames, administrators must verify that the hostname can be resolved to an IP address via DNS or manually using the ip host [ip-address] [hostname] command in the local router configuration. Additionally, each peer using a hostname for ISAKMP identification must be instructed to do so using the crypto isakmp identity [hostname] command, as the default is use of the IP address associated with the physical interface where the crypto map is applied.

IKE Authentication Errors with RSA Signatures

As we'll discuss later in Chapter 11, the dynamics of authentication change dramatically when RSA signatures are used. Until now, we've discussed IKE SA authentication methods that require direct key exchange between crypto endpoints, including both IKE PSK and RSA Encrypted Nonce methods of IKE authentication. Now we will discuss the RSA Signatures method of IKE SA authentication, in which both endpoints are authenticated indirectly using a centralized trusted resource, a Certificate Authority (CA), during Phase 1 negotiation. As such, our focus will not be on endpoint-endpoint authentication and peering, but instead will explore common IKE authentication issues attributable to endpoint-CA operation:

  • Authenticating the CA and Obtaining the CA Certificate

  • Enrolling with the CA and Obtaining Public Key Certificates

We will examine debugs and diagnostics for each of these processes using the topology in Figure, as Routers A and B obtain certificates from IOS_CAROOT needed for IKE authentication using RSA Signatures. It has been confirmed that Router_A and Router_B can reach the CA.

Troubleshooting IKE Authentication Errors with RSA Signatures


Figure provides the configuration for Router_A in Figure. We will use this configuration while troubleshooting and validating IKE SA authentication with RSA Signatures later in this chapter.

Figure. RSA Signatures Configuration on Router_A (Figure)

Router_A#show crypto ca certificates
Certificate
  Status: Available
  Certificate Serial Number: 03
  Certificate Usage: General Purpose
  Issuer:
    cn=IOS_CAROOT
  Subject:
    Name: Router_A.cisco.com
    IP Address: 192.168.1.1
    Serial Number: 01C2F27F
    serialNumber=1C2F27F+ipaddress=192.168.1.1+hostname=Router_A.cisco.com
  Validity Date:
    start date: 10:12:45 UTC Feb 24 2005
    end   date: 10:12:45 UTC Feb 24 2006
    renew date: 00:00:00 UTC Jan 1 1970
  Associated Trustpoints: IOS_CAROOT

CA Certificate
  Status: Available
  Certificate Serial Number: 01
  Certificate Usage: Signature
  Issuer:
    cn=IOS_CAROOT
  Subject:
    cn=IOS_CAROOT
  Validity Date:
    start date: 09:06:11 UTC Feb 24 2005
    end   date: 09:06:11 UTC Feb 24 2008
  Associated Trustpoints: IOS_CAROOT

Router_A#show crypto key mypubkey rsa
% Key pair was generated at: 10:11:30 UTC Feb 24 2005
Key name: Router_A.cisco.com
 Usage: General Purpose Key
 Key is not exportable.
 Key Data:
  30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00AF2FC9
  1919ECF1 DE24C37D 796658E2 2B186600 98EB5CE3 AE0E53FE B1F736EA CE417989
  F3029E25 594B9BCB 30DD0A2D 799814B1 555071FE BFB081E1 80548F91 3021F997
  0FBC0B62 4A6284A4 22175B89 4D5C00B2 4DE6F657 F6CA00DA E8629294 413487F6
  6AB72BAF 071F4C63 CD813C3A 8925B95D F3DE265C CCFA3AA5 C38386DA 25020301 0001
% Key pair was generated at: 10:11:31 UTC Feb 24 2005
Key name: Router_A.cisco.com.server
 Usage: Encryption Key
 Key is exportable.
 Key Data:
  307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00C7CE18 CD11DBAE
  6FE6999B 15E81063 998CD039 91677AAD 9E310C38 9CF10010 EE3BBD5C 574837E8
  08098084 D1F09C7D 9143F22C 6684AAA5 9B518676 AB205A9B 2681B77A 24E69ABA
  734AB29C 28D4A672 4C93B3B4 DE27CB77 FF0DBBF0 2A5ABF1F AF020301 0001

Router_A#show crypto key pubkey-chain rsa
Codes: M - Manually configured, C - Extracted from certificate

Code  Usage       IP-Address/VRF         Keyring           Name
C     Signing                            default           X.500 DN name:
                             cn=IOS_CAROOT

C     Signing     192.168.2.1/           default           Router_B.cisco.com

Figure provides the configuration for Router_B in Figure. We will use this configuration while troubleshooting and validating IKE SA authentication with RSA Signatures later in this chapter.

Figure. RSA Signatures Configuration on Router_B (Figure)

Router_B#show crypto ca certificates
Certificate
  Status: Available
  Certificate Serial Number: 02
  Certificate Usage: General Purpose
  Issuer:
    cn=IOS_CAROOT
  Subject:
    Name: Router_B.cisco.com
    IP Address: 192.168.2.1
    Serial Number: 46DDB4F1
    serialNumber=46DDB4F1+ipaddress=192.168.2.1+hostname=Router_B.cisco.com
  Validity Date:
    start date: 10:12:14 UTC Feb 24 2005
    end   date: 10:12:14 UTC Feb 24 2006
    renew date: 00:00:00 UTC Jan 1 1970
  Associated Trustpoints: IOS_CAROOT

CA Certificate
  Status: Available
  Certificate Serial Number: 01
  Certificate Usage: Signature
  Issuer:
    cn=IOS_CAROOT
  Subject:
    cn=IOS_CAROOT
  Validity Date:
    start date: 09:06:11 UTC Feb 24 2005
    end date: 09:06:11 UTC Feb 24 2008
  Associated Trustpoints: IOS_CAROOT

Router_B#show crypto key mypubkey rsa
% Key pair was generated at: 10:11:24 UTC Feb 24 2005
Key name: Router_B.cisco.com
 Usage: General Purpose Key
 Key is not exportable.
 Key Data:
  30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00BED6DA
  A5B2F28A 344B205F 3DA673FF C68454E4 68CF0E46 C798BA58 03599AB0 AFF59A8C
  7BACFF5B C99549D5 8F74A7CE 70A2DF07 32961389 47CBA640 20BC3680 8A45309D
  775E3233 F491738D 345B59EE 4FAA2086 BCE01E7B 0BF8337B CEB74FF0 8464AC03
  161AD316 D18B1720 A24AC357 DF990577 C170BB0F 652DA98A 49E165C4 45020301 0001
% Key pair was generated at: 10:11:25 UTC Feb 24 2005
Key name: Router_B.cisco.com.server
 Usage: Encryption Key
 Key is not exportable.
 Key Data:
  307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00B0EF99 26A348E9
  DCEEA144 54CA48F4 B396BBA6 E9973EC8 58B5A3D5 2B9339EC D3B26894 FBA3F6C5
  50864ECD 4329EE58 4291FAE0 4E9C02EF C0FE117C 77E1E7E7 F871B74D 2012BF25
  56C60BAF 33F7C29D 8B79FDCF D4ACE6E9 9DCD1DB6 92E62427 2B020301 0001

Router_B#show crypto key pubkey-chain rsa
Codes: M - Manually configured, C - Extracted from certificate

Code Usage         IP-Address/VRF         Keyring          Name
C    Signing                              default          X.500 DN name:
                              cn=IOS_CAROOT
C    Signing       192.168.1.1            default          Router_A.cisco.com

Authenticating the CA and Obtaining the CA Certificate

During the process of CA authentication on a Cisco IOS VPN endpoint, the administrator of the VPN endpoint visually inspects the CA certificate fingerprint and manually accepts the corresponding CA certificate. Aside from human error in the inspection and acceptance of the CA fingerprint and certificate described above, one of the most common errors observed during this process is attributable to inconsistencies in clock settings between the endpoint and the CA. The CA's certificate has a lifetime associated with it. When a public-key infrastructure (PKI) endpoint receives the CA certificate during the authentication process and has an incorrect clock setting, the CA certificate could appear to be invalid. Consider Figure in which Router_B attempts to enroll with the CA, RSA_CAROOT. Router_B's clock is set incorrectly, which leads the router to believe that the CA certificate is outside of the appropriate period of validity.

CA Authentication Failure Due to Inconsistent Clock Settings

Router_B#sh clock
09:55:30.262 UTC Wed Apr 26 2002
Router_B(config)#crypto pki authenticate IOS_CAROOT
% Error in saving certificate: status = FAIL
%CRYPTO_PKI: CA Cert not yet valid or is expired -
    start date: 14:40:58 UTC Feb 17 2005
    end   date: 14:40:58 UTC Feb 17 2008

Once Router_B's clock has been synchronized with the PKI (and subsequently the CA's), Router_B can then authenticate the CA in the PKI by verifying the CA certificate's thumbprint, as illustrated in Figure, lines 3-5. The debugging output from Figure, lines 10 and 11, verifies that a CA certificate has been received by Router_B. We can further confirm that a CA certificate exists on Router_B via the show command executed in Figure, line 13, and the resulting diagnostic output in Figure, lines 14-25.

Authenticating and Obtaining the CA Certificate

1  Router_B(config)#crypto pki authenticate IOS_CAROOT
2  Certificate has the following attributes:
3  Fingerprint: 743A3CD1 14293369 3CB5D70C BDB96C7F
4  % Do you accept this certificate? [yes/no]: yes
5  Trustpoint CA certificate accepted.
6
7  IOS_CAROOT#debug crypto pki server
8  !
9  !
10 Feb 22 10:54:12.715: CRYPTO_CS: received a SCEP GetCACert request
11 Feb 22 10:54:12.715: CRYPTO_CS: CA certificate sent
12
13 Router_B#show crypto pki certificates
14 CA Certificate
15   Status: Available
16   Certificate Serial Number: 01
17   Certificate Usage: Signature
18   Issuer:
19     cn=IOS_CAROOT
20   Subject:
21     cn=IOS_CAROOT
22   Validity Date:
23     start date: 14:40:58 UTC Feb 17 2005
24     end   date: 14:40:58 UTC Feb 17 2008
25   Associated Trustpoints: IOS_CAROOT

Now that we have verified that we have the CA's certificate, we can proceed to enroll the VPN endpoint in the PKI.

Enrolling in the PKI

In order to enroll in the PKI, the VPN endpoint must have successfully authenticated the CA to which it will enroll. Additionally, the VPN endpoint subscribing to the PKI must successfully obtain the CA's signing certificate from the CA after enrolling. In order to successfully accomplish this, two things must occur. First, the CA must receive the appropriate request from the VPN endpoint. This requires that the VPN endpoint use the required communication method configured on the CA. Consider the case below in which Router_A wants to enroll with IOS_CAROOT in Figure. We can confirm through the PKI server operation debugging output on the IOS CA provided in Figure that the requests for enrollment have indeed been received from Router_A.

Verifying That Enrollment Requests Are Received by the CA

IOS_CAROOT#debug crypto pki server
!
!
Feb 22 10:41:06.119: CRYPTO_CS: received a SCEP request
Feb 22 10:41:06.119: CRYPTO_CS: read SCEP: registered and bound service SCEP_READ_DB_26
Feb 22 10:41:06.127: CRYPTO_CS: scep msg type - 19
Feb 22 10:41:06.127: CRYPTO_CS: trans id - A758860CFBEAC6B6720A8650A1046863
Feb 22 10:41:06.199: CRYPTO_CS: read SCEP: unregistered and unbound service SCEP_READ_DB_26
Feb 22 10:41:06.199: CRYPTO_CS: received an enrollment request

The second task that must be accomplished in PKI enrollment is verification that the router has indeed received the CA's certificate. Remember that, when enrolling in the PKI, the CA administrator must grant the VPN endpoint its certificate before it can be issued to the VPN endpoint. It is therefore quite possible to authenticate a CA successfully, while not enrolling successfully. The following diagnostic output on the IOS command-line interface (CLI) of the CA in line 4 confirms that the CA has granted and sent its certificate to a requestor (Router_A). The output provided in line 7 of Figure confirms that Router_A has indeed received its signed certificate from the CA.

Router_A's Certificate Is Signed by the CA, Sent by the CA, and Received by Router_A

1  IOS_CAROOT#debug crypto pki server
2  !
3  !
4  Feb 22 10:41:13.871: CRYPTO_CS: Certificate generated and sent to requestor
5
6  Router_A#
7  *Feb 22 10:56:12.299: %CRYPTO-6-CERTRET: Certificate received from Certificate Authority

After a crypto endpoint has successfully authenticated and enrolled with the PKI, IKE SA negotiation must still occur for two crypto endpoints to establish an IPsec VPN tunnel between each other. It is, therefore, important to verify ISAKMP SA establishment using the verification methods described earlier in this chapter after peers can successfully authenticate and enroll to the PKI to ensure that the remaining mechanics of IKE SA negotiation have been successfully executed. It is equally important to inspect the certificates for validity after PKI authentication and enrollment, in order to avoid IKE authentication errors with RSA signatures. Once certificates have been received by each VPN endpoint, they should be checked for consistency. Consider once again the IKE authentication exchange between Router_A and Router_B in Figure. We can confirm the existence of signed certificates on both Router_A and Router_B, as illustrated in Figure.

Verifying the Existence of Certificates on IOS PKI VPN Endpoints

Router_A#show crypto ca certificates
Certificate
  Status: Available
  Certificate Serial Number: 07
  Certificate Usage: General Purpose
  Issuer:
    cn=IOS_CAROOT
  Subject:
    Name: Router_A.cisco.com
    IP Address: 202.0.0.1
    Serial Number: 01C2F27F
    serialNumber=1C2F27F+ipaddress=202.0.0.1+hostname=Router_A.cisco.com
  Validity Date:
    start date: 15:21:49 UTC Feb 22 2005
    end   date: 15:21:49 UTC Feb 22 2006
    renew date: 00:00:00 UTC Jan 1 1970
  Associated Trustpoints: IOS_CAROOT

Router_B#show crypto ca certificates
Certificate
  Status: Available
  Certificate Serial Number: 06
  Certificate Usage: General Purpose
  Issuer:
    cn=IOS_CAROOT
  Subject:
    Name: Router_B.cisco.com
    IP Address: 202.0.0.2
    Serial Number: 46DDB4F1
    serialNumber=46DDB4F1+ipaddress=202.0.0.2+hostname=Router_B.cisco.com
  Validity Date:
    start date: 15:20:38 UTC Feb 22 2005
    end   date: 15:20:38 UTC Feb 22 2006
    renew date: 00:00:00 UTC Jan 1 1970
  Associated Trustpoints: IOS_CAROOT

Finally, the certificates displayed above are used to authenticate the IKE channel during Phase1 negotiation. Diagnostic and debugging output from Figure confirms that RSA Signatures are indeed used for IKE authentication, and that an ISAKMP SA has successfully been established using the RSA Signatures method of authentication.

Verifying the Establishment of an ISAKMP SA Using RSA Signatures on Router_A

Router_A#debug crypto isakmp
!
!
*Feb 22 15:22:47.943: ISAKMP (0:1): SA is doing RSA signature authentication using id type
ID_FQDN
!
!
*Feb 22 15:22:47.947: ISAKMP (0:1): constructing CERT payload for
serialNumber=1C2F27F+ipaddress=202.0.0.1+hostname=Router_A.cisco.com
*Feb 22 15:22:47.947: ISAKMP (0:1): using the IOS_CAROOT trustpoint's keypair to sign
!
!
*Feb 22 15:22:52.987: ISAKMP (0:1): processing SIG payload. message ID = 0
*Feb 22 15:22:52.991: ISAKMP (0:1): SA authentication status:
        authenticated
*Feb 22 15:22:52.991: ISAKMP (0:1): SA has been authenticated with 200.0.0.2

Router_A#show crypto isakmp sa
dst          src            state            conn-id slot
200.0.0.2    200.0.0.1      QM_IDLE                1    0

Router_A#show crypto engine connections active

  ID Interface           IP-Address    State   Algorithm          Encrypt  Decrypt
   1 FastEthernet0/0     200.0.0.1     set     HMAC_SHA+3DES_56_C       0        0
2000 FastEthernet0/0     200.0.0.1     set     HMAC_SHA+AES_CBC         0        2
2001 FastEthernet0/0     200.0.0.1     set     HMAC_SHA+AES_CBC         2        0

IPsec SA Proposal Mismatches

Recall from our IPsec overview in Chapter 2 that the IPsec SAs cannot be established until there is an ISAKMP SA (unless manual keying is used). Up until this point, we've discussed common troubleshooting tactics for debugging Phase 1 negotiation errors. Now we will assume that an ISAKMP SA has been established and explore some common issues to troubleshoot in Phase 2 negotiation of the IPsec SA.

In order for two peers to successfully negotiate an IPsec SA, they must agree on three things specific to Phase 2 negotiation:

  • The IP addresses used for IPsec tunnel termination

  • The symmetric IPsec transforms to use on crypto-protected traffic after an IPsec SA has been negotiated

  • The scope of protected traffic in the crypto switching path

Note

Other items in the crypto path can be negotiated during Phase 2 negotiation even if they are mismatched. Such elements of the IPsec SA include the SA lifetime and perfect forward secrecy (PFS) group modulus.


Now that the routers in Figure have been able to authenticate one another using RSA Signatures, and can establish an ISAKMP SA, we will insert an error in to the crypto map that prevents us from negotiating an IPsec SA. On Router_B, we will change the peering address to point to Router_C instead of Router_A. In Figure, we will intentionally insert an incorrect peer on Router_B in order to illustrate peer mismatch diagnostic output on the IOS CLI in Figure.

Inserting a Peering Error on Router_B

Router_B#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router_B(config)#crypto map pki4 10
Router_B(config-crypto-map)#set peer 200.0.0.10
Router_B(config-crypto-map)#end
Router_B#

As expected, Router_A and Router_B can establish an ISAKMP SA, but are unable to complete Phase 2 negotiation due to the peering inconsistency introduced in Figure. We can confirm the inconsistency by debugging the Phase 2 negotiation process using the debug crypto IPsec command. Figure provides diagnostic output indicating a peering address inconsistency on Router_B causing the IPsec SA negotiation to fail.

Identifying IPsec Proposal Mismatch Issues

Router_A#debug crypto IPsec
Router_A#
Feb 24 11:52:30.196: IPSEC(sa_request): ,
  (key eng. msg.) OUTBOUND local= 200.0.0.1, remote= 200.0.0.2,
    local_proxy= 202.1.1.0/255.255.255.0/0/0 (type=4),
    remote_proxy= 202.2.2.0/255.255.255.0/0/0 (type=4),
    protocol= ESP, transform= esp-aes esp-sha-hmac (Tunnel),
    lifedur= 5000s and 4608000kb,
    spi= 0x59ABE066(1504436326), conn_id= 0, keysize= 128, flags= 0x400B.....

Router_B#debug crypto IPsec
Router_B#
Feb 24 11:52:30.627: IPSEC(key_engine): got a queue event with 1 kei messages
Feb 24 11:52:30.791: IPSEC(validate_proposal_request): proposal part #1,
  (key eng. msg.) INBOUND local= 200.0.0.2, remote= 200.0.0.1,
    local_proxy= 202.2.2.0/255.255.255.0/0/0 (type=4),
    remote_proxy= 202.1.1.0/255.255.255.0/0/0 (type=4),
    protocol= ESP, transform= esp-aes esp-sha-hmac (Tunnel),
    lifedur= 0s and 0kb,
    spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x42
Feb 24 11:52:30.791: Crypto mapdb : proxy_match
        src addr     : 202.2.2.0
        dst addr     : 202.1.1.0
        protocol     : 0
        src port     : 0
        dst port     : 0
Feb 24 11:52:30.791: IPSEC(validate_transform_proposal): peer address 200.0.0.1 not found
Feb 24 11:52:30.795: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Quick mode failed with peer
at 200.0.0.1
Feb 24 11:53:00.315: IPSEC(validate_proposal_request): proposal part #1,
  (key eng. msg.) INBOUND local= 200.0.0.2, remote= 200.0.0.1,
    local_proxy= 202.2.2.0/255.255.255.0/0/0 (type=4),
    remote_proxy= 202.1.1.0/255.255.255.0/0/0 (type=4),
    protocol= ESP, transform= esp-aes esp-sha-hmac (Tunnel),
    lifedur= 0s and 0kb,
    spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x42
Feb 24 11:53:00.315: Crypto mapdb : proxy_match
        src addr     : 202.2.2.0
        dst addr     : 202.1.1.0
        protocol     : 0
        src port     : 0
        dst port     : 0
Feb 24 11:53:00.315: IPSEC(validate_transform_proposal): peer address 200.0.0.1 not found

Let us now insert another error that causes Phase 2 negotiation failure. In Figure, we will remedy the peering issue introduced in Figure and diagnosed in Figure. We will also reconfigure the crypto transform in transform set "pki4," introducing a transform set mismatch with Router_A (Router_A uses esp-aes esp-sha-hmac for its transform).

Figure. Correcting the Peering Inconsistency in Figure and Figure and Creating a Mismatched IPsec Transform Set on Router_B

Router_B#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router_B(config)#crypto map pki4 10
Router_B(config-crypto-map)#no set peer 200.0.0.3
Router_B(config-crypto-map)#set peer 200.0.0.1
Router_B(config-crypto-map)#exit
Router_B(config)#crypto IPsec transform-set pki4 esp-aes esp-md5-hmac
Router_B(cfg-crypto-trans)#end
Router_B#

As with IPsec peering inconsistencies, an IPsec transform set mismatch will not prevent the establishment of an ISAKMP SA. Indeed, the agreement of a transform to use occurs in Phase 2 negotiationthe negotiation of the IPsec SA. The routers in Figure are now configured to use different transforms. Originally, Router_A and Router_B would use SHA1 Hash-based Message Authentication Code (HMAC) authentication in their transform sets. But, Router_B now uses the incorrect algorithm (MD-5 vs. SHA-1) to create the HMACs. As such, the routers are not able to agree on an IPsec proposal. As before, we will confirm this by debugging the IPsec crypto engine (debug crypto IPsec). The diagnostic output in Figure highlighted below confirms a mismatch in the IPsec transform causing a quick mode to fail to negotiate an IPsec SA.

Diagnosing IPsec Proposal InconsistenciesIdentifying Mismatched IPsec Transform Sets

Router_A#
Feb 24 12:01:01.121: IPSEC(key_engine): request timer fired: count = 1,
  (identity) local= 200.0.0.1, remote= 200.0.0.2,
    local_proxy= 202.1.1.0/255.255.255.0/0/0 (type=4),
    remote_proxy= 202.2.2.0/255.255.255.0/0/0 (type=4)
Feb 24 12:01:01.121: IPSEC(sa_request): ,
  (key eng. msg.) OUTBOUND local= 200.0.0.1, remote= 200.0.0.2,
    local_proxy= 202.1.1.0/255.255.255.0/0/0 (type=4),
    remote_proxy= 202.2.2.0/255.255.255.0/0/0 (type=4),
    protocol= ESP, transform= esp-aes esp-sha-hmac (Tunnel),
    lifedur= 5000s and 4608000kb,
    spi= 0xEBD24B7A(3956427642), conn_id= 0, keysize= 128, flags= 0x400B

Router_B#
Feb 24 12:00:31.537: IPSEC(key_engine): got a queue event with 1 kei messages
Feb 24 12:00:31.705: IPSEC(validate_proposal_request): proposal part #1,
  (key eng. msg.) INBOUND local= 200.0.0.2, remote= 200.0.0.1,
    local_proxy= 202.2.2.0/255.255.255.0/0/0 (type=4),
    remote_proxy= 202.1.1.0/255.255.255.0/0/0 (type=4),
    protocol= ESP, transform= esp-aes esp-sha-hmac (Tunnel),
    lifedur= 0s and 0kb,
    spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x42
Feb 24 12:00:31.705: Crypto mapdb : proxy_match
        src addr     : 202.2.2.0
        dst addr     : 202.1.1.0
        protocol     : 0
        src port     : 0
        dst port     : 0
Feb 24 12:00:31.705: IPSEC(validate_transform_proposal): transform proposal not supported
  for identity:
    {esp-aes esp-sha-hmac }
Feb 24 12:00:31.705: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Quick mode failed with peer
  at 200.0.0.1

Crypto-Protected Address Space Issues (Crypto ACL Errors)

As we had mentioned during our IPsec overview in Chapter 2 and earlier in this chapter, crypto-protected address spaces between VPN endpoints must be consistent for an IPsec SA to be established. These crypto-protected address spaces are defined with ACLs, commonly referred to as crypto ACLs.

When crypto ACLs specify inconsistent scopes of addresses between two peers, the expected result is that ISAKMP SA negotiation will complete successfully, but IPsec SA negotiation will fail. We will now walk through several examples of acceptable and unacceptable crypto ACL definition, and then explore some methods for diagnosing crypto ACL definition problems using Cisco IOS IPsec debugging capabilities.

Note

The protected address and port ranges specified in crypto ACLs are commonly shown as "proxies" in the crypto debugging output in Cisco IOS and ASA IPsec VPN endpoints.


The first case we will discuss demonstrates a crypto ACL definition that will facilitate successful IPsec SA negotiation. However, the next three examples of crypto ACLs present inconsistencies in crypto-protected address spaces that will cause Phase 2 SA proposals to be rejected. Configurations illustrating a valid crypto ACL match for Router_A and Router_B are provided in Figure.

Note

The crypto ACL's described in Cases 2 through 4 below will not preclude Phase 2 SA negotiation when TEDv3 is used. Although the ACL's are inconsistent, TEDv3 probes will dynamically discover consistent crypto-protected scopes and install the appropriate information in the IPsec SADB. The use of TED is discussed in greater detail in Chapter 12, "Solutions for Handling Dynamically Addressed Peers."


Crypto ACL Match

Router_A#show access-list 101
Extended IP access list 101
    10 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
Router_A#

Router_B#show access-list 101
Extended IP access list 101
    10 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
Router_B#

In Figure, Router_B has an extra access-list entry (ACE) in the crypto ACL (ACE #20). However, ACE 10 is consistent between routers A and B. As such, traffic matching ACE 10 will facilitate successful Phase1 and 2 SA negotiations. Traffic matching ACE 20 on Router-B will initiate a Phase 2 SA proposal that will be rejected by Router_A, which has no corresponding ACE in its Crypto ACL for Router_B's ACE 20 in crypto ACL 101. The traffic matching ACE 20 will subsequently be dropped. Figure provides the configurations on Router_A and Router_B illustrating the missing crypto ACE on Router_A.

Crypto ACL Mismatch Due to Missing ACE on Router_A

Router_A#sh access-list 101
Extended IP access list 101
    10 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
Router_A#

Router_B#sh access-list 101
Extended IP access list 101
    10 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
    20 permit ip 192.168.2.0 0.0.0.255 202.1.3.0 0.0.0.255
Router_B#

Figure provides a configuration in which the crypto ACLs on both Router_A and Router_B define scopes of protected address spaces that are inconsistent with the opposite peer's scope of protected source addresses. For example, Router_A protects traffic destined for any IP address that is sourced from 192.168.1.0/24. What would occur if traffic was sent from 192.168.1.1 to Router_A's physical IP address, 200.0.0.2? Router_A would encrypt the traffic as it matches ACE 10 in ACL 101. Router_B, however, would not encrypt the return traffic, as traffic sourced from 200.0.0.2 is not defined anywhere in its crypto ACL. For this reason, Phase 2 SA negotiation will fail when such an inconsistency is defined in the crypto ACL's of two IPsec peers.

Crypto ACL Mismatch Due to Inconsistent Destination Address Ranges

Router_A#show access-list 101
Extended IP access list 101
    10 permit ip 192.168.1.0 0.0.0.255 any
Router_A#

Router_B#show access-list 101
Extended IP access list 101
    10 permit ip 192.168.2.0 0.0.0.255 any
Router_B#

In the case provided in Figure, the ACL defines a tighter scope of address space on Router_B's crypto ACL. As such, if Router_B initiates the Phase 2 exchange, then an IPsec SA will be established successfully in the SADB, and traffic will pass. However, if Router_A initiates the Phase 2 exchange, the IPsec SA proposal will be rejected by Router_B for the same reasons discussed in Figure.

Crypto ACL Mismatch Due to Inconsistent Destination Address Scope on Router_B

Router_A#sh access-list 101
Extended IP access list 101
    10 permit ip 192.168.1.0 0.0.0.255 any (24 matches)
Router_A#

Router_B#sh access-list 101
Extended IP access list 101
    10 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
Router_B#



 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows