Cisco ASA packet-tracer: Troubleshooting Access Problems

packet-tracer is the single most valuable command on a Cisco ASA: it injects a simulated packet into the data path and reports the result of every check — route lookup, ACL, NAT, inspection, adjacency — phase by phase. Instead of guessing whether an outage is an ACL problem, a NAT problem or something upstream, you get the exact configuration line that matched and the reason the packet was dropped. The catch is that the final "Action: drop" often reflects something other than the phase you expected, so reading the phases in order is the whole skill.

Syntax and the 5-tuple

packet-tracer input <ingress-interface> <protocol> <src-ip> <src-port> <dst-ip> <dst-port>

ASA-PERIM# packet-tracer input inside tcp 10.10.10.50 12345 8.8.8.8 443
ASA-PERIM# packet-tracer input outside tcp 203.0.113.50 33000 198.51.100.10 80

! ICMP takes type/code/identifier instead of ports
ASA-PERIM# packet-tracer input outside icmp 1.1.1.1 8 0 198.51.100.10

The destination IP must be the address as it appears on the wire from the ingress side, which is the point that confuses people most on NAT-heavy configurations. Source port is arbitrary; use a high port that will not collide with an existing translation. Useful flags:

• detailed — expands object groups and ACL hit details.
• xml — machine-readable output for scripting.
• vlan-id <n> — tag the simulated packet when the ingress is a trunk subinterface.
• decrypted — simulate the inner packet as if a VPN engine had already decrypted it.
• persist — keep the simulated flow in the connection table so show conn can display it.

Reading the phases

ASA-PERIM# packet-tracer input inside tcp 10.10.10.50 12345 8.8.8.8 443
Phase: 1
Type: ACCESS-LIST
Result: ALLOW
Config:
Implicit Rule
Phase: 2
Type: INPUT-ROUTE-LOOKUP
Result: ALLOW
Additional Information:
Found next-hop 203.0.113.1 using egress ifc outside
Phase: 3
Type: NAT
Result: ALLOW
Config:
object network INSIDE-NET
 nat (inside,outside) dynamic interface
Additional Information:
Dynamic translate 10.10.10.50/12345 to 203.0.113.2/12345
Phase: 10
Type: FLOW-CREATION
Result: ALLOW
New flow created with id 4, packet dispatched to next module
Result:
input-interface: inside
output-interface: outside
Action: drop
Drop-reason: (no-v4-adjacency) No valid V4 adjacency. Check ARP table

Every phase above reports ALLOW, and the packet still drops. The reason is in the last line: there is no ARP entry for the next hop yet, so the ASA cannot build the egress frame. This pattern — end-to-end allows, final drop with no-v4-adjacency — is extremely common on ASA software 9.x during lab testing, because the simulation never triggers real ARP resolution. Read every phase, not just the final action: each ALLOW phase is confirmation that one configuration block is correct.

The drop reasons worth memorising

• acl-drop — an interface ACL denied the flow. The phase that fired prints the exact ACE, including a hit on the implicit deny.
• nat-no-xlate / nat-no-xlate-to-pat-pool — no NAT rule matched and the egress requires translation; often a missing dynamic NAT.
• nat-rpf-failed — the NAT reverse path check failed, usually because the route chosen does not match what NAT expected.
• no-route / no-v4-adjacency — no route, or no ARP entry for the next hop on the egress interface.
• sp-security-failed — uRPF anti-spoofing rejected the source.
• tcp-not-syn — a non-SYN packet arrived for a flow that does not exist; a classic asymmetric-routing or stale-client symptom.
• inspect-icmp-error-different-embedded-conn — an ICMP error for a flow the ASA does not have, again an asymmetric path tell.

Not blaming the ACL when it is innocent

ASA# show running-config access-list
ASA# show access-list OUTSIDE_IN
ASA# show asp drop
ASA# show asp drop frame acl-drop
ASA# show conn detail
ASA# show xlate

The workflow is three commands in order: packet-tracer answers "what happens to this exact packet", show access-list answers "is the line I edited being hit" (per-line counters and last-hit timestamps), and show asp drop answers "what is the ASA dropping in aggregate, and why". If phase 2 says ALLOW and the user still cannot connect, the failure is downstream of the ACL and you should stop editing it.

A four-step incident pattern

1. Test the flow exactly as the user reported it: same source, same destination, same port.
2. If it allows but the flow still fails, the ASA is not the problem; check the host, the downstream firewall and DNS.
3. If it drops, read the drop reason: acl-drop means ACL, nat-no-xlate means NAT, rpf-violated means asymmetric routing or anti-spoofing.
4. Test the reverse direction explicitly. The ASA does not assume reciprocity, and return-traffic problems only show up when you simulate from the far side.

Real packets, not just simulations

ASA# capture mycap interface outside match tcp host 203.0.113.50 host 198.51.100.10 eq 80
ASA# capture mycap access-list 199 interface outside trace
ASA# show capture mycap trace packet-number 3

The trace keyword makes the ASA trace the actual received packets that match the capture, bridging the gap between simulation and reality. Combine it with show conn detail and show asp drop and you have both the configuration verdict and the live evidence.

See also: Cisco ASA CLI basics, ASA site-to-site IPsec VPN configuration, and Firepower Threat Defense initial setup.

原文链接：https://pinglabz.com/cisco-asa-packet-tracer