Jump to content
Welcome to our new Citrix community!

LDAPS from secondary: "Test LDAP Reachability" Fails

Paul Blitz

Recommended Posts

Setup: 2 x SDX, each running 4 VPX instances. They all have LDAPS configured for local management access. In all cases the LDAPS points directly to to a cascade of 3 domain controllers (so no LB involved).


- LDAPS works fine on all primary instances

- 3 of the 4 secondary instances can do LDAPS just fine

- on the other VPX secondary instance, the LDAPS login fails. Using the "Test LDAP Reachability" feature, the first step (=ping) works, but it then says that it can't reach port 636/tcp.

- if I failover the HA pair, then that VPX, now a Primary of course, works fine, and the other (now secondary) can't do LDAPS!


The NSIP's on all boxes are in the same network, and there's also a SNIP in that network.


Thinking aloud: the only reason I can think of this having an issue, is that it would be trying to use a SNIP. But why would it be using the SNIP? The other 3 instances are set up the same, and clearly they are using their NSIP for the LDAPS, because it works!


I'm thinking that it's NOT a routing issue because (a) the ping bit works; (b) it works when it's a primary. Also not a firewall issue, for same reason. Having said that, I can see that it's 


Any thoughts?

Link to comment
Share on other sites

Is it really failing the ldap communication or is the issue only with the gui test client?

We've had an issue before wehre the test utility failed but actual authentication attempts worked.


Versions, cipher or any other differences when comparing the conf files?  Clock out of sync issues on one particular appliance?

Link to comment
Share on other sites

The problem remains with the secondary, even after a failover... so the test fails and you can't log in with ldaps to the secondary, but promote it to primary, and it then works ok (and of course, the box demoted to secondary now fails!)


So that pretty well eliminates all suggestions so far.


3 other vpx pairs are working fine!

Link to comment
Share on other sites

Sorry, Paul (didn't notice it was you).


So no difference in versions

Just thinking through weird things that would affect the secondary communications in this specific of an instance.


No clock/sync issues?

No dmesg errors in boot that might indicate a bonus issue on startup?

Is there a vmac configured on this pair that might be interfering with secondary communications?

And no INC or network/firewall filter affecting one pair and not the others via a trace?


Only other random things:

Is prop/sync disabled between nodes in this pair?

Does nslog indicate some sort of network/channel issue where the switch in use isn't aware of a channel config and is muting ports or something.


Do a conf file compare against the other conf files and see if there is an unexpected feature difference in play?

Its either that or a network trace to see what is affecting this pair differently than the others.




Link to comment
Share on other sites

- Clock seems fine

- sync working great

- dmesg.boot looks clean

- no VMAC

- no INC

- sync etc all enabled and working


There's an LDAPS LB on another instance that we know works, so we're about to see if it works via that (rather than using a direct 'cascade')... if it does, then this problem 'goes away' nicely!


Link to comment
Share on other sites

  • 1 month later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...