The Usage of the Packet-Tracer Feature on the ASA

Hello Everyone,

 

I am going to talk today about one of the most fundamental and useful features that the ASA will provide us : “The Packet-Tracer”.

This tool is unique for the ASA and it’s main function is to let us know if a packet  will be permitted or denied by the configuration of the security appliance so it will basically show us all of the security checks that a packet must go through in order to be allowed with an ASA.

 

The Syntax:

packet-tracer input interface_nameif  protocol source_IP_Address Source_Port Destination_Ip_Address Destination_Port

Let’s break it down:

Interface nameif: Where the packet comes from, where the connection is being initiated

Source IP address: Source IP address of the connection

Source Port: Source port of the packet (usually random and higher than 1024)

Destination IP address: Destination IP address of the packet

Destination Port: Destination port of the packet (normally the well known protocol, example: HTTP/80 ,SMTP/25, SSH/22, etc)

 

Let’s take a look at our scenario today

ASA Inside Outside Basic Scenario

So pretty simple scenario:

  • 2 Subnets being protected by an ASA
  • On each side of the networks we have a router that we will use to generate some traffic
  • Routers IP addresses are 192.168.10.100 and 192.168.20.100 respectively
  • The ASA IP addresses are 192.168.10.1 and 192.168.20.1 respectively
  • Each router has as it’s default gateway the ASA

Let’s see the basic configuration so far

R1:

hostname R1
interface FastEthernet1/0
ip address 192.168.10.100 255.255.255.0
duplex auto
speed auto
ip route 0.0.0.0 0.0.0.0 192.168.10.1

R2

hostname R2
interface FastEthernet1/0
ip address 192.168.20.100 255.255.255.0
duplex auto
speed auto
ip route 0.0.0.0 0.0.0.0 192.168.20.1

ASA

ASA Version 8.4(2)
hostname ciscoasa
interface GigabitEthernet0
nameif outside
security-level 0
ip address 192.168.20.1 255.255.255.0
!
interface GigabitEthernet1
nameif inside
security-level 100
ip address 192.168.10.1 255.255.255.0

 

So that’s it, that’s all we need to have connectivity between the ASA to R1 and the ASA to R2

ciscoasa(config)# ping 192.168.10.100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 10/30/60 ms
ciscoasa(config)# ping 192.168.20.100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.20.100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 10/20/40 ms

Scenario 1

Now, what do you think is going to happen if we ping from 192.168.10.100 to 192.168.20.100?

Answer/We are not able to ping the device

R1(config)#do ping 192.168.20.100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.20.100, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

Hmm, okay but why is that happening?

Let’s say we do not know at this moment the cause of the issue so we want to determine why is the traffic failing while passing through the ASA (A perfect scenario to use the amazing Packet-Tracer tool)

The Packet-Tracer command should be:

packet-tracer input inside icmp 192.168.10.100 8 0 192.168.20.100

Inside: Name_If of the interface where the traffic is being originated

icmp: Protocol being used

8 0 : ICMP type and code

 

packet-tracer input inside icmp 192.168.10.100 8 0 192.168.$

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 192.168.20.0 255.255.255.0 outside

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

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

Phase: 5
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 11, 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

Based on the previous output it seems like we should be able to ping the router at 192.168.20.100 right?

I mean everything is allowed , no policy denying the traffic… Well that’s what the Packet-Tracer shows on this particular scenario but if we go a little bit deeper with the command using the ¨detail¨ keyword at the end we are going to see something unique for the ICMP protocol.

packet-tracer input inside icmp 192.168.10.100 8 0 192.168.20.100 detail

ciscoasa(config)# packet-tracer input inside icmp 192.168.10.100 8 0 192.168.2$

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 192.168.20.0 255.255.255.0 outside

Phase: 2
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xbc2d7070, priority=0, domain=inspect-ip-options, deny=true
hits=7, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
input_ifc=inside, output_ifc=any

Phase: 3
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xbc2d6c48, priority=66, domain=inspect-icmp-error, deny=false
hits=7, user_data=0xbc2d6260, cs_id=0x0, use_real_addr, flags=0x0, protocol=1
src ip/id=0.0.0.0, mask=0.0.0.0, icmp-type=0
dst ip/id=0.0.0.0, mask=0.0.0.0, icmp-code=0, dscp=0x0
input_ifc=inside, output_ifc=any

Phase: 4
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 14, packet dispatched to next module
Module information for forward flow …
snp_fp_tracer_drop
snp_fp_inspect_ip_options
snp_fp_adjacency
snp_fp_fragment
snp_ifc_stat

Module information for reverse flow …

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

As we can see on the highlighted statement the ICMP packet is not going through an ASA inspection, it’s saying this packet is not being inspected.

Is there a problem with that?

YES, a gold rule for us:

When  we work with the ICMP protocol across the ASA we must inspect it as the ICMP protocol is stateless (not oriented to connection) so the ASA will not be able to permit the returning traffic because it does not know it belongs to a valid connection

So let’s add the ICMP inspection and see if it works:

The only command need it is:

ciscoasa(config)# fixup protocol icmp
INFO: converting ‘fixup protocol icmp ‘ to MPF commands

Easy right, now let’s do the ping again from R1

R1(config)#do ping 192.168.20.100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.20.100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/71/96 ms

Awesome, let’s see what the packet-tracer would say now

ciscoasa(config)# packet-tracer input inside icmp 192.168.10.100 8 0 192.168.2$

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 192.168.20.0 255.255.255.0 outside

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

Phase: 3
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: 4
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:

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

Phase: 6
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 21, 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

We can see now in phase 3 that is being inspected, that’s what made it work, We were missing just one command.

Note: This scenario did not show an easy example of when by just reading the general output of the Packet-Tracer we will get to the solution. I wanted to point the fact that sometimes we must understand the traffic patterns and then check the policies the ASA is taking.

 

Scenario 2

This time we will try to telnet from the router at 192.168.20.100 (R2) to the router at 192.168.10.1 (R1)

We will add the following configuration on R1 so it starts accepting connections on it’s VTY lines.

R1(config)#line vty 0 4
R1(config-line)#pas
R1(config-line)#password cisco123

Note: password cisco123 is not secure at all, do NOT use it on a live environment.

Okey now let’s telnet:

R2#telnet 192.168.10.100
Trying 192.168.10.100 …
% Connection timed out; remote host not responding

Remote not responding , hmm but we have configured everything on R1 to allow the connection, another useful scenario to use the Packet-Tracer tool

 

packet-tracer input outside tcp 192.168.20.100 1025 192.168.10.100 23

outside: Nameif of the interface where the traffic is being originated

TCP: Protocol being used at the transport layer to handle the communication

1025: Source port (We will use any random port {from 1024 to 65535)

23: Destination port (Telnet works over TCP port 23

Now that we explain why we use each of the parameters let’s see the result

packet-tracer input outside tcp 192.168.20.100 1025 192.168.10.100 23

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 192.168.10.0 255.255.255.0 inside

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

Result:
input-interface: outside
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

This scenario is more implicit as we can determine just by reading the output what’s the cause of the issue, on this case we need an acl to fix this.

 

Why is that:

 

Another rule of thumb:

 

“On the ASA traffic from a higher security level to a lower security level is allowed by default but from a lower security level to a higher security level an ACL must be configured to allow the traffic”

 

With the command show name-if we are going to see each of the interfaces name_if we have configured on the ASA and their respective security level value:

 

ciscoasa(config)# sh nameif
Interface Name Security
GigabitEthernet0 outside 0
GigabitEthernet1 inside 100

 

In this scenario the communication is getting started from Outside which has a security level of 0 and we are going to inside which has a security level of 100, we must use an ACL to allow this traffic and apply it to the lower security level interface.

 

access-list Outside_In extended permit tcp host 192.168.20.100 host 192.168.10.100 eq telnet
access-group Outside_In in interface outside

 

Done let’s now see the Packet-Tracer:

 

ciscoasa(config)# packet-tracer input outside tcp 192.168.20.100 1025 192.168.$

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 192.168.10.0 255.255.255.0 inside

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group Outside_In in interface outside
access-list Outside_In extended permit tcp host 192.168.20.100 host 192.168.10.100 eq telnet
Additional Information:

Phase: 3
Type: IP-OPTIONS
Subtype:
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:
New flow created with id 22, packet dispatched to next module

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

 

Awesome we can see how the ASA checks the ACL on the outside interface and allows the traffic.

 

R2#telnet 192.168.10.100
Trying 192.168.10.100 … Open
User Access Verification

Password:
R1>

We did it.

On this post we have seen what the Packet-Tracer tool exists for and 2 rules of thumb when we talk about ASA’s

Regards,