DiagnosticsPrivileged EXEC

packet-tracer input [intf] tcp [src] [sport] [dst] [dport]

Simulates a packet traversing the firewall to verify ACL, NAT, and routing policies.

Overview

The packet-tracer command is a powerful diagnostic tool on Cisco ASA firewalls that simulates the path a packet would take through the device. It allows engineers to test ACLs, NAT rules, routing, and other security policies without sending actual traffic. This command is essential for troubleshooting connectivity issues, verifying policy changes, and understanding the order of operations within the ASA.

The command works by creating a virtual packet with specified source/destination IP, protocol, and ports, then processing it through the ASA's internal pipeline. The output shows each phase of processing, including route lookup, ACL checks, NAT translation, IP options, and flow creation. Each phase indicates whether the packet is allowed or dropped and provides the specific configuration that caused the result.

Packet-tracer is used in various scenarios: pre-deployment validation, post-change verification, and root cause analysis of denied traffic. It is platform-specific to Cisco ASA and Firepower Threat Defense (FTD) with similar syntax. Unlike Cisco IOS, which uses 'ping' or 'traceroute' for basic connectivity, ASA's packet-tracer provides deep insight into security policy enforcement. It is a must-know tool for CCNP Security and other Cisco certifications.

Syntax·Privileged EXEC

packet-tracer input [intf] tcp [src] [sport] [dst] [dport]

When to Use This Command

Verify that a TCP connection from an inside host to an outside server is permitted by ACLs.
Troubleshoot why a specific TCP flow is being dropped by the firewall.
Test NAT translation rules for inbound or outbound traffic.
Validate routing decisions for traffic entering a specific interface.

Parameters

Parameter	Syntax	Required	Description
intf	interface name (e.g., inside, outside)	Required	The name of the input interface where the simulated packet enters the ASA. Must be a configured interface name.
src	source IP address (e.g., 192.168.1.10)	Required	The source IP address of the simulated packet. Can be any valid IPv4 address.
sport	source port number (e.g., 12345)	Required	The source TCP or UDP port number. Must be an integer between 0 and 65535.
dst	destination IP address (e.g., 8.8.8.8)	Required	The destination IP address of the simulated packet.
dport	destination port number (e.g., 80)	Required	The destination TCP or UDP port number.

Command Examples

Basic TCP packet trace from inside to outside

packet-tracer input inside tcp 192.168.1.10 12345 8.8.8.8 80

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
Destination: 8.8.8.8

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inside-in in interface inside
access-list inside-in extended permit ip any any
Additional Information:

Phase: 3
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 4
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: FLOW-CREATION
Subtype: 
Result: ALLOW
Config:
Additional Information:

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

The trace shows each phase the packet goes through. Phase 1 is a route lookup to determine the egress interface. Phase 2 checks the ACL applied to the inside interface; here it matches a permit all rule. Phase 3 is NAT (no translation in this case). Phase 4 checks IP options. Phase 5 creates a flow. The final result shows the action is 'allow' and the output interface is 'outside'.

Packet trace with NAT translation

packet-tracer input inside tcp 10.1.1.100 5000 203.0.113.50 443

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
Destination: 203.0.113.50

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inside-in in interface inside
access-list inside-in extended permit ip 10.1.1.0 255.255.255.0 any
Additional Information:

Phase: 3
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
object network obj-10.1.1.100
 nat (inside,outside) dynamic interface
Additional Information:
Dynamic translate 10.1.1.100/5000 to 198.51.100.1/5000

Phase: 4
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: FLOW-CREATION
Subtype: 
Result: ALLOW
Config:
Additional Information:

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

This trace shows NAT occurring in Phase 3. The source IP 10.1.1.100 is translated to the outside interface IP 198.51.100.1 with a dynamic PAT. The ACL in Phase 2 permits the source subnet. The final action is allow.

Understanding the Output

The output is divided into phases, each representing a processing step. The first phase is always a route lookup to determine the egress interface. Subsequent phases include ACL checks, NAT translations, IP option inspection, and flow creation. Each phase shows the type, subtype, result (ALLOW or DROP), and the configuration that caused the result. The final summary shows the input and output interface status and the overall action (allow or drop). Key fields to examine: 'Result' in each phase indicates if the packet passed that check. If any phase shows DROP, the packet is denied. The 'Config' field shows the specific rule or object that matched. The 'Additional Information' field provides details like translated addresses. The final 'Action' line gives the overall verdict. Healthy output shows ALLOW in all phases and 'Action: allow'. Problematic output shows DROP in a phase; for example, an ACL deny will show 'Result: DROP' in the ACCESS-LIST phase, and the 'Config' field will indicate the deny rule. NAT failures may show 'Result: DROP' in the NAT phase with an error message.

Configuration Scenarios

Verifying ACL and NAT for Outbound Web Traffic

An internal host (10.1.1.100) needs to access a web server at 203.0.113.50 on port 443. The ASA has an ACL permitting the inside subnet and a dynamic PAT rule for outbound traffic.

Topology

Host (10.1.1.100) --- [inside] ASA [outside] --- Web Server (203.0.113.50)

Steps

1.Configure the inside ACL to permit traffic from 10.1.1.0/24 to any.
2.Configure dynamic PAT for the inside network to the outside interface.
3.Run packet-tracer input inside tcp 10.1.1.100 5000 203.0.113.50 443.
4.Verify that all phases show ALLOW and the final action is allow.

Configuration

! ACL
access-list inside-in extended permit ip 10.1.1.0 255.255.255.0 any
access-group inside-in in interface inside
! NAT
object network obj-10.1.1.0
 subnet 10.1.1.0 255.255.255.0
 nat (inside,outside) dynamic interface

Verify: Run the packet-tracer command and check that Phase 2 (ACCESS-LIST) shows ALLOW with the permit rule, Phase 3 (NAT) shows translation to the outside interface IP, and final action is allow.

Watch out: If the ACL is missing or denies the source subnet, the packet will be dropped at Phase 2. Ensure the ACL is applied to the correct interface and direction.

Troubleshooting with This Command

When a packet-tracer shows a DROP, the first step is to identify which phase caused the drop. Common phases: ROUTE-LOOKUP (no route to destination), ACCESS-LIST (denied by ACL), NAT (no NAT rule or misconfiguration), IP-OPTIONS (malformed packet). For ACL drops, check the 'Config' field for the specific deny rule. For NAT drops, verify that a NAT rule exists for the source/destination combination and that the interface is correct.

If the result shows 'Action: drop' but no specific phase shows DROP, check the final summary for additional information. Sometimes the drop occurs due to TCP state or other advanced inspections. Use 'packet-tracer' with the 'detailed' keyword to get more verbose output.

Another useful technique is to trace the reverse path (from outside to inside) to verify inbound policies. Always ensure the input interface is correct; tracing from the wrong interface will give misleading results. If the trace shows ALLOW but actual traffic is still blocked, consider other factors like routing asymmetries, interface ACLs in the opposite direction, or global inspection policies.

CCNA Exam Tips

Remember that packet-tracer is the primary tool for verifying traffic flow; be able to interpret each phase.

Know that the command does not actually send packets; it simulates the path based on current configuration.

Practice tracing packets with different source/destination IPs and ports to understand ACL and NAT interactions.

Common Mistakes

Forgetting to specify the correct input interface; the trace will fail or give misleading results.

Assuming packet-tracer shows real-time traffic; it only simulates based on current config.

Misinterpreting a DROP in the NAT phase as a routing issue; it's usually a missing or misconfigured NAT rule.

Platform Notes

On Cisco ASA, the packet-tracer command is available in privileged EXEC mode. It is similar to the 'test' command on Cisco IOS firewalls but more comprehensive. On Firepower Threat Defense (FTD), the command is 'packet-tracer' as well, but the output format may differ slightly. In ASA version 9.x and later, the command supports additional options like 'detailed' and 'xml' for machine parsing.

Unlike Cisco IOS, where 'ping' and 'traceroute' are primary troubleshooting tools, ASA relies heavily on packet-tracer for policy verification. The command does not require any special licensing and is available in all feature sets. When migrating from ASA to FTD, the packet-tracer syntax remains largely the same, but the output may include additional phases for intrusion prevention (IPS) if configured.

For older ASA versions (pre-8.4), the NAT configuration syntax differs, but the packet-tracer command works similarly. Always check the version documentation for any subtle differences.

Practice for the CCNA 200-301

Test your knowledge with hundreds of CCNA practice questions covering all exam domains.

Practice CCNA Questions