×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

ASA 5512 (Flow is Denied by Configured Rule)

Answered Question

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:

FlowDenied.png

For clarity, here are the NAT Rules currently created:

NatRules.png

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

syslog.png

Many thanks in advance...


-BH

Correct Answer by Jouni Forss about 3 years 7 months ago

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Correct Answer
Jouni Forss Fri, 12/27/2013 - 13:21
User Badges:
  • Super Bronze, 10000 points or more

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

@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

Actions

This Discussion