Troubleshooting Tool Enhancements in ASA v9.9 Code – Part 1

July 9th, 2018
Troubleshooting Tool Enhancements in ASA v9.9 Code – Part 1

*** Packet-tracer Enhancements in ASA 9.9 code ***

 

The packet-tracer and capture utilities built into Cisco ASA's, and now Firepower appliances as of v6.1, are great "go to" troubleshooting tools for Cisco firewall administrators.  The packet-tracer and the capture utilities can be used in combination or used as separate tools depending on the situation. 

 

Packet-tracer allows the simulation of a particular traffic flow to see how it will be handled while being processed by the firewall.  The capture utility allows administrators to run packet captures directly on the firewall appliance which can then be reviewed directly on the ASA or can be downloaded and reviewed using a protocol analyzer such as Wireshark.

 

Some of the useful information that the packet-tracer utility provides once a trace is completed includes: which interface the packet will exit, if the flow matches any particular access-lists and if the traffic is permitted or denied, if and how the traffic will be translated, if the packet will be encrypted, as well as many other useful items.  This tool allows for us engineers to validate configuration changes confirming functionality prior to closing out a change request. 

 

With ASA v9.9 code, Cisco has included some extremely welcome additions to the already-awesome packet-tracer and capture utilities.  A few of the enhancements that I'm excited about include now being able to actually send the simulated packet to the destination address in order for the remote host to receive and process the packet.  This ability to now transmit the simulated packet assists with verifying that the remote destination host receives the traffic and if the ASA receives a response if expected.

 

Using the sample topology below, I wanted to demonstrate the new packet-tracer transmit feature.

 

 

In this sample topology, I will be using R01 as the client workstation and will use R02 as the destination web server.  Between these two routers include ASA1, a provider router, and ASA2.  The ASA's have an IKEv2 IPsec VPN tunnel established and the Provider router is acting as a transit router between the two firewalls.

 

For these examples, I will be sending a tcp/80 request from R01 (10.0.1.1) acting as the client over to R02 (10.0.2.1) acting as the server.

 

During this example, I will also be running a packet capture on ASA1 filtering traffic specifically between R01 and R02.

 

ASA1(config)# sho run access-l cap

access-list cap extended permit ip host 10.0.1.1 host 10.0.2.1

access-list cap extended permit ip host 10.0.2.1 host 10.0.1.1

ASA1(config)#

ASA1(config)# sho cap

capture cap type raw-data access-list cap interface inside [Capturing - 0 bytes]

ASA1(config)#

 

The first example below, we will take a look at using packet-tracer without using the new “transmit” option.  During the packet-tracer, we can see each step including any ACL's being hit, which exit interface the traffic will use, if/how how the traffic will be translated, etc. 

 

ASA1(config)# packet-tracer input inside tcp 10.0.1.1 32000 10.0.2.1 80

Phase: 1

Type: CAPTURE

Subtype:

Result: ALLOW

Config:

Additional Information:

MAC Access list

Phase: 2

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 3

Type: ROUTE-LOOKUP

Subtype: Resolve Egress Interface

Result: ALLOW

Config:

Additional Information:

found next-hop 198.18.1.1 using egress ifc  outside

Phase: 4

Type: UN-NAT

Subtype: static

Result: ALLOW

Config:

nat (inside,outside) source static inside inside destination static site2 site2 no-proxy-arp route-lookup

Additional Information:

NAT divert to egress interface outside

Untranslate 10.0.2.1/80 to 10.0.2.1/80

Phase: 5

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group inside in interface inside

access-list inside extended permit ip any4 any4

Additional Information:

Phase: 6

Type: NAT

Subtype:     

Result: ALLOW

Config:

nat (inside,outside) source static inside inside destination static site2 site2 no-proxy-arp route-lookup

Additional Information:

Static translate 10.0.1.1/32000 to 10.0.1.1/32000

Phase: 7

Type: NAT

Subtype: per-session

Result: ALLOW

Config:

Additional Information:

Phase: 8

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 9

Type: QOS

Subtype:     

Result: ALLOW

Config:

Additional Information:

Phase: 10

Type: CAPTURE

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 11

Type: VPN

Subtype: encrypt

Result: ALLOW

Config:

Additional Information:

Phase: 12

Type: NAT

Subtype: rpf-check

Result: ALLOW

Config:      

nat (inside,outside) source static inside inside destination static site2 site2 no-proxy-arp route-lookup

Additional Information:

Phase: 13

Type: VPN

Subtype: ipsec-tunnel-flow

Result: ALLOW

Config:

Additional Information:

Phase: 14

Type: QOS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 15

Type: NAT

Subtype: per-session

Result: ALLOW

Config:

Additional Information:

Phase: 16

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 17

Type: CAPTURE

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 18

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

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

ASA1(config)#

 

With the packet-tracer complete, when we take a look at the capture below, we will see that the ASA processed the packet and created the flow, but the packet did not leave the ASA.

 

ASA1(config)# sho cap cap

1 packet captured

   1: 16:38:36.544115       10.0.1.1.32000 > 10.0.2.1.80: S 1550136167:1550136167(0) win 8192

1 packet shown

ASA1(config)#

 

 

In this next example, we will add the "transmit" option to the same packet-tracer.  In this new packet-tracer, we will see the same results in the packet-tracer output, only this time the packet exited the ASA and was sent to the remote destination host.  We can verify this within the capture.

 

ASA1(config)# packet-tracer input inside tcp 10.0.1.1 32000 10.0.2.1 80 transmit

Phase: 1

Type: CAPTURE

Subtype:

Result: ALLOW

Config:

Additional Information:

MAC Access list

.....

omitted for brevity

.....

Phase: 18

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

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

ASA1(config)#

 

Taking a look at this new capture, we can see that the packet-tracer output appears the same, but this time, the packet was sent to the remote destination, the remote destination processed the request, and responded to the simulated packet back to the client, R01.  Since R01 did not send the actual request, R01 then responded with a reset back to R02.

 

ASA1(config)# sho cap cap

3 packets captured

   1: 16:43:19.486852       10.0.1.1.32000 > 10.0.2.1.80: S 115026015:115026015(0) win 8192

   2: 16:43:19.611677       10.0.2.1.80 > 10.0.1.1.32000: S 4195304887:4195304887(0) ack 115026016 win 4128 <mss 536>

   3: 16:43:19.623380       10.0.1.1.32000 > 10.0.2.1.80: R 115026016:115026016(0) win 0

3 packets shown

ASA1(config)#

 

As you can see, with being able to simulate and now transmit a packet to a remote destination address, we can test and verify connectivity on behalf of a particular host.  This could also assist a remote engineer with troubleshooting connectivity on other end without having to engage other groups or departments requiring their time to test the connectivity.

 

 

 

 

Join the High Availability, Inc. Mailing List

Subscribe