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

We're building a load balanced setup with two load balancers (that also terminate SSL) and several upstream servers. Both the load balancers and the upstream servers run nginx. The network on which requests are forwarded to the upstream servers cannot be trusted, hence we have to re-encrypt it after SSL termination on the load balancer. We're wondering which route we should take for re-encrypting the connection:

  • SSL: the load balancer connects to an upstream server using SSL.
    • positive: fairly resilient, since every connection is established from the ground up
    • negative: added latency from the SSL handshake
  • persistent SSH tunnel
    • positive: no (or less?) added latency
    • negative: tunnel may break down and has to be monitored with e.g. autossh

Additionally, I'm not sure how both solutions compare in throughput. Does anybody have some experience with one or both of these solutions? Or are there better approaches?

share|improve this question
Why not just terminate SSL at the upstream servers, then? – Michael Hampton Mar 25 '13 at 15:09
Have you considered a VPN? – Christopher Perrin Mar 25 '13 at 15:27

Nice question and also in my interest.

I would vote for a persistent SSL tunnel with monitoring or VPN, as said. Encryption then needs to be done once and for all traffic. As it's a load balancer you should be able to easily timeout on failing encryption link.

Have you already implemented something?

share|improve this answer

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.