flow diagnostic ( cisco ASA )

In these next series of posts, I went over some of the basic diagnostic  methods for netscreen, fortigate. I'm wrapping this series up with the cisco ASA, which is similar but quite different and even simpler.

 As firewall admins, we need to know how to aid in t-shooting. Blindly changing rules, rebooting, and host of other steps are typically a hail mary and accomplish nothing.

1^st up,

Flow diagnostic  on the cisco ASA are just as simple as juniper/fortigate;

2nd, unlike the previous flow diagnostic posted earlier, the cisco ASA does not require real user data, you can simulate the traffic in order to validate the flow and fwpolicy handling. This is process is known simply as packet-tracer. So you can test your fwpolicy, encryption,nat,etc...... with out having REAL data.

So look at it as pre-trouble-shooting before going live :)

3rd

we need to used the intergral packet-tracer cmd and specify the following;

• src interface
• protocol
• src/dst port ( if proto = udp/tcp )
• icmp type  ( if proto #1 icmp )
• detail is optional
• XML format is optional
  

• asaken# 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
  
  
  

4th

Here's a few samples ( ipv4 ) using the same example a host inside going to one of Google DNS servers;

 cmd
 

-->

asaken# packet-tracer  input  inside udp 192.168.110.11 1234 8.8.8.8 53

-->

And the following diagnostic will be learned;

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   0.0.0.0         0.0.0.0         outside

Phase: 3

Type: NAT

Subtype:

Result: ALLOW

Config:

object network inside

 nat (inside,outside) dynamic interface

Additional Information:

Dynamic translate 192.168.110.11/1234 to 192.0.2.1/1234

Phase: 4

Type: NAT

Subtype: per-session

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type: INSPECT

Subtype: np-inspect

Result: ALLOW

Config:

Additional Information:

Phase: 7     

Type: HOST-LIMIT

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 8

Type: NAT

Subtype: per-session

Result: ALLOW

Config:

Additional Information:

Phase: 9

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 10

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 347, 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

 here's a deny for example;

-->

And here’s a deny for example;

asaken# packet-tracer  input  inside udp 192.168.110.11 1111 192.168.110.12 53$

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   192.168.110.0   255.255.255.0   inside

Phase: 2

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

 Forward Flow based lookup yields rule:

 in  id=0xda05f258, priority=111, domain=permit, deny=true

            hits=1, user_data=0x0, cs_id=0x0, flags=0x4000, protocol=0

            src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0

            dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0 dscp=0x0

            input_ifc=inside, output_ifc=inside

Result:

input-interface: inside

input-status: up

input-line-status: up

output-interface: inside

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

The above was deny due to the src/dst was the same as the inside subnet  I also used the  detail option for that above example.

Here's  another deny, but with the format changed to xml;

asaken# packet-tracer  input  inside udp 192.168.111.11 1111 192.168.110.12 53$

<Phase>

<id>1</id>

<type>ROUTE-LOOKUP</type>

<subtype>input</subtype>

<result>ALLOW</result>

<config>

</config>

<extra>

in   192.168.110.0   255.255.255.0   inside

</extra>

</Phase>

<Phase>

<id>2</id>

<type>ACCESS-LIST</type>

<subtype></subtype>

<result>DROP</result>

<config>

Implicit Rule

</config>

<extra>

 Forward Flow based lookup yields rule:

 in  id=0xda05f258, priority=111, domain=permit, deny=true

            hits=3, user_data=0x0, cs_id=0x0, flags=0x4000, protocol=0

        src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0

            dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0 dscp=0x0

            input_ifc=inside, output_ifc=inside

</extra>

</Phase>

<result>

<input-interface>inside</input-interface>

<input-status>up</input-status>

<input-line-status>up</input-line-status>

<output-interface>inside</output-interface>

<output-status>up</output-status>

<output-line-status>up</output-line-status>

<action>drop</action>

<drop-reason>(acl-drop) Flow is denied by configured rule</drop-reason>

</result>

and finally, here's a ipv6 packet-trace


-->
asaken#   packet-tracer input inside tcp 2002:100::44bf:21b9:296f:9656 1234 2$  -->

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   2001:db8::      ffff:ffff:ffff:ffff:: outside

Phase: 3

Type: NAT

Subtype: per-session

Result: ALLOW

Config:

Additional Information:

Phase: 4     

Type: HOST-LIMIT

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: NAT

Subtype: per-session

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 882, 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

Each trace is marked and the key take aways are the following;

  

    

•   Interface dst/src ( directionality ) 
•     Session allocation
•   if SNAT/DNAT is applicable ( NAT )
•   the Allowed or Denied ( action )

I hope these series of post are helpful in your l3/l4 diagnostic.

Ken Felix
Freelance Network/Security Engineer
kfelix a-t hyperfeed-d-o-t-com