Using Cisco ASA Packet-Tracer to Diagnose Issues

Cisco ASA Packet-Tracer Utility Overview:

The Cisco ASA Packet-Tracer utility is a handy utility for diagnosing whether traffic is able to traverse through an ASA firewall. It has the following capabilities:

• Allows the user to specify which interface the traffic originates from.
• Allows the user to spoof traffic from any source.
• Supports object-groups for source and destination
• Supports UDP, TCP, RawIP, and ICMP traffic.
• Provides step-by-step detail to show how the traffic traverses various access lists and NAT configurations.

Using Packet-Tracer:

• • Login to the ASA and go to enable mode:

     login as: peiadmin
     peiadmin@10.222.0.5's password:
     Type help or '?' for a list of available commands.
     Pei-Hq-Fw01> en
     Password: Pei-Hq-Fw01#

• Gather the required information for your packet trace:
  • The interface you wish the traffic to originate from
  • The type of traffic you wish to spoof, with TCP, UDP, ICMP (all types) or RawIP traffic supported.
  • The source port (if applicable) you want the traffic to originate from.
  • The destination port (again, if applicable) you want the traffic to be destined to.
• Now type in the command, syntax is

   packet-tracer input $source-interface $traffic-type $src_address $src_proto $src_proto_options $dest_address

   

   

  In this instance let’s test

• Inside interface address
• ICMP traffic
• Destined for google 8s

Pei-Hq-Fw01# packet-tracer input inside icmp 10.222.0.5 8 0 8.8.8.8

Phase: 1
 Type: ROUTE-LOOKUP
 Subtype: Resolve Egress Interface
 Result: ALLOW
 Config:
 Additional Information:
 found next-hop 209.66.66.1 using egress ifc OUTSIDE

Phase: 2
 Type: ACCESS-LIST
 Subtype:
 Result: DROPDiagno
 Config:
 Implicit Rule
 Additional Information:

Result:
 input-interface: inside
 input-status: up
 input-line-status: up
 output-interface: OUTSIDE
 output-status: up
 output-line-status: up
 Action: drop
 Drop-reason: (acl-drop) Flow is denied by configured rule

• As you can see from the above, the ASA routed the test to the outside interface of the device where it was dropped by an ACL applied there. This makes sense since the source IP we utilized is the IP of the inside interface itself and not part of NAT rules to the outside.
• Let’s do the same test on a known good server:

Pei-Hq-Fw01# packet-tracer input inside icmp 10.222.0.200 8 0 8.8.8.8

Phase: 1
 Type: ROUTE-LOOKUP
 Subtype: Resolve Egress Interface
 Result: ALLOW
 Config:
 Additional Information:
 found next-hop 209.66.66.1 using egress ifc OUTSIDE

Phase: 2
 Type: NAT
 Subtype:
 Result: ALLOW
 Config:
 object network REDOUBT
 nat (inside,OUTSIDE) static 209.66.66.66
 Additional Information:
 Static translate 10.222.0.200/0 to 209.66.66.66/0

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: INSPECT
 Subtype: np-inspect
 Result: ALLOW
 Config:
 class-map inspection_default
 match default-inspection-traffic
 policy-map global_policy
 class inspection_default
 inspect icmp
 service-policy global_policy global
 Additional Information:

Phase: 6
 Type: INSPECT
 Subtype: np-inspect
 Result: ALLOW
 Config:
 Additional Information:

Phase: 7
 Type: NAT
 Subtype: rpf-check
 Result: ALLOW
 Config:
 nat (any,OUTSIDE) after-auto source dynamic any interface
 Additional Information:

Phase: 8
 Type: USER-STATISTICS
 Subtype: user-statistics
 Result: ALLOW
 Config:
 Additional Information:

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

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

Phase: 11
 Type: USER-STATISTICS
 Subtype: user-statistics
 Result: ALLOW
 Config:
 Additional Information:

Phase: 12
 Type: FLOW-CREATION
 Subtype:
 Result: ALLOW
 Config:
 Additional Information:
 New flow created with id 725694429, packet dispatched to next module

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

• As you can see above, the ping passes through the outside to google successfully.
  • You can see the initial routing decision(Phase 1),
  • that the traffic hit the outside interface NAT (Phase 2 & 3)
  • and that it passed ICMP inspection (Phase 5).

Max Fuller, PEI