[TABS_R id=8782]
Which of the following commands should you issue when troubleshooting basic IKE peering to determine whether PSKs are present and matching on both peers? (Select the best answer.)
- ping
- traceroute
- show crypto isakmp policy
- debug crypto isakmp
Explanation/Reference:
You should issue the debug crypto isakmp command to determine whether preshared keys (PSKs) are present and matching on both peers. If there is a PSK mismatch between the peers, you will see the 1d00h:%CRYPTO4IKMP_BAD_MESSAGE: IKE message from 10.11.12.13 failed its sanity check or is malformed debug error message. If a PSK is missing on one of the peers, you will see the
1d00h:#CRYPTO4IKMP_NO_PRESHARED_KEY: Preshared key for remote peer at 10.11.12.13 is missing debug error message. To create a PSK, issue the crypto isakmp key key {address | ipaddress [mask] | hostname name} [noxauth] command.
When troubleshooting basic Internet Key Exchange (IKE) peering, you should perform the following steps:
1. Verify that the peers can reach each other.
2. Verify that the IKE policies match on both peers.
3. Verify that the peers successfully authenticate each other.
To verify that the peers can reach each other, you can issue the ping command. A successful ping indicates that connectivity between the peers exists. If the ping is not successful, you can issue the traceroute command to see where the fault is occurring along the path between the two peers.
To verify that the IKE policies match on both peers, you can issue the show crypto isakmp policy command to display the IKE phase 1 policy settings that are configured on the router, including the encryption algorithm, hash algorithm, authentication method, DiffieHellman (DH) key exchange mechanism, and security association (SA) lifetime. The following displays sample output from the show crypto isakmp policy command:
RouterA#show crypto isakmp policy
Global IKE policy
Protection suite of priority 20
encryption algorithm: AES – Advanced Encryption Standard (128 bit keys)
hash algorithm: Secure Hash Standard
authentication method: PreShared Key
DiffieHellman group: #14 (2048 bit)
lifetime: 3600 seconds, no volume limit
In order for virtual private network (VPN) peers to successfully negotiate a key management tunnel during IKE phase 1, the peers must agree on security parameters. For example, when RouterA sends an IKE policy proposal to RouterB, the IKE policy is compared with the IKE policies defined on RouterB. The proposed policy must be an exact match to one of RouterB’s locally defined policies? otherwise, it will be rejected. The one exception to this rule is the value of the IKE lifetime parameter. An IKE lifetime is considered a match if the value is less than or equal to the IKE lifetime defined in the local policy. If the IKE lifetime value is less than that of the local policy, the router will use the lesser of the two values. For example, when RouterA initiates a connection to RouterB, RouterA will only consider lifetime values from RouterB’s policies as matching if they are less than or equal to 14,400 seconds.
To configure IKE phase 1 policy parameters, issue the crypto isakmp policy prioritycommand to enter Internet Security Association and Key Management Protocol (ISAKMP) policy configuration mode, where you can issue the following commands:
-authentication
– encryption
– group
– hash
– lifetime
You can issue the debug crypto isakmp command to determine whether an IKE phase 1 policy mismatch is occurring. The debug error message 1d00h: ISAKMP (0:1): atts are not acceptable. Next payload is 0 will appear when there is a phase 1 policy mismatch between the peers.
To verify that the peers successfully authenticate each other, you should issue the debug crypto isakmp command. If the PSKs are present and matching on both peers, the IKE SA should establish successfully and communication between the sites should occur.
[TABS_R id=8782]