The purpose of a firewall is to block network traffic, and then allow limited, controlled, and specific traffic through. For someone who isn’t doing this every day, it can sometimes be a frustrating challenge figuring out why the firewall isn’t performing as expected when security rules are changed, added, or removed. Using Cisco’s ASDM GUI configuration tool can be helpful in figuring out why the ASA isn’t “working”.
Often looking at the configuration directly via the command line is the best way to find problems. However, the ASDM tool provides ways of displaying the text configuration as well. Additionally, other common troubleshooting tools are also included in ASDM and we will review them in this blog.
The first step in troubleshooting is determining if the ASA can connect to the both ends of the connection that is being allowed through. Often it is an outside system connecting to a dmz system on a specific port, or maybe a dmz system connecting through to an inside system. For this to have any chance of working the firewall must have connectivity to both systems. If we have a simple network as in:
We can test basic connectivity in ASDM using the Ping function from the Tools menu:
We should make sure we can ping both hosts:
This is the outside system
This is the inside system
If you are seeing “?????” rather than “!!!!!” there is a problem with the basic connectivity. Make sure the switches and routers if any are setup correctly. Also, confirm both the firewall and the host can ping other devices on the same subnet.
Once the firewall can ping both devices any further issues are often, but not always, related to the firewall.
The second step in troubleshooting is more dependent on what the Cisco ASA firewall is configured to accomplish. We will look at port forwarding issues. As with connectivity, a good first step is confirming the port being forwarded is locally accessible. For example, forwarding port 443 to a web server that isn’t running, isn’t going to work. A good initial test would be to see if another inside (or in the case of a webserver it would be better in a dmz) system can open a web page. If you have Linux based systems available, another way to test is using netcat.
In our example, on the server you could run:
nc -l 443
and a test client could run
nc 172.23.182.101 443
this will allow text to be passed between the systems.
After it is confirmed the server is working as intended, the ASDM tool to use is the Packet Tracer also available from the Tools menu.
We also recommend unchecking the “Show animation” box as it will speed up the use of the packet tracer.
VPN troubleshooting is often more complex, difficult and frustrating. First, confirm the tunnel is up. You can look for tunnels in ASDM by clicking Monitoring at the top, and then VPN on the bottom right:
If the tunnel isn’t coming up, confirm connectivity between the endpoints with the instructions above, you can access the Ping tool directly from the Monitoring window. Also, confirm ALL of the encryption parameters are correct.
If the tunnel is up, but traffic isn’t passing through the VPN, confirm on any inside devices the routes are properly set to direct the traffic through the Cisco ASA firewall. Next, use the Packet Tracer to confirm traffic is configured to pass through the tunnel.
Should the Packet Tracer not allow the packet, look carefully at where the packet is dropped, and confirm the rules are correct.
In the NAT rules, make sure the VPN rules are before the default rule sending traffic to the Internet.
Troubleshooting often requires looking at the firewall configuration directly, and then making changes to it. This is also supported with ASDM. To look at the running configuration, from the File menu select Show Running Configuration in New Window.
This will open the configuration in your default web browser. Refreshing the page shows the current running configuration.
There is also a Command Line Interface in the Tools menu. You can send single or multiple lines at a time, and then see the results in your web browser after refreshing the screen. This is often easier than trying to use an 80x25 character terminal window.
While troubleshooting is never fun, most firewall changes don’t work perfectly on the first attempt and some of the tools presented here can be helpful in figuring out what went wrong.
Should further assistance be required, an iuvo Technologies network engineer would be happy to assist.