12-23-2016 09:42 AM - edited 03-12-2019 01:42 AM
Hi there,
I've been trying to allow an outside application to pass LDAP(s) traffic to a server on our network. We have an ASA 5520 running 8.2. The first step I took was creating an ACL for the desired IPs:
access-list outside_access_in extended permit tcp host Address_1 host AD_Sync_Server-10.1.1.1 eq ldaps
access-list outside_access_in extended permit tcp host Address_2 host AD_Sync_Server-10.1.1.1 eq ldap
From there I thought all I needed to do was create the NAT:
static (Inside,Outside) PublicIP 10.1.1.1 netmask 255.255.255.255
After making that entry, our server was not able to access anything outside the network. So I tried
static (Inside,Outside) tcp PublicIP 636 10.1.1.1 636
This entry didn't cause loss of external access, but when I had the vendor test the connection, they still were still not able to connect on the ports.
What am I missing here? I still have a lot to learn in the world of Cisco, so I may be way off or just missing something simple. Any advice would be appreciated!
Solved! Go to Solution.
12-23-2016 03:13 PM
Yes, pre 8.3 version of the ASA, public IP address of the static NAT is used in Outside ACL. From 8.3 onwards, you can use the private (10.1.1.1 in this case) in the ACL.
Another good way to figure out what is blocking the traffic is to run a packet-tracer for sample traffic from outside to inside. In your scenario, it would be something like:
packet-tracer input outside tcp Address_1 12345 PublicIP 636 detailed
Hope this helps.
12-23-2016 01:34 PM
After creating static NAT for your internal server did you replace internal address with the public address in the ACL? the ACL you posted it appears to be using internal address.
access-list outside_access_in extended permit tcp host Address_1 host AD_Sync_Server-10.1.1.1 eq ldaps
12-23-2016 03:13 PM
Yes, pre 8.3 version of the ASA, public IP address of the static NAT is used in Outside ACL. From 8.3 onwards, you can use the private (10.1.1.1 in this case) in the ACL.
Another good way to figure out what is blocking the traffic is to run a packet-tracer for sample traffic from outside to inside. In your scenario, it would be something like:
packet-tracer input outside tcp Address_1 12345 PublicIP 636 detailed
Hope this helps.
12-27-2016 04:52 AM
Thank you all for the replies. I went ahead and changed the NAT to use the public address. I then ran packet tracer. I'm not completely familiar with it, but all phases showed up with ALLOW as a result, I can only assume that's a good start? Then if I'm not mistaken I went to look for untranslate-hits which represent outside address coming in? In which case I do show a hit there as well.
I'll be holding actual testing later today with the vendor needing to access this server, I'll return with results. Again, I appreciate the help!
12-27-2016 10:22 AM
Please refer to the below mentioned url with the complete information about the subject.
https://supportforums.cisco.com/video/11929221/asa-enabling-port-forwarding-asdm-versions-83-and-84
Video Link for Enabling port forwarding via ASDM (versions 8.3 and 8.4)
https://supportforums.cisco.com/document/132066/asa-nat-83-nat-operation-and-configuration-format-cli
Let me know if it help.
12-27-2016 10:56 AM
Unfortunately we're still running 8.2 and we're not using asdm.
12-27-2016 08:31 AM
The vendor responded to my request to test the connection again, and they are still not able to connect to our server. The packet tracer shows traffic being Allowed all the way though. Have any ideas what I could still be missing?
12-23-2016 05:16 PM
Do packet tracer from outisde to inside details with ldap.
Regards,
Mani
12-28-2016 11:25 AM
So the issue I'm running to now, is after I add the NAT entry, I lose internet access on the server in which it corresponds to. Am I missing something in the ACL?
12-29-2016 04:48 AM
Can you run the same packet-tracer from inside to outside with source as your server and destination as an internet ip (eg 4.2.2.2) and see then results?
Also, could you past the relevant nat statements here so that we can confirm that the config is correct?
12-29-2016 05:06 AM
I have since resolved the issue. Turns out they had me working with false information. They had me using a public address that wasn't in our allocated block. But, thanks to you guys, as soon as I used the correct IP everything worked perfectly!
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