Cloud Web Security - LDAP Source Query IP (Cisco ISR G2 Connector)

frankegns · ‎02-22-2013

Hi Cisco folks,

Goal:
I would like to implement Cisco ISR Connector with ScanSafe for the company.
I have followed the ISR Solution Guide carefully (found here:

http://www.cisco.com/en/US/docs/security/web_security/ISR_SS/ISR_ScanSafe_SolutionGuide.pdf)
So far I have managed to get a basic configuration working.

Problem:

This configuration consists of the basic Web Security features and a VPN to our internal network.
I would now like to implement authentication on the device with LDAP.
As far as I can tell the configuration is correct. (I followed the solution guide precisely)
The authentication though doesn't work.

Here an output from the debug:

*Feb 22 13:07:35.034: LDAP: LDAP: Queuing AAA request 52 for processing

*Feb 22 13:07:35.034: LDAP: Received queue event, new AAA request

*Feb 22 13:07:35.034: LDAP: LDAP authentication request

*Feb 22 13:07:35.034: LDAP: Username sanity check failed

*Feb 22 13:07:35.034: LDAP: Invalid hash index 512, nothing to remove

*Feb 22 13:07:35.038: LDAP: New LDAP request

*Feb 22 13:07:35.038: LDAP: Attempting first next available LDAP server

*Feb 22 13:07:35.038: LDAP: Got next LDAP server :scansafe-ldap-server

*Feb 22 13:07:35.038: LDAP: Free connection not available. Open a new one.

*Feb 22 13:07:35.038: LDAP: Opening ldap connection ( Internal IP of DC, 636 )ldap_open

ldap_init libldap 4.5 18-FEB-2000

open_ldap_connection

ldap_connect_to_host: Internal IP of DC
:636

*Feb 22 13:07:35.038: LDAP: socket 5 - connecting to Internal IP of DC (636)

*Feb 22 13:07:35.038: LDAP: socket 5 - connection in progress

*Feb 22 13:07:35.038: LDAP: Connection on socket 5

*Feb 22 13:07:35.038: LDAP: Connection to LDAP server (scansafe-ldap-server, Internal IP of DC) attempted

*Feb 22 13:07:35.038: LDAP: Connection state: DOWN => CONNECTING

*Feb 22 13:07:35.038: LDAP: LDAP request saved. Will be served after Root Bind is done.

*Feb 22 13:07:35.038: LDAP: LDAP request successfully processed

*Feb 22 13:08:05.038: LDAP: Received socket event

*Feb 22 13:08:05.038: LDAP: Process socket event for socket = 5

*Feb 22 13:08:05.038: LDAP: Server is not valid and non-TLS

*Feb 22 13:08:05.038: LDAP: Socket read event socket=5

*Feb 22 13:08:05.038: LDAP: Found socket ctx

*Feb 22 13:08:05.038: LDAP: ldap tcp transport closing on socket 5

*Feb 22 13:08:05.038: LDAP: Transport DOWN notification for scansafe-ldap-server/5

*Feb 22 13:08:05.038: LDAP: Clearing all ldap transactions

*Feb 22 13:08:05.038: LDAP: Triggering server failover for transit requet

*Feb 22 13:08:05.038: LDAP: Connection state: CONNECTING => DOWNldap_unbind

ldap_free_connection lc=0x8C5C14D4

ldap_free_connection: actually freed

As you can see the router can't contact our DC.
Now I did some sniffing and noticed that the router sends the LDAP query with the source address of the external interface (Public IP).
This results, that the queries are sent out into the internet with an internal destination IP. --> hence can't connect.

Question:

Now to my actual question.. How can I force the ISR to originate the LDAP queries from our internal interface ... which would then enter the VPN and connect to the DC?

Thanks in advance, and if you need any additional information, please don't hesitate to ask

Kind regards

- Sam

Jeffrey Ness · ‎02-22-2013

I recently went through this exact issue with Cisco TAC. The answers are quite unpleasant, but Cisco feels the LDAP protocol doesn't need a source-interface command because an LDAP server doesn't need a specific source IP. The "workaround" is to include your egress interface IP in the VPN tunnel so it will get encapsulated and be able to reach the LDAP server over the VPN. There is another even less desirable workaround to use a Virtual Tunnel Interface, but it is not practical for companies with more than 1 remote site or using the headend VPN concentrator for internet routing because of the requirement of the tunnel being ip any any.

frankegns · ‎02-25-2013

Hello Jeff

Thank you very much for your fast reply.
I have tried the first workaround you mentioned.

I do see an issue with the first workaround though.

As long as the VPN is up the first workaround will work just fine. The problem though will be as soon as the vpn connection dies for some reason, the VPN will not come up again until the egress IP is removed from the VPN ACL.
Hence it is not really a viable solution for a company of our size.

Thanks

-Sam