Hi, I've setup a test between java7 clients and servers using SSL passthough. Unfurnately using a stick table like so:
stick-table type string len 20 size 2m expire 60m stick on ssl_fc_sni doesn't seem to have any effect in TCP mode (and stick on req_ssl_sni doesn't seem to be supported as previously mentioned). note that using static acl based routing rules like so: acl alias123 req_ssl_sni -i alias123.mydomain acl alias456 req_ssl_sni -i alias456.mydomain use_backend bk_backend1 if alias123 use_backend bk_backend1 if alias45 does work. But I really need them to be dynamic in order to let HAProxy load balance based on it, rather than the client application having to specify some pre-defined alias. ps. I'm using HA-Proxy version 1.5-dev17-59 2013/02/21 Kind regards, Robbert On Thu, Feb 28, 2013 at 1:13 PM, Robbert van Waveren <[email protected]>wrote: > Hi Baptiste, > > thanks for your reply. > I assumed ssl_fc_sni wasn't going to work as the documentation suggest it > needs to decipher the content. > Will give it a try with latest source from git. > > Regards, > > Robbert > > > > On Thu, Feb 28, 2013 at 11:30 AM, Baptiste <[email protected]> wrote: > >> 2 reasons: >> 1. use the right SSL sni pattern extraction: ssl_fc_sni >> 2. use the latest haproxy version (from git) >> >> good luck >> >> Baptiste >> >> >> On Thu, Feb 28, 2013 at 9:47 AM, Robbert van Waveren <[email protected]> >> wrote: >> > Hi Baptiste, >> > >> > Thanks for your reply. Seems I wasn't really clear enough in my >> > use-case/solution description. >> > >> > Both the client and the server in my scenario are internal java based >> > servers part of different clusters within the same LAN. >> > They can do SSL based on selfsigned client and server certificates with >> > wildcards on the domainname part. >> > >> > Schematically looking like this: >> > web client --> ssl termination @ haproxy1 --> java serverfarm1 (client) >> --> >> > ssl passthrough @ haproxy2 --> java serverfarm2 (server) >> > >> > As the client is also a java server holding its own session to the >> actual >> > web client I'd like to use that session (or an alias for it) as the >> > subdomain. >> > This means that the client from farm1 is able to send a per session >> unique >> > subdomainname from the first request to a server from farm2. >> > That session/alias doesn't have to make sense to the server, it could >> only >> > be used by HAProxy to send it to the correct server. >> > >> > Btw meanwhile I've futher looked into using the payload_lv but seems I >> can't >> > use it as the offset of the SNI part is variable. >> > So I'd still really like to be able to use: >> > stick on req_ssl_sni >> > >> > ps. Your blogs are great and one of the reasons I started with HAProxy, >> so I >> > already read most of them ;) >> > >> > Regards, >> > >> > Robbert >> > >> > >> > >> > On Thu, Feb 28, 2013 at 8:38 AM, Baptiste <[email protected]> wrote: >> >> >> >> On Wed, Feb 27, 2013 at 3:00 PM, Robbert van Waveren < >> [email protected]> >> >> wrote: >> >> > Hi, >> >> > >> >> > Ive got the following use-case that I cant seem to solve. >> >> > >> >> > Problem: >> >> > sticky session load balancing client-to-server SSL traffic without >> >> > decrypting it >> >> > assumption is that source ip and sslid can't be used as there are >> less >> >> > clients then servers in my scenario. >> >> > >> >> > My current solution (that does not work) is the following: >> >> > using an alias of the java sessionid as subdomainname within the >> request >> >> > and thus allowing HAProxy to see some per session unique id using SNI >> >> > and >> >> > stick on that. >> >> > Both the clients and the servers run java 7 so they should be SSL SNI >> >> > capable. >> >> > >> >> > My problem is that currently "stick on req_ssl_sni" does not seem to >> be >> >> > supported: >> >> > 'stick': unknown fetch method 'req_ssl_sni' >> >> > >> >> > >> >> > example hostname pattern: >> >> > somesession1.myserver.local >> >> > somesession2.myserver.local >> >> > somesession3.myserver.local >> >> > somesession4.myserver.local >> >> > >> >> > my current configuration: >> >> > listen sticky_server_to_server_ssl >> >> > mode tcp >> >> > bind :1000 >> >> > balance roundrobin >> >> > >> >> > tcp-request inspect-delay 5s >> >> > tcp-request content accept if { req_ssl_hello_type 1 } >> >> > >> >> > stick-table type string len 20 size 2m expire 60m >> >> > stick on req_ssl_sni >> >> > >> >> > server srv1 10.0.0.1:2000 weight 1 maxconn 100 check >> >> > server srv2 10.0.0.2:2000 weight 1 maxconn 100 check >> >> > >> >> > Are there any obvious answers/solutions to this that could help me? >> >> > If not, does my solution make sense to support in HAProxy? >> >> > >> >> > Considering HAProxy does support sticking on payload, could I perhaps >> >> > use >> >> > that for this: >> >> > acl clienthello req_ssl_hello_type 1 >> >> > stick-table type string len 20 size 2m expire 60m >> >> > stick on payload(...) if clienthello >> >> > >> >> > >> >> > Kind regards, >> >> > >> >> > Robbert >> >> > >> >> >> >> Hi Robbert, >> >> >> >> first of all, in order to do this, you must have a wildcard >> >> certificate, otherwise your client will get warnings (I don't know how >> >> you can manage such warnings in your Java client code). >> >> Second, you want to do persistence on an information provided by the >> >> client, BUT HAProxy can't learn it on the fly from the server first, >> >> which means that HAProxy may send the first and the second request >> >> from the same session to 2 different servers. but from request #2, you >> >> will have the persistence. >> >> the diagram bellow shows what happens: >> >> 1. client to haproxy to server on https://domain.com with SNI >> domain.com >> >> 2. server answers "come back to clientX.domain.com" >> >> 3. client to haproxy with https://clientX.domain.com + SNI >> >> clientX.domain.com >> >> ==> there are no link between requests from #1 and #3. >> >> so at #3, haproxy may choose a different server from #1, but will >> >> store clientX.domain.com in the stick table >> >> then whenever clientX.domain.com will get connected again, then >> >> HAProxy will be able to maintain persistence and redirect this user to >> >> the same server forerver (until expire timeout in the stick table >> >> actually). >> >> >> >> More about load-balancing and persistence: >> >> >> >> >> http://blog.exceliance.fr/2012/03/29/load-balancing-affinity-persistence-sticky-sessions-what-you-need-to-know/ >> >> >> >> Last but not least, you should avoid persistence on the first domain, >> >> because you may redirect all first requests to a single server, making >> >> it to generate symmetric keys which takes a huge amount of CPU >> >> resources (furthermore if your cert is big: 2K or more)... ! >> >> >> >> Baptiste >> > >> > >> > >
