Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I use a ldirectord setup for load balancing a couple of real servers and for the HTTPS conenctions I am considering using some offloading mechanism on the LB - is there some functionality already implemented in the ldirectord, or should I look for another solutions that I will have to pair with ldirectord?

Thanks in advance!

share|improve this question
up vote 0 down vote accepted

I should start by saying that I haven't configured LVS for a couple of years, now, and it may have moved on.

That said, when I last did it was very much software that worked at layer 3, not layer 4. If you wanted something that would redirect your incoming TCP/443 connections to one of a pool of back-end servers, LVS was your man. If you wanted something to receive incoming HTTPS connections, decrypt them, and farm the decrypted requests out to a pool of back-end servers, it wasn't your man.

Edit: yes, I'd consider using apache to do the decrypt and redirect-to-the-pool. Furthermore, you could use Linux-HA to control two front-end apache boxes (one live, one hot standby), so that the redirector was still always-up, on an IP address that floated between the two under HA's control.

share|improve this answer
Thanks for the quick answer! :) So, I guess I should consider something like an Apache server or Squid proxy infront of / behind the Load Balancer, so that they can work with the SSL encrypt / decrypt. – Konstantin Boyanov Apr 12 '13 at 7:29

when using lvs with ssl, set the certificates on the ssl service servers (ldap in my case) to match the load-balancer VIP, not the hosting server DNS names. This means that when you hit the lvs server VIP:ssl port, the cert negotiation matchs the reverse dns name that is expected by the initiating server.

Testing ssl handshake -> openssl s_client -connect hostname:port

the problem isnt the config. A standard lvs config works fine. The problem is the the ssl certificate negotiation. The "client" expects a certifcate that matches the reverse dns for the IP it is connecting to. (ie the load balancer virtual IP interface IP). If the host farm responder responds with "its" certificate, it will look like a spoofed cert because it wont match the connection IP. Therefore the "fix" is to load all the farm responders with the LB virt IP certificate instead


share|improve this answer
I find this answer a bit unclear. Maybe it can be improved with an example of what the suggested configuration would look like. – kasperd Nov 27 '14 at 1:22
btw, I tried to sign up, but your site requires me to use a password I cant memorise, namely upper+lower+digits+nonalpha. Totally ignoring human factors. The pont of letting people choose their own password is making it something they can remember easily. – Andrew Nov 28 '14 at 4:20
Who are you expecting to read that comment? – kasperd Nov 28 '14 at 7:20

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.