12-26-2013 02:00 PM - edited 03-11-2019 08:22 PM
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
Solved! Go to Solution.
12-27-2013 01:21 PM
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
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
12-27-2013 01:21 PM
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
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
12-28-2013 04:54 AM
@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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide