Tuesday, June 14, 2011

ASA Firewall Packet-Tracer Command

One of my favorite Cisco commands is the "packet-tracer" command of the Cisco ASA Firewall. Haven't you ever wanted to know if the ACL you just wrote will  accomplish what you intended? And, how many times has somebody asked you, "Am I being blocked by the firewall?" Well, until now you just took an educated  guess based on your running-config or looked in the log for their IP address while scratching your head. (You know I'm right, I know I'm right, heck we've  all been there!)

Enough blabity blab, let's cut to the chase.
I've been tasked with finding out if tcp port 88 (Kerberos) is allowed out of the network. Since I know the source port and the IP of my webserver I can  start to walk through the "packet-tracer" command. (Let's pretend like we've never used the command...)

ASA1# packet-tracer ?    


  input  Ingress interface on which to trace packet

ASA1# packet-tracer input ?


Current available interface(s):
  DMZ     Name of interface Ethernet0/0
  INSIDE  Name of interface Ethernet0/1
  GUESTS    Name of interface Ethernet0/2
  DMZ_2   Name of interface Ethernet0/3


ASA1# packet-tracer input INSIDE ?


  icmp   Enter this keyword if the trace packet is ICMP
  rawip  Enter this keyword if the trace packet is RAW IP
  tcp    Enter this keyword if the trace packet is TCP
  udp    Enter this keyword if the trace packet is UDP


ASA1# packet-tracer input INSIDE tcp ?


  A.B.C.D     Enter the Source address if ipv4
  X:X:X:X::X  Enter the Source address if ipv6

ASA1# packet-tracer input INSIDE tcp 10.10.10.10 ?


  <0-65535>        Enter port number (0 - 65535)
  aol             
  bgp             
  chargen         
  cifs            
  citrix-ica      
  cmd             
  ctiqbe          
  daytime         
  discard         
  domain          
  echo            
  exec            
  finger          
  ftp             
  ftp-data        
  gopher 
  .....
  .....
        
ASA1# packet-tracer input INSIDE tcp 10.10.10.10 88 ?


  A.B.C.D  Enter the destination ipv4 address

ASA1# packet-tracer input INSIDE tcp 10.10.10.10 88 155.155.155.155 3028


Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   0.0.0.0         0.0.0.0         DMZ


Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group LAN_INCOMING in interface INSIDE
access-list LAN_INCOMING extended permit tcp host 10.10.10.10 any
Additional Information:


Phase: 3
Type: CONN-SETTINGS
Subtype:
Result: ALLOW
Config:
class-map classdefault
 match any
policy-map global_policy
 class classdefault
  set connection decrement-ttl
service-policy global_policy global
Additional Information:
             
Phase: 4     
Type: IP-OPTIONS
Subtype:     
Result: ALLOW
Config:      
Additional Information:
             
Phase: 5     
Type: NAT    
Subtype:     
Result: ALLOW
Config:      
nat (INSIDE,DMZ) source dynamic 10.10.10.10 262.1.2.3
Additional Information:
Dynamic translate 10.10.10.10/88 to 262.1.2.3/415
             
Phase: 6     
Type: ACCESS-LIST
Subtype: log 
Result: ALLOW
Config:      
access-group DMZ_LEAVING out interface DMZ
access-list DMZ_LEAVING extended permit tcp host 10.10.10.10 any
Additional Information:
             
Phase: 7     
Type: IP-OPTIONS
Subtype:     
Result: ALLOW
Config:      
Additional Information:
             
Phase: 8     
Type: FLOW-CREATION
Subtype:     
Result: ALLOW
Config:      
Additional Information:
New flow created with id 54311482, packet dispatched to next module
             
Result:      
input-interface: INSIDE
input-status: up
input-line-status: up
output-interface: DMZ
output-status: up
output-line-status: up
Action: allow       
ASA1#

The bottom line is yes, 88 is allowed out from the 10.10.10.10 address.
Look at all the juicy info we can see, what access-lists and access-groups it had to traverse, the NAT statement in play, and the dynamic translation. Sweet!
(If you really want some verbose output try adding "detailed" to the end of the command.)
If we had failed it would have shown something like this...

ASA1# packet-tracer input INSIDE tcp 10.10.10.10 22 155.155.155.155 3028
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   0.0.0.0         0.0.0.0         DMZ


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


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

See the "Implicit Rule" in the above output? This is the "implicit deny" that catches things you don't "explicitly allow." You've just seen it in play here.

Well, there you go. Have fun with this baby!

Please email this link to a pal. Thanks!

5 comments:

  1. Hi, I like this feature but I'm trying to use this on a production node. My question to you is, when you don't know the source port # how would you use this feature?

    Thanks!

    ReplyDelete
    Replies
    1. The source port from "packet-tracer's" perspective is always unimportant. It just needs to be an ephemeral port (something above 1024).
      Typically in client-server communication, the client uses an ephemeral port to request something from the server. Different services are associated with different ports on the server. These are referred to as "listening ports." So, a web server usually "listens" on ports 80, 443 (http/https).
      Hope that's clear as mud!!

      Author

      Delete
  2. Good and Thank you

    ReplyDelete
  3. In your examples, in phase 2 ACL, you get an allow in the top example, and that packet will be allowed to pass.
    In the bottom example using ssh, phase 2 gives you drop with no acl lines or acl name, and you get a drop as the end result.
    I'm troubleshooting not being able to get an icmp request back from a host on the inside to the outside. I'm getting an allow in phase 2 with a line from the acl on the inside int, but getting a drop in the end for reason "(acl-drop) Flow is denied by configured rule" with no more explanation given to indicate which acl or rule.
    What gives?

    ReplyDelete
  4. So, if I'm reading this right, you're pinging something external from an internal host. Also, you mention an acl on the inside interface. Check your acl applied to the outside interface and make sure you're allowing icmp traffic from the external destination.

    ReplyDelete