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 23–25.
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 categories—mismatched 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 keys—the 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.
IKE Authentication Failure—Mismatched 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