Using Packet Tracer to Verify Which Packets Are Allowed

Now that the firewall with interfaces has been configured and a default route has been set up and is providing NAT for the benefit of our clients, we should probably make sure that the rules that we have configured, including NAT, are performing as we want. Being able to troubleshoot a problem before it even occurs is a wonderful thing. ASA has a built-in tool called Packet Tracer that enables you to identify whether the ASA will forward or drop a packet, before the user even powers on her computer. Packet Tracer even indicates the reason why a packet would be dropped by the ASA.

You can launch Packet Tracer from the Tools menu, and there is an icon for Packet Tracer located on many of the configuration windows as well, including the Access Rules window shown previously in Figure 16-17. Also note that Cisco Academy has a simulator program called Packet Tracer; this is not the same tool as the Packet Tracer tool integrated into the ASAs.

After launching Packet Tracer from either the Tools menu or from an icon in the current window, you are presented with a dialog box in which you enter the specific traffic flow that you want to test or verify. Because we just placed an ACL on the inside interface that should permit everything except for Telnet traffic, we can test to see whether web traffic will be forwarded from our inside users as they make requests to web servers out on the Internet. To simulate this, we enter the source IP and port information and destination port and IP address and the interface and packet type that the packet will be using as it leaves the user and enters the firewall. Figure 16-18 shows the input for this test.

Figure 16-18 Configuring Input for the Packet Tracer Test

The literal IP of the source and destination do not have to be valid hosts, as the ASA is only determining, from it is current configuration, whether the firewall would allow the packet. In Figure 16-18, we use a random source port, higher than 1023, and the destination well-known TCP port of 80. The IP addresses represent a device from the inside and a server on the outside (based on the default route on the ASA). Also in the Packet Tracer, we identified that the traffic is entering the ASA on the inside interface. When we click Start, ASDM sends the commands to the ASA to simulate this packet.

The output in the GUI shows the final result of the packet being either allowed or denied, along with each of the individual checks that the ASA did along the way (each of which can be expanded), as shown in Figure 16-19.

Figure 16-19 Packet Tracer Results Screen

From the output, we can see that the ASA performed several checks, and ultimately would have allowed this packet through the firewall. If there was any issue with ACLs, interfaces that are down, Modular Policy Framework, or any other policies or issues that would cause this ASA not to forward the packet, the result would show as a deny, including which part of the processing on the ASA caused the packet to be denied.

Behind the scenes, the ASA is really processing a CLI command and feeding the information back to ASDM. Example 16-9 shows the actual CLI for this command.

Example 16-9 Using the Packet Tracer Utility at the CLI

Click here to view code image

! Checks to see if a packet, inbound on the inside interface,
! that is coming from host 10.0.0.101 and going to 22.33.44.55, and is
! TCP based and from port 1065 going to 80, and tell us if it would make
! it through the firewall
ASA1# packet-tracer input inside tcp 10.0.0.101 1065 22.33.44.55 80

! ! Here are the results of each of the tests it internally checks (based on
! the current, configured and default rules in place)
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   0.0.0.0         0.0.0.0         outside

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inside_access_in in interface inside
access-list inside_access_in extended permit ip any any
Additional Information:

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

Phase: 4
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside,outside) source dynamic Inside_Hosts interface
Additional Information:
Dynamic translate 10.0.0.101/1065 to 23.1.2.3/5069

Phase: 5
Type: HOST-LIMIT
Subtype:
Result: ALLOW
Config:
Additional Information:

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

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

So, from this, we can safely say that the firewall will allow a host on the inside to initiate an HTTP session with a web server on the outside.