SSL Backends
Hi, it might be a stupid question but how is it possible (if at all) to balance incomming traffic with cookie based session stickyness to a set of webservers which terminate ssl. If i understand the documentation correct, ssl backends are only possible in tcp mode, not http and then haproxy is not able to maintain the session cookie. My actual configuration looks like: client (browser) -- https - nginx http haproxy -- http -- multiple servers example config: listen server1 bind 127.0.0.1:6003 timeout connect 5000ms timeout client 5000ms timeout server 5000ms option httpchk HEAD /check HTTP/1.0 balance roundrobin cookie SERVERID insert indirect maxidle 3600s server backendserver-1 172.20.225.16:8080 cookie i-abcdef check inter 3000s server backendserver-2 172.20.225.32:8080 cookie i-cdefgh check inter 3000s So how can i talk to backendserver-1 and backendserver-2 with https and still have the session persistence. BTW. This configuration is just a part of a much larger one which is working perfectly well in a quiet descent load. So thanks a lot for this piece of great software willy ! Any ideas ? Greetings -- Stefan Majer
Re: SSL Backends
Assuming your ssl terminator (in this case I presume it's nginx) is on the same box as haproxy, haproxy basically is getting unencrypted content. I've not used nginx to do ssl termination but stunnel supports the proxy protocol and passes all of the once encrypted cookie information to haproxy to delegate to your backends properly. On Monday, July 16, 2012 at 11:31 AM, Stefan Majer wrote: Hi, it might be a stupid question but how is it possible (if at all) to balance incomming traffic with cookie based session stickyness to a set of webservers which terminate ssl. If i understand the documentation correct, ssl backends are only possible in tcp mode, not http and then haproxy is not able to maintain the session cookie. My actual configuration looks like: client (browser) -- https - nginx http haproxy -- http -- multiple servers example config: listen server1 bind 127.0.0.1:6003 timeout connect 5000ms timeout client 5000ms timeout server 5000ms option httpchk HEAD /check HTTP/1.0 balance roundrobin cookie SERVERID insert indirect maxidle 3600s server backendserver-1 172.20.225.16:8080 cookie i-abcdef check inter 3000s server backendserver-2 172.20.225.32:8080 cookie i-cdefgh check inter 3000s So how can i talk to backendserver-1 and backendserver-2 with https and still have the session persistence. BTW. This configuration is just a part of a much larger one which is working perfectly well in a quiet descent load. So thanks a lot for this piece of great software willy ! Any ideas ? Greetings -- Stefan Majer
Re: SSL Backends
You'd have to delegate back out to stunnel/nginx again which would delegate to your backends. On Monday, July 16, 2012 at 11:40 AM, Stefan Majer wrote: Hi, sure, but i want to talk to the backends encrypted again. So that my last line in the drawing is ssl. nginx and haproxy live on the same box, but the backends dont. They are on a totally different network and some people argue that traffic crosses some routers unencrypted. So to be more clear: haproxy gets unencrypted traffic and should encrypt it again. Greetings Stefan On Mon, Jul 16, 2012 at 6:36 PM, Chris LeBlanc ch...@blendedby.us (mailto:ch...@blendedby.us) wrote: Assuming your ssl terminator (in this case I presume it's nginx) is on the same box as haproxy, haproxy basically is getting unencrypted content. I've not used nginx to do ssl termination but stunnel supports the proxy protocol and passes all of the once encrypted cookie information to haproxy to delegate to your backends properly. On Monday, July 16, 2012 at 11:31 AM, Stefan Majer wrote: Hi, it might be a stupid question but how is it possible (if at all) to balance incomming traffic with cookie based session stickyness to a set of webservers which terminate ssl. If i understand the documentation correct, ssl backends are only possible in tcp mode, not http and then haproxy is not able to maintain the session cookie. My actual configuration looks like: client (browser) -- https - nginx http haproxy -- http -- multiple servers example config: listen server1 bind 127.0.0.1:6003 timeout connect 5000ms timeout client 5000ms timeout server 5000ms option httpchk HEAD /check HTTP/1.0 balance roundrobin cookie SERVERID insert indirect maxidle 3600s server backendserver-1 172.20.225.16:8080 cookie i-abcdef check inter 3000s server backendserver-2 172.20.225.32:8080 cookie i-cdefgh check inter 3000s So how can i talk to backendserver-1 and backendserver-2 with https and still have the session persistence. BTW. This configuration is just a part of a much larger one which is working perfectly well in a quiet descent load. So thanks a lot for this piece of great software willy ! Any ideas ? Greetings -- Stefan Majer -- Stefan Majer
Re: SSL Backends
Hi, I agree with Chris. It's a common setup: client == stunnel == haproxy == stunnel == server First stunnel runs in server mode while second one runs in client more. that way, HAProxy sees traffic in clear but the connection from the client and to the server are encrypted. cheers
IPv6 ACLs for 1.4.x
Hi guys, I saw that 1.5.x will have IPv6 ACL support. Would it be possible to backport it to 1.4.x? :) I haven't looked at the patch yet though so I don't know how much work it may be. -- Regards, Christian Ruppert pgpScmPJYmYHN.pgp Description: PGP signature
Re: SSL Backends
IMHO if you run your servers in a trusted network, **haproxy == stunnel == server** part adds a lot of overhead we do client == stunnel == haproxy == server[0..N] also, take a look to stud [1] vs stunnel. I would recommend you also to check the PROXY protocol which helps with all the XFF, client ip address issue... saludos [1] https://github.com/bumptech/stud On Mon, Jul 16, 2012 at 4:13 PM, Baptiste bed...@gmail.com wrote: Hi, I agree with Chris. It's a common setup: client == stunnel == haproxy == stunnel == server First stunnel runs in server mode while second one runs in client more. that way, HAProxy sees traffic in clear but the connection from the client and to the server are encrypted. cheers -- Gabriel Sosa Si buscas resultados distintos, no hagas siempre lo mismo. - Einstein
Re: SSL Backends
I concur, We don't worry about encrypting traffic that is sent from haproxy to the backends. On Monday, July 16, 2012 at 3:39 PM, Gabriel Sosa wrote: IMHO if you run your servers in a trusted network, **haproxy == stunnel == server** part adds a lot of overhead we do client == stunnel == haproxy == server[0..N] also, take a look to stud [1] vs stunnel. I would recommend you also to check the PROXY protocol which helps with all the XFF, client ip address issue... saludos [1] https://github.com/bumptech/stud On Mon, Jul 16, 2012 at 4:13 PM, Baptiste bed...@gmail.com (mailto:bed...@gmail.com) wrote: Hi, I agree with Chris. It's a common setup: client == stunnel == haproxy == stunnel == server First stunnel runs in server mode while second one runs in client more. that way, HAProxy sees traffic in clear but the connection from the client and to the server are encrypted. cheers -- Gabriel Sosa Si buscas resultados distintos, no hagas siempre lo mismo. - Einstein
Re: SSL Backends
On Mon, Jul 16, 2012 at 4:39 PM, Gabriel Sosa sosagabr...@gmail.com wrote: IMHO if you run your servers in a trusted network, **haproxy == stunnel == server** part adds a lot of overhead I see your point but have to chime in with this: A trusted network is one small step away from being an untrusted network. Your web servers, and/or load balancers generally live in some kind of DMZ, which should be the least trusted part of the network. However, even the non-DMZ should not be completely trusted. It is very sane and sensible to encrypt protocols on ANY network. If you can afford to do so, then you probably should. My favorite common phrase about this is: hard and crunchy on the outside, soft and chewy on the inside.
IPv6 for source directive?
Hey, y'all! Apologies if this question has already been answered elsewhere; It looks like the mailing list archives stopped working last December, so I can't really check the recent history of this list. Anyway my question is this: The haproxy 1.5 documentation says the source directive takes an IPv4 address. Is this still the case for the latest development releases, or is it possible to specify an IPv6 source address (or perhaps a mix of the same, in case one has a mix of IPv4 and IPv6 back-ends, eh.)? If it's not possible to specify an IPv6 address to bind to for backend connections, has this feature been requested yet? Thanks, Stephen -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807
Re: SSL Backends
Guys, some applications provided in black boxes only accept connections on SSL, port 443. Or some type of company like banks don't want to have traffic in clear, even on their LAN... So you must encrypt traffic. By the way, stud has now a client mode: https://github.com/bumptech/stud/commit/7330881726e120ba021dc49b076b807acd0752c7 So you can chain stud = haproxy = stud, all of this with the proxy protocol (that said, not sure stud in client mode accept yet the proxy protocol). cheers
