cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2396
Views
5
Helpful
10
Replies

ASA LDAP port forward

ddesroche1
Level 1
Level 1

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!

1 Accepted Solution

Accepted Solutions

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.

View solution in original post

10 Replies 10

cofee
Level 5
Level 5

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

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.

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!

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.

Unfortunately we're still running 8.2 and we're not using asdm.

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?

MANI .P
Level 1
Level 1

Do packet tracer from outisde to inside details with ldap.

Regards,

Mani

ddesroche1
Level 1
Level 1

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?

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?

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!

Review Cisco Networking for a $25 gift card