RE: Forwarding SSL connections - forwardfor information is missing

Not ideal for scalability, but you could use round-robbin dns for the ssl tunnels that then connect to the load balancer via http. Depending on the app, you are likely to need far more app servers than ssl servers.

> -----Original Message-----
> From: Jan Miczaika [mailto:jan#hitflip.de]
> Sent: Thursday, November 01, 2007 5:40 AM
> To: Willy Tarreau
> Cc: haproxy#formilux.org
> Subject: Re: Forwarding SSL connections - forwardfor information is
missing
>
> Hi Willy,
>
> thanks for your feedback. Terminating the SSL connection on the load
> balancer puts all of the SSL decoding work on the load balancer.
This
> can take up CPU time very quickly. And since only one SSL
termination
> point can be running at any time, we can't scale it linearly by
adding
> pizza boxes. As you described, distributing the work doesn't work.
>
> It seems like we're stuck between a rock, a hard place, and a
dedicated
> SSL decrypter ;-)
>
> Best regards
>
> Jan
>
>
>
>
> Willy Tarreau wrote:
> > Hello Jan,
> >
> > On Fri, Oct 26, 2007 at 01:32:05PM +0200, Jan Miczaika wrote:
> >
> >> Hello,
> >>
> >> we would like to load balance our https connections as well,
using
> >> haproxy. The connections end up on a number of pound servers.
They
> >> decrypt the SSL traffic and send it on to the apaches.
> >>
> >> We are able to forward the https connections using tcp mode,
however we
> >> lose the "forwardfor" information. This is very important for us
on
> >> https connections, as these are purchases and we need to save the
IP
> >> address for fraud detection and prevention.
> >>
> >
> > Yes, it's a very common problem.
> >
> >
> >> Forwarding the https connections using http mode does not work,
obviously.
> >>
> >> What we would really like to do is:
> >>
> >> listen sslourpage.de:443 213.xxx.xxx.xxx147:443
> >> mode tcp
> >> -> forwardfor
> >> option ssl-hello-chk
> >> balance roundrobin
> >> server www1 192.168.xxx.xxx:443 maxconn 500 check
> >> server www2 192.168.xxx.xxx:443 maxconn 500 check
> >> server www3 192.168.xxx.xxx:443 maxconn 500 check
> >> server www4 192.168.xxx.xxx:443 maxconn 500 check
> >>
> >> As far as I know this option is not supported? The alternative
would be
> >> to not use haproxy and set up a LVS cluster, with requests coming
in to
> >> pound. But haproxy is so much easier and simpler. I would love to
see a
> >> solution. Currently we are using haproxy 1.2.16.
> >>
> >
> > It's not a matter of "option not supported", but a conceptual
problem.
> > What you're trying to do is configure a TCP proxy which is
installed in
> > the middle of an SSL connection so that it will insert data inside
the
> > protected and ciphered stream.
> >
> > The only way to achieve this is to terminate the SSL connection on
your
> > load balancer, and make the SSL proxy add the header itself. Since
haproxy
> > does not yet support SSL, you have to do that outside of it. I
think you
> > can do this with Pound, I know you can do it with apache, but I'm
only used
> > to do this with stunnel (for which I have a patch on my site). In
all cases,
> > the principle is the same: you install your server's certificates
on the
> > SSL end on your load balancer (pound/stunnel/apache), and that one
transforms
> > HTTPS into HTTP sent to haproxy working in HTTP mode. It also adds
the
> > X-Forwarded-For header so after that, you're fine.
> >
> > Take a look at the architecture manual, there are examples of such
a setup.
> >
> > Regards,
> > Willy
> >
> >
> >
>
> --
> Geschäftsführer / Managing Director
> Hitflip Media Trading GmbH
> Gürzenichstr. 7, 50667 Köln
> http://www.hitflip.de - new: http://www.hitflip.co.uk
> Private blog: www.managingtech.de
>
> Tel. +49-(0)221-272407-27
> Fax. 0221-272407-22 (that's so 1990s)
> HRB 59046, Amtsgericht Köln
>
> Geschäftsführer: Andre Alpar, Jan Miczaika, Gerald Schönbucher
>
Received on 2007/11/01 12:58