Thanks Baptiste, I will try the latest snapshot. Mir
On Nov 7, 2011, at 10:27 PM, Baptiste wrote: > Hi, > > The configuration is for HAProxy 1.5-something :) > > cheers > > On Tue, Nov 8, 2011 at 3:00 AM, Mir Islam <[email protected]> wrote: >> Thanks Vincent for the link. That is exactly what I was looking for. However >> the configuration they provided does not work out of the box. My knowledge >> in HAProxy is less than two days old. So if you or anyone else can tell me >> what the following errors mean, I will appreciate it a lot. >> >> First one is simple, for some reason binary type is not valid for >> stick-table? All I could see in web site in reference to "ip" but not binary >> or other types. I have compiled haproxy 1.4.18 from source on linux. >> >> ./haproxy -f ./haproxy-zdm-ssl2.cfg >> [ALERT] 311/015412 (23710) : parsing [./haproxy-zdm-ssl2.cfg:8] : >> stick-table: unknown type 'binary'. >> [ALERT] 311/015412 (23710) : parsing [./haproxy-zdm-ssl2.cfg:10] : error >> detected while parsing ACL 'clienthello'. >> [ALERT] 311/015412 (23710) : parsing [./haproxy-zdm-ssl2.cfg:11] : error >> detected while parsing ACL 'serverhello'. >> [WARNING] 311/015412 (23710) : parsing [./haproxy-zdm-ssl2.cfg:14] : >> tcp-request inspect-delay will be ignored because backend 'https' has no >> frontend capability >> [ALERT] 311/015412 (23710) : parsing [./haproxy-zdm-ssl2.cfg:15] : error >> detected in backend 'https' while parsing 'if' condition >> [ALERT] 311/015412 (23710) : parsing [./haproxy-zdm-ssl2.cfg:18] : unknown >> keyword 'tcp-response' in 'backend' section >> [ALERT] 311/015412 (23710) : parsing [./haproxy-zdm-ssl2.cfg:24] : 'stick': >> unknown fetch method 'payload_lv(43,1)'. >> [ALERT] 311/015412 (23710) : parsing [./haproxy-zdm-ssl2.cfg:27] : 'stick': >> unknown fetch method 'payload_lv(43,1)'. >> [ALERT] 311/015412 (23710) : Error(s) found in configuration file : >> ./haproxy-zdm-ssl2.cfg >> [WARNING] 311/015412 (23710) : config : missing timeouts for backend 'https'. >> | While not properly invalid, you will certainly encounter various problems >> | with such a configuration. To fix this, please ensure that all following >> | timeouts are set to a non-zero value: 'client', 'connect', 'server'. >> [ALERT] 311/015412 (23710) : Fatal errors found in configuration. >> >> >> My configuration >> >> backend https >> mode tcp >> balance roundrobin >> srvtimeout 50000 >> >> # maximum SSL session ID length is 32 bytes. >> stick-table type binary len 32 size 30k expire 30m >> >> acl clienthello req_ssl_hello_type 1 >> acl serverhello rep_ssl_hello_type 2 >> >> # use tcp content accepts to detects ssl client and server hello. >> tcp-request inspect-delay 5s >> tcp-request content accept if clienthello >> >> # no timeout on response inspect delay by default. >> tcp-response content accept if serverhello >> >> # SSL session ID (SSLID) may be present on a client or server hello. >> # Its length is coded on 1 byte at offset 43 and its value starts >> # at offset 44. >> # Match and learn on request if client hello. >> stick on payload_lv(43,1) if clienthello >> >> # Learn on response if server hello. >> stick store-response payload_lv(43,1) if serverhello >> >> server s1 192.168.1.1:443 >> server s2 192.168.1.2:443 >> >> >> >> >> On Nov 7, 2011, at 12:00 PM, Vincent Bernat wrote: >> >>> OoO Pendant le journal télévisé du lundi 07 novembre 2011, vers 20:16, >>> Mir Islam <[email protected]> disait : >>> >>>> Yea that is the problem. Right now SSL is terminated at the >>>> application level on each server. There is no way to inspect the >>>> cookie even if the server sets one. Sticky session in TCP mode can be >>>> done by source IP (that is why I have balance source). But that >>>> creates the other problem as I mentioned. Folks coming from behind >>>> NAT will hit the same server and not get load balanced. Because >>>> HAProxy will think they are all the same. I was trying to find out if >>>> there is something else that could be done. From my own logical >>>> reasoning, no. :) but I have been wrong before so I was hoping >>>> someone had similar issue. >>> >>> See this post: >>> http://blog.exceliance.fr/2011/07/04/maintain-affinity-based-on-ssl-session-id/ >>> >>> While this won't work, in theory, if client is requesting to use >>> tickets, almost all clients keep the right session ID even when using >>> tickets. You should of course ensure that a client will keep the same >>> session ID all the time. This means that you need to ensure that your >>> web server is able to resume session with and without tickets correctly. >>> For example, with nginx, you need to configure a session cache. >>> -- >>> Vincent Bernat ☯ http://vincent.bernat.im >>> >>> Keep it right when you make it faster. >>> - The Elements of Programming Style (Kernighan & Plauger) >> >> >>
