[sugarcode]

One downside of this approach (without some funky iptables/networking-fu) is that you loose the source IP from the original request. Adding headers like X-Forwarded-For only works after the request has been decrypted, so all the traffic will appear to source from the load balancer, which can present its own issues.

IMO (and I believe Google agrees - http://www.imperialviolet.org/2010/06/25/overclocking-ssl.ht...) the advantages of terminating SSL at the load balancer outweigh the horizontal scalability of this approach, at least in most cases.

[X-Istence]

Transparent load balancers exist and don't have the issues you are talking about.

[sugarcode]

Hardware or software? There's some hacks with TPROXY/HAproxy I've seen that would do the transparent proxy but the setup seems like more trouble than it's worth.

[ominous_prime]

IPVS is built-in to the Linux kernel, and HA projects like keepalived have ipvsadm integration. Tproxy works fine, and has been in the kernel since 2.6.30. In most load-balancing cases, losing the remote IP address isn't that big a deal (you have to deal with NAT too), and a full proxy like haproxy has it's benefits.

[X-Istence]

OpenBSD PF for example can do round-robin load balancing.