| 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 2-24 and Figure 2-25 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 Example 4-1 and Example 4-2, Router_A and Router_B will attempt to form an IKE SA between one another using the topology illustrated in Figure 4-1. Figure 4-1. ISAKMP SA Negotiation Resulting in ISAKMP Proposal Mismatch 
Example 4-1 provides the ISAKMP policies configured for Router_A in Figure 4-1. Note that, in this configuration, there are no ISAKMP proposals configured that match those configured on Router_B in Example 4-2. Example 4-1. Crypto ISAKMP Policy Definition for Router_A in Figure 4-1 (Mismatch with Router_B, Example 4-2) 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
|
Example 4-2 provides the ISAKMP policy configuration on Router_B of Figure 4-1. Router_B will use this policy when building an ISAKMP SA to Router_A, whose ISAKMP policy is provided in Example 4-1. Because Router_B's ISAKMP configuration contains no matching proposals with Router_A's configuration provided in Example 4-1, ISAKMP negotiation will fail. Example 4-2. Crypto ISAKMP Policy Definition for Router_B in Figure 4-1 (Mismatch with Router_B, Example 4-1) 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 Example 4-1 for Router_A in Figure 4-1 and Example 4-2 for Router_B in Figure 4-1. 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. Example 4-3 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 Example 4-3, 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. Example 4-3, 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 Example 4-3, line 18. Example 4-3. 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 4-2 to highlight authentication failures directly attributable to mismatched keys and mismatched peers. Figure 4-2. Troubleshooting IKE PSK Authentication 
Example 4-4 provides the configuration of Router_A in Figure 4-2. Note that, unlike Router_A's configuration in Figure 4-1, Router_A is now configured with an ISAKMP policy that contains a matching proposal (Example 4-4, priority 30) with Router_B (Example 4-5, priority 10). In this case, however, IKE will still fail to negotiate due to a mismatched PSK on Router_A (Example 4-4, line 32) and Router_B (Example 4-5, line 32). Example 4-4. Mismatched IKE PSK on Router_A (Corresponds with Mismatched Key for Router_B in Example 4-5) 1 Router_A#show crypto isakmp policy 2 3 Global IKE policy 4 #<--ISAKMP Policy 10 Matches Router_B's ISAKMP Proposal 30 (Example 4-5 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
|
Example 4-5 provides the configuration of Router_B in Figure 4-2. Note that Router_B's ISAKMP proposal listed with priority 10 (Example 4-4, lines 5-10) will match Router_A's proposal listed with priority 30 (Example 4-4, lines 17-22). However, IKE will still fail because of mismatched PSKs on Router_A (Example 4-4, line 32) and Router_B (Example 4-5, line 32). Example 4-5. Mismatched IKE PSK on Router_B (Corresponds with Mismatched Key for Router_A in Example 4-4) 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 (Example 4-4 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 Example 4-4 and Example 4-5, the Router_A fails to negotiate an IKE SA due to mismatched PSKs. The diagnostic output provided in Example 4-6, line 13, confirms that the two crypto peers have agreed on an IKE proposal. However, Example 4-6, line 18, confirms that the SA fails negotiation due to a PSK mismatch. Example 4-6. 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 4-2, 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. Example 4-7 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. Example 4-7. 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 Example 4-8. Example 4-8. 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 Example 4-9 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 (Example 4-8), the IKE engine will try to look for a key to use with that peer. In this case, the case described in Example 4-9, 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 Example 4-8 has been changed to 201.0.0.1, but the IKE PSK statement is still 200.0.0.1. The diagnostic output provided in Example 4-9 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). Example 4-9. 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 (Example 4-10). Example 4-10, line 13, confirms that the two crypto peers have agreed on an ISAKMP proposal, and Example 4-10 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 Example 4-10, lines 2325. Example 4-10. 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 4-3 are set up to do RSA encryption for IKE authentication. Figure 4-3. IKE Authentication FailureMismatched RSA Public Keys 
Example 4-11 provides the RSA key configuration of Router_A in Figure 4-3. 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 Example 4-11, lines 3-9. The administrator of Router_A has manually entered Router_B's encryption key, as listed in Example 4-11, lines 20-29. Example 4-11. Router_A's (Figure 4-3) 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
|
Example 4-12 provides the RSA key configuration of Router_B in Figure 4-3. Note that Router B has mistakenly been configured with Router_A's private key, rather than its public key. Example 4-12. Router_B's (Figure 4-3) 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
|
Example 4-13, line 5, confirms that ISAKMP SA negotiation is initiated with RSA Encryption for authentication. Output from Example 4-13, 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. Example 4-13, 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. Example 4-13. 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 Example 4-11 through Example 4-13, 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 4-4). 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. Figure 4-4. RSA Encryption and ISAKMP Peer Mismatches 
Example 4-14 provides the RSA key configuration for Router_A in Figure 4-4. Example 4-14. Router_A RSA Encryption Key Peer Mismatch with Router_B in Figure 4-4 (Router_B Configuration Provided in Example 4-15) 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
|
Example 4-15 provides the RSA key configuration for Router_B in Figure 4-4. 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 Example 4-15, lines 22-23. Example 4-15. Router_B RSA Encryption Key Peer Mismatch with Router_A in Figure 4-4 (Router_A Configuration Provided in Example 4-14) 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 (Example 4-15, 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 Example 4-16. Example 4-16. 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: We will examine debugs and diagnostics for each of these processes using the topology in Figure 4-5, 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. Figure 4-5. Troubleshooting IKE Authentication Errors with RSA Signatures 
Example 4-17 provides the configuration for Router_A in Figure 4-5. We will use this configuration while troubleshooting and validating IKE SA authentication with RSA Signatures later in this chapter. Example 4-17. RSA Signatures Configuration on Router_A (Figure 4-5) 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
|
Example 4-18 provides the configuration for Router_B in Figure 4-5. We will use this configuration while troubleshooting and validating IKE SA authentication with RSA Signatures later in this chapter. Example 4-18. RSA Signatures Configuration on Router_B (Figure 4-5) 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 Example 4-19 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. Example 4-19. 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 Example 4-20, lines 3-5. The debugging output from Example 4-20, 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 Example 4-20, line 13, and the resulting diagnostic output in Example 4-20, lines 14-25. Example 4-20. 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 4-5. We can confirm through the PKI server operation debugging output on the IOS CA provided in Example 4-21 that the requests for enrollment have indeed been received from Router_A. Example 4-21. 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 Example 4-22 confirms that Router_A has indeed received its signed certificate from the CA. Example 4-22. 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 4-5. We can confirm the existence of signed certificates on both Router_A and Router_B, as illustrated in Example 4-23. Example 4-23. 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 Example 4-24 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. Example 4-24. 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 4-5 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 Example 4-25, we will intentionally insert an incorrect peer on Router_B in order to illustrate peer mismatch diagnostic output on the IOS CLI in Example 4-26. Example 4-25. 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 Example 4-25. We can confirm the inconsistency by debugging the Phase 2 negotiation process using the debug crypto IPsec command. Example 4-26 provides diagnostic output indicating a peering address inconsistency on Router_B causing the IPsec SA negotiation to fail. Example 4-26. 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 Example 4-27, we will remedy the peering issue introduced in Example 4-25 and diagnosed in Example 4-26. 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). Example 4-27. Correcting the Peering Inconsistency in Example 4-15 and Example 4-16 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 4-5 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 Example 4-28 highlighted below confirms a mismatch in the IPsec transform causing a quick mode to fail to negotiate an IPsec SA. Example 4-28. 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 Example 4-29. 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."
Example 4-29. 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 Example 4-30, 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. Example 4-30 provides the configurations on Router_A and Router_B illustrating the missing crypto ACE on Router_A. Example 4-30. 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#
|
Example 4-31 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. Example 4-31. 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 Example 4-32, 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 Example 4-31. Example 4-32. 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#
|
|
