1. What is the device type?
Cisco ASA 9.9
2. What is the issue that you want to automate the detection/triage of?
A Network Administrator has made a configuration change to the IPsec of an ASA firewall during a hardening operation activity. Then it was noticed that the remote site connected with IPsec tunnel over the internet with the HQ is not reachable.
Troubleshooting of the interfaces, routing and IPsec tunnel proved after of 3hours service outage that the IKE phase output was in state “MM_KEY_EXCH”. Extensive debug analysis shows a mismatch to the pre-shared-key used between the IPsec peers. The administrator during the hardening operation of the ASA made a mistake to the IPsec preshared key password including an extra space character.
3. How can the issue be diagnosed?
The knowledge should extract the state per tunnel…
A proper “State” is ‘MM_ACTIVE’ or ‘AM_ACTIVE’. The absence of an entry, or any entry in another state, indicates that IKE is not configured properly.
ASA# sh crypto isakmp sa
IKEv1 SAs:
Active SA: 2
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 2
1 IKE Peer: 62.23.139.254
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE
2 IKE Peer: 195.110.91.242
Type : user Role : initiator
Rekey : no State : MM_KEY_EXCH
Run the next debug command in order to determine the location of the tunnel failure:
IKEv1 ‘debug crypto ikev1 127’
IKEv2: ‘debug crypto ikev2 protocol 127’and ‘debug crypto ikev2 platform 127’
Note: If the number of VPN tunnels on the ASA is significant, the debug crypto condition peer A.B.C.D command should be used before you enable the debugs in order to limit the debug outputs to include only the specified peer.
4. What are the Remediation Steps?
Use the “show crypto isakmp sa” command to view the Internet Security Association Management Protocol (ISAKMP) security associations (SAs) built between peers. If the state is either AM_ACTIVE or MM_ACTIVE ten the ISAKMP negotiations are completed otherwise there is a problem at phase1
You can simulate interesting traffic via the tunnel by running the next ASA command as is provided to the next example
“packet-tracer input Inside tcp 10.0.0.1 http 172.16.0.1 http” and then run the relevant debug commands to troubleshoot it
The isakmp sessions can be cleared with the next command “clear crypto isakmp sa”
In order to automatically verify whether the IPSec LAN-to-LAN configuration is valid, you can use the IPSec LAN-to-LAN Checker Cisco official tool. The tool is designed so that it accepts a show tech or show running-config command from either an ASA or IOS router. It performs a multi-point check of the configuration and highlights any configuration errors and settings for the tunnel that would be negotiated. You can get access there: https://cway.cisco.com/tools/L2L-Checker/
Run the next debug command in order to determine the location of the tunnel failure:
IKEv1 ‘debug crypto ikev1 127’
IKEv2: ‘debug crypto ikev2 protocol 127’and ‘debug crypto ikev2 platform 127’
Note: If the number of VPN tunnels on the ASA is significant, the debug crypto condition peer A.B.C.D command should be used before you enable the debugs in order to limit the debug outputs to include only the specified peer
5. Are there known ways to reproduce this issue?
Yes. Modify the pre-shared-key you are using on one end in order to not exactly matched, character by character.