Category: ASDM

You might get an argument from Cisco that this one is a bug, but it sure is annoying:

On an ASA you can apply firewall rules in two places (in ASA 8.3 and above). Rules can be applied on an interface or globally. When applied on an interface they can operate on traffic entering the interface (incoming rules) or on traffic egressing the interface (outgoing rules).

When using ASDM to create a new rule, you can right-click on a rule and select Insert After to add a new rule after the existing right-clicked rule. When you do that you are presented with a dialog box allowing you enter the required details:

The dialog box presented allows the common details to be entered with an option to expand the dialog to include further options if needed. Selecting More Option reveals the following additional fields:

The second additional option allows the traffic direction to be set. In this example, the direction is set to In – that is the rule is an Incoming rule.

Unfortunately, the Traffic Direction is set to ‘In’ even if you are inserting a rule after an outgoing rule. If you don’t notice this, and with the unexpanded dialog box why should you, the rule is added in the wrong place and will not work as expected.

We have a number of Cisco ASA devices and on one high availability pair we run OSPF. We do this to allow us to exchange routes with our MPLS provider. When we first set this up we made use of ASDM to display the external routes in the OSPF database – that is type 5 LSAs. This was useful to verify that the expected routes were being redistributed to us from the providers BGP.

Unfortunately the display only listed a few LSAs with the majority missing. After some time chasing our tails to try to resolve the problem, we used the CLI to display the OSPF database and were surprised, but happy, to see all the external routes we had expected.

After some investigating we discovered that the list displayed by ASDM was being truncated at the first LSA with an address that matched an ASA object name. We reported this problem to Cisco and they accepted it as a bug (CSCtq48552 if you are interested).

Well, over a year later it still has not been fixed. I guess the moral from the story is: if in doubt use the CLI and having a bug accepted by Cisco does not mean it will ever get fixed.