-1

Context

debian 64bits.

I try to learn https. I created a loadbalancer but I cannot answer tthe client directly from the backend since it receive the LB ip.

Question

I would like to know how I could achieve the following with ssl connection:

client -------> loadbalancer Level4 -----> 3 backends (ssl termination) -----> Back to client

The goal is to avoid decrypting on the loadbalancer but still be able to send the requests to each of the backend servers, decrypt there and send back to client directly.

Any way to make it happen ? I am learning and it is difficult to follow all the things happening in haproxy or tinyproxy. I need a visual help.

Improve this question
7
  • Why on earth would you want to do this? – ceejayoz Aug 26 '14 at 17:35
  • My loadbalancer is not on the same network as my backends and I cannot change it. I would have avoided the cpu hassle to offload at the loadbalancer and reencrypt toward the backends :( Please don't downvote me, I am learning – Larry Aug 26 '14 at 17:40
  • SSL encryption is pretty minimal on current hardware. Your proposed solution (which I'm not sure is even possible given how TCP works) would if nothing else entail so much complication as to obliterate any benefit you gain from it. – ceejayoz Aug 26 '14 at 17:41
  • Understood. Now the problem is the ability to pass the client's source port to be able to answer him (browser). X-forwarded-for is only for ip – Larry Aug 26 '14 at 17:51
  • The client's source port will be 443, it's HTTPS. What on earth are you doing? If HAProxy is this complicated, you're doing something odd. – ceejayoz Aug 26 '14 at 17:52
1

What you are asking for is called Direct Server Return. It is a feature available on some load balancers, but not all. I have not found any definitive answer as to whether HAProxy or tinyproxy supports DSR.

A couple of significant advantages of DSR are:

  • You can do SSL on backends behind the LB and still know the IP of the client
  • You can get better scalability because the LB only need to handle packets in one direction (usually the one with the least traffic).

A disadvantage of DSR is that you can no longer rely on standard IP routing for packets from the LB to the backend. This is due to the packets still having the VIP as destination address, and thus IP routing would route them to the LB.

Two approaches to get around this are the following:

  • The LB bypass the ARP/ND layer when incoming packets are forwarded. Instead the LB fill in the destination MAC with the MAC of the selected backend. This approach only works if LB and backend are on the same segment.
  • Use an IP tunnel between LB and backend. This approach works even if there is a router between LB and backend. When using this approach, one must take care to avoid MTU issues. Reducing MSS can avoid MTU issues, but the LB cannot do that due to DSR, so the backend need to be configured with lower MSS.
Improve this answer
1
  • Some weeks later, I implemented a firewall routing and display publicly my backends ips to take the next load. The loadbalancer is touched once. Thanks kasperd – Larry Oct 13 '14 at 17:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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