ASA VPN Auth to LDAP over tunnel

[cistera.com]

We use LDAP for auth and it has been working fine for years.  I moved our LDAP server to be across a tunnel between 2 cisco applicances (pix/asa), and everything can talk to the LDAP server *except* the device originating the tunnel.  I am trying to use LDAP over the tunnel for the pix.  Packet tracer shows it being dropped by the ACL, yet the ACL above it has allow for the inside IP of the pix.

Is there a way to add the *interface* to allow?  I cannot see how to do it.

Thanks!

[kaaftab]

kindly share you topology and config.

[cistera.com]

Sure - topology is:

Site A - Pix 515e

Routable IP - 8.8.8.8/32

Inside IPs 192.168.0.0/16

Site B - Asa5505

Routable IP - 9.9.9.9/32

Inside IPs - 192.168.5.0/24

DMZ IPs - 192.168.7.0/24

Site B contains the LDAP server on 192.168.7.16

from the pix console:

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.7.16, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 20/28/30 ms

Yet the ldap test always fails even though I know LDAP is running on the host and I can auth against it from hosts behind the pix.  A packet capture from the LDAP hosts shows no packets ever getting to the host either. 

Machines at Site A have no problem communicating with 192.168.{5,7}.0/24

ONLY the Pix at Site A cannot communicate with it for it's server group's LDAP auth.  The LDAP server was local to the Pix @ siteA and it has been working flawless, but I guess the version on it is not smart enough to use the tunnel (or I do not know how to make it use the tunnel for an LDAP server group entry.  It only lets me specify a physical interface.

I have read others with the same issue and no resolve except to upgrade, but that is not really an option at this point.  I was hoping someone knew some *magic* to make it work with 8.0.4 (the latest our pix will support)

Thanks!

[Javier Portuguez]

Please share the version of the PIX and the AAA server configuration.

[cistera.com]

Cisco PIX Security Appliance Software Version 8.0(4)

Hardware:   PIX-515E, 256 MB RAM, CPU Pentium II 433 MHz

Flash E28F128J3 @ 0xfff00000, 16MB

BIOS Flash AM29F400B @ 0xfffd8000, 32KB

aaa-server Cistera_LDAP (inside) host 192.168.7.16

timeout 3

ldap-base-dn o=Corporate,dc=cistera,dc=com

ldap-scope subtree

ldap-naming-attribute uid

ldap-login-password *

ldap-login-dn cn=Bind User,dc=cistera,dc=com

server-type openldap

Keep in mind - 192.168.7.16 is across a tunnel that is terminated on the same PIX.  All devices inside the pix can use that server (and I can ping that server from the PIX), but the PIX will not authenticate to it for VPN users any longer (only the IP changed).  I have tried setting both inside and outside interfaces as the source.

Thanks!

[Javier Portuguez]

Please correct:

aaa-server Cistera_LDAP (outside) host 192.168.7.16

Make sure you include the outside interface of the PIX to the tunnel and make the same changes + NAT adjustments on the remote ASA.

Thanks,

[cistera.com]

Befor I make these changes, I want to make sure I understand you.  You want me to include the interfaces ip addresses that the tunnels terminate on to be *inside* the tunnel on each side?  I can currently ping the ldap server from the pix, but the pix cannot auth to it.

That seems a bit convoluted to me, but if it works and does not affect regular traffic on the outside interfaces I will try it.

Thanks again.

[Javier Portuguez]

Ealier versions of the ASA can manage the server pointing to the inside but still route it to the outside an eventually through the tunnel.

The problem is that your PIX version is too old and it does not support such functionality. So, you will need to point to the outside and also include the outside IP address of the PIX to the VPN tunnel.

access-list crypto permit ip interface outside host remote_ldap_server

The same ACE should be included to the remote site in addition to the NAT exemption rule (if applicable).

Keep me posted.

[cistera.com]

Yes, so like I thought it might, adding both external IP addresses /32 into the respective tunnel maps fopr protected networks, and putting them into the exempt nat rules killed traffic flow between the sites.

Any other ideas?

Thanks again.

[Javier Portuguez]

Good Morning,

"killed traffic flow between the sites..."

Could you please be more specific?

Is the tunnel up or down?

Is phase II up? Do you see the SA active?

Thanks

[cistera.com]

So, I should have been more clear.  The interfaces themselves became unreachable.  IE, I could not manage to the inside interface of one site from inside the other site, etc.

I'll revisit this over the weekend, and if I cannot figure it out, I will send more detailed info.  Sorry - I have just not had time to properly present it to you.

Thanks,

[Javier Portuguez]

Thats absolutely fine, I totally understand.

Have a great weekend!

[cistera.com]

Just so the forums have a correct answer in case someone else runs into it, it was due to the fact that the ASA side had ikev1 and ikev2 enabled, and it was hitting the 120 second timeout trying to bring up the ikev2 tunnel map before it would allow traffic to pass in ikev1.

[Javier Portuguez]

Very well! Thanks.