Solved: ASA 5512 (Flow is Denied by Configured Rule)

bhodgson · ‎12-26-2013

Hello all,

New to the forums and the relatively new to Cisco ASA 5512. Particularly utiilizing the ASDM gui config.

I'm trying to setup the ASA to allow LDAP sync for a new SPAM/AV Email security service and running into an issue that I'm sure is a simple oversight. In production, using an our old firewall (sonicwall) all works well, but I'm testing through the ASA5512 in hopes to move this over soon.

Here's the message I receive when using packet tracer:

For clarity, here are the NAT Rules currently created:

And here's the message I receive in the Syslog when initiating a test connection for the LDAP sync:

Many thanks in advance...

-BH

Jouni Forss · ‎12-27-2013

Hi,

The "packet-tracer" test seems to indicate that the test is DROPed because the packet initially matches NO NAT configuration on the firewall but the reverse (RPF) check fails because it matches a NAT configuration.

It would seem to me that since your source address is a public IP address that you are probably attempting to simulate a connection coming from the public network, therefore the destination IP address should be a public NAT/PAT IP address configured on the ASA and not the actual private IP address of the destination host.

So the reason for the "packet-tracer" fail might be that you are using the private IP address as the destination but if the actual connection is not working then there might be other problems too.

I would suggest running the "packet-tracer" through the CLI of the firewall with the command

packet-tracer input tw tcp 12345

You can do this through the ASDM also from Tools -> Command Line Interface

There is either confusion about the actual destination IP address to connect to or perhaps some NAT/ACL configuration problem. For me personally troubleshooting would be easier looking at the CLI format of the ASA configuration.

Hope this helps

- Jouni

View solution in original post

Jouni Forss · ‎12-27-2013

Hi,

The "packet-tracer" test seems to indicate that the test is DROPed because the packet initially matches NO NAT configuration on the firewall but the reverse (RPF) check fails because it matches a NAT configuration.

It would seem to me that since your source address is a public IP address that you are probably attempting to simulate a connection coming from the public network, therefore the destination IP address should be a public NAT/PAT IP address configured on the ASA and not the actual private IP address of the destination host.

So the reason for the "packet-tracer" fail might be that you are using the private IP address as the destination but if the actual connection is not working then there might be other problems too.

I would suggest running the "packet-tracer" through the CLI of the firewall with the command

packet-tracer input tw tcp 12345

You can do this through the ASDM also from Tools -> Command Line Interface

There is either confusion about the actual destination IP address to connect to or perhaps some NAT/ACL configuration problem. For me personally troubleshooting would be easier looking at the CLI format of the ASA configuration.

Hope this helps

- Jouni

bhodgson · ‎12-28-2013

@Jouni

Thanks!

Using the packet tracer with the external still failed, but it helped uncover a simple oversight in the NAT/ACL configuration. Also, thanks for the push to use cli for packet-tracer. Our contract stipulates that configuration changes should be done via ASDM, but allows for use of CLI in limited scenarios. This did the trick.

Thanks again, have a happy new year!

-BH