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.
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. 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. This too would result in an IKE authentication failure, ultimately causing IPsec VPN tunnel negotiation to stop before Phase 1 negotiation can complete. Example 4-8 Necessary Peering Changes Required on Router_B !Ĭrypto isakmp key tarheels address 201.0.0.1Ĭrypto map Router_B_Map 10 IPsec-isakmp set peer 201.0.0.1Īssume, 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 change is illustrated in the configuration fragment provided in Example 4-8. 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). The administrators of Router_B must make two basic changes to accommodate this change on Router_A. Example 4-7 Router_A Sources IPsec VPNs from Its Loopback1 Interface (201.0.0.1) !Ĭrypto map Router_A_Map local-address Loopback1 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. 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. 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). Now, let's turn our attention to IKE issues surrounding peering specification on PSKs. Thus far, we've covered IKE failure due to PSK mismatches. Mismatched Peer Addresses in IKE PSK DefinitionĪs we have discussed, there are two elements to troubleshoot in a PSK authentication scheme. However, Example 4-6, line 18, confirms that the SA fails negotiation due to a PSK mismatch. The diagnostic output provided in Example 4-6, line 13, confirms that the two crypto peers have agreed on an IKE proposal. Note that, in Example 4-4 and Example 4-5, the Router_A fails to negotiate an IKE SA due to mismatched PSKs. 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ĥ encryption algorithm: AES - Advanced Encryption Standard (128 bit keys).ĩ lifetime: 86400 seconds, no volume limitġ1 encryption algorithm: Three key triple DESġ3 authentication method: Rivest-Shamir-Adleman Signatureġ5 lifetime: 86400 seconds, no volume limit 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). 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). Of 9 1 Router_A# show crypto isakmp policyĦ encryption algorithm: Three key triple DESġ0 lifetime: 86400 seconds, no volume limitġ2 encryption algorithm: DES - Data Encryption Standard (56 bit keys).ġ6 lifetime: 86400 seconds, no volume limitġ8 encryption algorithm: AES - Advanced Encryption Standard (128 bit keys).Ģ2 lifetime: 86400 seconds, no volume limitĢ4 encryption algorithm: DES - Data Encryption Standard (56 bit keys).Ģ6 authentication method: Rivest-Shamir-Adleman SignatureĢ8 lifetime: 86400 seconds, no volume limitĮxample 4-5 provides the configuration of Router_B in Figure 4-2.
0 kommentar(er)
