Troubleshoot Cisco ASA firewalls

A structured set of Cisco Secure Firewall ASA commands for checking resource use, connection state, NAT, packet drops, captures, high availability and VPN status.

ⓘ

Validation status

Reviewed against the current Cisco Secure Firewall ASA 9.17 General Operations troubleshooting documentation and current Cisco ASA packet-capture guidance on 27 September 2026.

!

Use captures and debug carefully

Packet captures, ASP-drop captures, verbose logging and debug commands can generate significant output on busy appliances. Scope captures to the affected traffic where possible and remove temporary troubleshooting configuration after use.

System health

>_CPU, memory and platform state

show cpu usage
show memory
show version
show module

Connections, NAT and routing

>_Connection and translation state

show conn
show xlate
show local-host
show route

When investigating a single flow, correlate connection state with the expected NAT and route selection rather than relying on only one command.

Service policy and packet drops

>_Inspection and ASP drop counters

show service-policy
show asp drop

For a short controlled test, clearing the ASP counters immediately before reproducing the problem can make new drops easier to identify.

>_Reset and re-check ASP drop counters

clear asp drop
show asp drop

Cisco documents drop-reason keywords in show asp drop; once the relevant reason is known, use a scoped ASP capture where possible instead of collecting every drop on a busy firewall.

Packet-tracer

Use packet-tracer to evaluate how ASA processes a representative packet through NAT, access policy, inspection and routing logic.

>_Example TCP packet-tracer

packet-tracer input inside tcp 192.0.2.10 12345 198.51.100.20 443 detailed

Use addresses, interfaces and ports that match the real flow being investigated.

Packet capture

Create a scoped capture on the relevant interface:

>_Example interface capture

capture CAP-IN interface inside match tcp host 192.0.2.10 host 198.51.100.20 eq 443
show capture CAP-IN

Remove the temporary capture when finished:

>_Remove the capture

no capture CAP-IN

ASP-drop capture

If show asp drop identifies firewall drops, an ASP-drop capture can provide the dropped packets and reason.

>_Capture ASP drops

capture ASP-DROP type asp-drop all
show capture ASP-DROP

!

Scope ASP captures on busy systems

type asp-drop all can collect a large volume of traffic. Prefer a specific drop reason when one is known, and stop/remove the capture promptly after reproducing the issue.

>_Remove the ASP capture

no capture ASP-DROP

High availability

>_Failover state

show failover

Confirm the active/standby roles and interface states before making configuration changes during an incident.

Logging

>_Review ASA logging

show logging

Increase logging or enable debug output only when necessary and with an understanding of the potential operational impact.

VPN state

For IPsec VPN troubleshooting, use the command appropriate to the configured IKE version:

>_VPN security associations

show crypto ikev1 sa
show crypto ikev2 sa
show crypto ipsec sa

Not every deployment uses both IKEv1 and IKEv2; run the commands that match the configured VPN.

Suggested workflow

Confirm interface, route and failover state.
Check connection and translation state.
Use packet-tracer with the exact affected flow.
Review show asp drop for relevant drop reasons.
Take a tightly scoped packet capture.
Review VPN SAs if the path crosses an IPsec tunnel.
Use deeper debugging only if the lower-impact checks do not identify the issue.
Remove temporary captures and troubleshooting configuration.