Re: Follow-up on thread 'SSL handshake failure' from 2/5/2013
Hi Zack, On Thu, Apr 25, 2013 at 08:46:57PM +, Connelly, Zachary (CGI Federal) wrote: Lukas (et al), I pulled down the latest code and compiled (thanks for the build fix). I'm still getting the same problem with the latest code. Despite compiling with the debug options as specified we're not seeing a core dump come out yet to then do the backtrace against. I'm still looking around for it unless anyone knows what I might be missing. Let me know if there is anything else I can run and/or provide. Thanks for the trace you sent me. It would really help if you could send me the core file with the equivalent executable, and report the exact snapshot you used. I think that this crash explains why it randomly fails. Something is not working as expected, and when we're lucky, it crashes, but when we're unlucky, it probably silently uses an incorrect memory location explaining why the rest of the processing fails. The patch that was discussed in the thread you mentionned had no reason for changing anything, instead of clearing the errors unconditionally, it only cleared them if there were any. It's more of an optimization and the fact that it changed something indicates that we have a random bug somewhere. And your trace proves that ! Thanks, Willy
Re: HAProxy on FreeBSD 8.3 with transparent proxying (TProxy?)
Hi, On Fri, Apr 26, 2013 at 12:55:23AM +0200, PiBa-NL wrote: Hi All / Developers, Seams i have tranparent proxying working now on FreeBSD 8.3 with HAProxy1.5dev18 + small modification. Needed to add a firewall forwarding rule to forward the traffic to the localhost for socket processing. Could a developer please make the following change? /*/* Add the following on line 33 of /include/common/compact.h */*//* *//*#ifdef *//*IP_BINDANY*//* *//* /* FreeBSD define variables */*//* *//* #define SOL_IP IPPROTO_IP*//* *//* #define SOL_IPV6 IPPROTO_IPV6*//* *//* #define IP_TRANSPARENT IP_BINDANY*//* *//*#endif*/ It's quite hard to exactly understand what needs to be changed with such a syntax, could you please send a standard patch ? For this, just do a diff -urN between the original source directory and the modified one. Also I'm wondering whether we should define USE_FREEBSD_TPROXY instead of USE_LINUX_TPROXY for this. Maybe we should rename CONFIG_HAP_LINUX_TPROXY to CONFIG_HAP_FULL_TPROXY and adapt it depending on the OS. After this haproxy can be successfully compiled on FreeBSD8.3 with the USE_LINUX_TPROXY=yes build option and transparent proxying works when the fwd firewall rule is made active. On my pfSense2.1 system the following worked to load ipfw and add the fwd rule in ipfw.. : /sbin/kldload ipfw /sbin/sysctl net.inet.ip.pfil.inbound=pf net.inet6.ip6.pfil.inbound=pf net.inet.ip.pfil.outbound=pf net.inet6.ip6.pfil.outbound=pf /sbin/sysctl net.link.ether.ipfw=1 ipfw_context -a haproxy ipfw_context -s haproxy ipfw_context -a haproxy -n em0 *ipfw -x haproxy add 20 fwd localhost tcp from IP-BACKEND-SERVER 80 to any in recv em0* (This firewall rule should actually also check if the correct 'uid' of the haproxy process is set to also allow directly contacting the backendserver, but i could not get that part to work though that is not a HAProxy issue so should get fixed elsewhere.) And ideally it should be possible with 'pf' instead of 'ipfw', but that is still something i'm trying to investigate.. Maybe such information should go into a dedicated file in the doc/ directory. If this is not the correct way to fix/change this for FreeBSD could someone please advice on what is.? Thanks in advance. PiBa-NL Thanks, Willy
RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013
Hi! report the exact snapshot you used. He is at current HEAD by using 20130425 with c621d36ba applied manually on it (linux 2.6.18 without tproxy support). He also saw the crashes in -dev18, but I had him update the code. Thanks, Lukas
track log sessions
Hello all, My question is pretty simple. I just want to know if it's possible to track/log a session from the connexion to the disconnexion. I've seen that it was possible with the capture cookie statement but i don't want to change something from user side. Is there another way please ? Regards, Smana
Re: track log sessions
Hi, Capture cookie doesn't change anything, it adds to the log line the cookie value! pretty simple and straight forward, and this is how people usually track users. Of course, you must enable HTTP logging, turn your frontend in HTTP mode as well. Baptiste On Fri, Apr 26, 2013 at 9:39 AM, Smain Kahlouch smain...@gmail.com wrote: Hello all, My question is pretty simple. I just want to know if it's possible to track/log a session from the connexion to the disconnexion. I've seen that it was possible with the capture cookie statement but i don't want to change something from user side. Is there another way please ? Regards, Smana
CRL verification problem
Hi, all I have tested CRL verification for master of haproxy git repository under such conditions: * two CAs(CA1CA2) used to do verification * CRL file specified, but contains CRL only issued by CA1 When I send request with certificate issued by CA2, the verification will fail with the reason of 'Unknown CA', certificates issued by CA1 will be verified successfully. Then I append CRL issued by CA2 into CRL file. There are two CRLs in CRL file now. Client certificates issued by CA1 or CA2 can be verified OK. It means that if more than one CA used and CRL verification is enabled, each CRL issued by each CA should be put into one single file, otherwise client certificates issued by the CA which does not supply CRL may fail to be verified. Since haproxy called SSL library to do CRL verification with the following code: X509_STORE_set_flags(store, X509_V_FLAG_CRL_CHECK|X509_V_FLAG_CRL_CHECK_ALL); I guess that it may be the behavior of SSL library but found nothing related with this problem. Any help will be much appreciated. Best Regards, Godbach
Re: VS: Haparoxy hangs in one minute on config reload
Hi again Cyril, On Thu, Apr 25, 2013 at 11:04:03PM +0200, Willy Tarreau wrote: So I'll see how to enable this by default for health checks. The code will be different for 1.4 and 1.5 but it's worth doing it anyway. OK i've fixed it now in 1.4. In fact 1.5 already does this so no change was needed there. Cheers, Willy
Re: Follow-up on thread 'SSL handshake failure' from 2/5/2013
Hi don't understand: You said using openssl version 0.9.8y, but haproxy -vv shows OpenSSL 1.0.0a. Emeric On 04/25/2013 04:45 PM, Connelly, Zachary (CGI Federal) wrote: Lukas (et al), Here’s what I have so far: 1.use latest snapshot from [1] – *I’ll* *work on this today* 2.provide the output of haproxy –vv – *Output below* Sharing sig_handlers with pipe Sharing pendconn with pipe HA-Proxy version 1.5-dev18 2013/04/03 Copyright 2000-2013 Willy Tarreau w...@1wt.eu Build options : TARGET = linux26 CPU = generic CC = gcc CFLAGS = -g -O0 OPTIONS = USE_OPENSSL=1 USE_PCRE=1 Default settings : maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200 Encrypted password support via crypt(3): yes Built without zlib support (USE_ZLIB not set) Compression algorithms supported : identity Built with OpenSSL version : OpenSSL 1.0.0a 1 Jun 2010 OpenSSL library supports TLS extensions : yes OpenSSL library supports SNI : yes OpenSSL library supports prefer-server-ciphers : yes Available polling systems : epoll : pref=300, test result OK poll : pref=200, test result OK select : pref=150, test result OK Total: 3 (3 usable), will use epoll. 3.can you tell us OS, kernel and openssl version? *Linux 5.5, 2.6.18-164.11.1.el5, openssl version 0.9.8y* 4.compile haproxy with debug and without compiler optimizations: make DEBUG=-DDEBUG_FULL CFLAGS=-g -O0 TARGET=[...] *Done* 5.catch a backtrace of the crash with gdb (see [2] if you need details) – *Will work on this once #1 is complete from above* Thanks for the assistance so far, Zack *From:*Lukas Tribus [mailto:luky...@hotmail.com] *Sent:* Wednesday, April 24, 2013 12:36 PM *To:* Connelly, Zachary (CGI Federal); Baptiste *Cc:* haproxy@formilux.org *Subject:* RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013 Hi! Please also note that the second SOAP call made that fails the handshake also causes the HAProxy server to crash. Could you: - use latest snapshot from [1] - provide the output of haproxy -vv - can you tell us OS, kernel and openssl version? - compile haproxy with debug and without compiler optimizations: make DEBUG=-DDEBUG_FULL CFLAGS=-g -O0 TARGET=[...] - catch a backtrace of the crash with gdb (see [2] if you need details) Regards, Lukas [1] http://haproxy.1wt.eu/download/1.5/src/snapshot/ [2] http://www.mail-archive.com/haproxy@formilux.org/msg09472.html
RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013
Emeric, I'm not sure about that either actually. We definitely only have 0.9.8~ versions on the box and I explicitly reference the 0.9.8y library when I compile the executable: TARGET=linux26 USE_PCRE=1 USE_OPENSSL=1 ADDLIB=-L/usr/local/openssl-0.9.8y/lib LDFLAGS+=-ldl Zack -Original Message- From: Emeric Brun [mailto:eb...@exceliance.fr] Sent: Friday, April 26, 2013 6:04 AM To: Connelly, Zachary (CGI Federal) Cc: Lukas Tribus; Baptiste; haproxy@formilux.org Subject: Re: Follow-up on thread 'SSL handshake failure' from 2/5/2013 Hi don't understand: You said using openssl version 0.9.8y, but haproxy -vv shows OpenSSL 1.0.0a. Emeric On 04/25/2013 04:45 PM, Connelly, Zachary (CGI Federal) wrote: Lukas (et al), Here's what I have so far: 1.use latest snapshot from [1] - *I'll* *work on this today* 2.provide the output of haproxy -vv - *Output below* Sharing sig_handlers with pipe Sharing pendconn with pipe HA-Proxy version 1.5-dev18 2013/04/03 Copyright 2000-2013 Willy Tarreau w...@1wt.eumailto:w...@1wt.eu Build options : TARGET = linux26 CPU = generic CC = gcc CFLAGS = -g -O0 OPTIONS = USE_OPENSSL=1 USE_PCRE=1 Default settings : maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200 Encrypted password support via crypt(3): yes Built without zlib support (USE_ZLIB not set) Compression algorithms supported : identity Built with OpenSSL version : OpenSSL 1.0.0a 1 Jun 2010 OpenSSL library supports TLS extensions : yes OpenSSL library supports SNI : yes OpenSSL library supports prefer-server-ciphers : yes Available polling systems : epoll : pref=300, test result OK poll : pref=200, test result OK select : pref=150, test result OK Total: 3 (3 usable), will use epoll. 3.can you tell us OS, kernel and openssl version? *Linux 5.5, 2.6.18-164.11.1.el5, openssl version 0.9.8y* 4.compile haproxy with debug and without compiler optimizations: make DEBUG=-DDEBUG_FULL CFLAGS=-g -O0 TARGET=[...] *Done* 5.catch a backtrace of the crash with gdb (see [2] if you need details) - *Will work on this once #1 is complete from above* Thanks for the assistance so far, Zack *From:*Lukas Tribus [mailto:luky...@hotmail.com] *Sent:* Wednesday, April 24, 2013 12:36 PM *To:* Connelly, Zachary (CGI Federal); Baptiste *Cc:* haproxy@formilux.orgmailto:haproxy@formilux.org *Subject:* RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013 Hi! Please also note that the second SOAP call made that fails the handshake also causes the HAProxy server to crash. Could you: - use latest snapshot from [1] - provide the output of haproxy -vv - can you tell us OS, kernel and openssl version? - compile haproxy with debug and without compiler optimizations: make DEBUG=-DDEBUG_FULL CFLAGS=-g -O0 TARGET=[...] - catch a backtrace of the crash with gdb (see [2] if you need details) Regards, Lukas [1] http://haproxy.1wt.eu/download/1.5/src/snapshot/ [2] http://www.mail-archive.com/haproxy@formilux.org/msg09472.html
Re: Follow-up on thread 'SSL handshake failure' from 2/5/2013
Zack, On Fri, Apr 26, 2013 at 02:12:46PM +, Connelly, Zachary (CGI Federal) wrote: Emeric, I'm not sure about that either actually. We definitely only have 0.9.8~ versions on the box and I explicitly reference the 0.9.8y library when I compile the executable: TARGET=linux26 USE_PCRE=1 USE_OPENSSL=1 ADDLIB=-L/usr/local/openssl-0.9.8y/lib LDFLAGS+=-ldl You're missing a ADDINC somewhere, so I guess you're building with another version's headers and with this version's lib, which explains why haproxy -vv reports 1.0.0a (it reports the version used for building). We've checked with Emeric and I can confirm that the SSL struct changed between the two versions, which exactly explains the 8 bytes offset we found for ssl-sid_ctx_length which pointed to some wrong location. I have added a second control in the sources to report both the build version and the runtime version. Cheers, Willy
Re: Follow-up on thread 'SSL handshake failure' from 2/5/2013
On Fri, Apr 26, 2013 at 06:25:38PM +0200, Willy Tarreau wrote: We've checked with Emeric and I can confirm that the SSL struct changed between the two versions, which exactly explains the 8 bytes offset we found for ssl-sid_ctx_length which pointed to some wrong location. I have added a second control in the sources to report both the build version and the runtime version. Just an update, Emeric has removed the dereference on the SSL struct so that this issue does not happen in the future. But still you need to fix your build issue anyway, and check with haproxy -vv that build and runtime versions are the same. Willy
Re: Problems using unique-id in logs
Hi,
On Fri, Apr 26, 2013 at 06:10:24PM +0100, Pedro Mata-Mouros wrote:
Hi everyone,
Having some trouble with using unique-id in logs, in 1.5-dev18. The following
conf file will completely ignore log-format in defaults. I have to move it to
the frontend in order for something to appear in the logs. But then, I can't
get %ID to appear at all:
global
daemon
pidfile /var/run/haproxy.pid
log 127.0.0.1 local5
defaults
mode http
timeout server 3s
timeout client 3s
timeout connect 3s
log global
log-format %{+X}o\ asd\ %ID\ dsa
option httplog
Option httplog overrides log-format. Please just remove it.
option dontlognull
frontend in
bind 127.0.0.1:80
default_backend localhost
backend localhost
server host 127.0.0.1:8080
And this is the output (sorry, it's tcpdump):
17:49:29.258838 IP localhost.49956 localhost.syslog: SYSLOG local5.info,
length: 47
0x: 0200 4500 004b 40bf 4011 E..K@...@...
0x0010: 7f00 0001 7f00 0001 c324 0202 0037 fe4a .$...7.J
0x0020: 3c31 3734 3e41 7072 2032 3620 3137 3a34 174Apr.26.17:4
0x0030: 393a 3239 2068 6170 726f 7879 5b31 3432 9:29.haproxy[142
0x0040: 3236 5d3a 2061 7364 202d 2064 7361 0a26]:.asd.-.dsa.
Spot any problems in that config?
You need to define the unique-id format using unique-id-format.
Willy
RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013
Thanks Willy/Emeric! I will try and track down the OpenSSL and we have and ensure we got the right versions. I did add the ADDINC parameter to the build to explicitly point to the include linked with the lib and same error occurred. I will also download the two fixes from today and see if the dereference especially helps resolve the issue. Zack
RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013
Two things: 1. After taking the two patches, ran version and am definitely getting different versions. I'll have to look into how this could be with the admins some more. Built with OpenSSL version : OpenSSL 1.0.0a 1 Jun 2010 Running on OpenSSL version : OpenSSL 0.9.8y 5 Feb 2013 (VERSIONS DIFFER!) 2. The fix for the SSL dereference looks to have solved the issue! I am no longer getting a crash and SSL seems to be handling the offload correctly without issue. Thank you so much again, I really appreciate the quick support and patience (as you can probably guess I am not the strongest Linux/C developer)! Zack
Re: HAProxy on FreeBSD 8.3 with transparent proxying (TProxy?)
Hi Willy, Sorry for the weird syntax.. I made the text 'bold', but that seams to have come out differently... Anyway i hope the 'patch' below is something you can work with.? As for renaming the CONFIG_HAP_LINUX_TPROXY to something different would require everyone that on a regular basis builds HAProxy with this feature to change their build flags.. So i don't think it should be renamed/removed. Also while adding another flag for clarity purposes, i don't think it really adds that much ease of use, and would require new make scripts and several other changes though-out where transparent proxying is implemented. Ive changed the defines a little more to i think be 'best compatible' with i think any circumstances.. Is this something that you could 'apply'?: --- workoriginal/haproxy-1.5-dev18/include/common/compat.h 2013-04-26 19:36:15.0 + +++ work/haproxy-1.5-dev18/include/common/compat.h 2013-04-26 20:32:15.0 + @@ -81,7 +81,16 @@ #endif /* On Linux, IP_TRANSPARENT and/or IP_FREEBIND generally require a kernel patch */ +/* On FreeBSD, IP_BINDANY is supported from FreeBSD 8 and up */ #if defined(CONFIG_HAP_LINUX_TPROXY) + #if defined(BSD) defined(IP_BINDANY) defined(IPV6_BINDANY) +/* FreeBSD defines */ +#define SOL_IP IPPROTO_IP +#define SOL_IPV6 IPPROTO_IPV6 +#define IP_TRANSPARENT IP_BINDANY +#define IPV6_TRANSPARENT IPV6_BINDANY + #endif + #if !defined(IP_FREEBIND) #define IP_FREEBIND 15 #endif /* !IP_FREEBIND */ Op 26-4-2013 8:33, Willy Tarreau schreef: Hi, On Fri, Apr 26, 2013 at 12:55:23AM +0200, PiBa-NL wrote: Hi All / Developers, Seams i have tranparent proxying working now on FreeBSD 8.3 with HAProxy1.5dev18 + small modification. Needed to add a firewall forwarding rule to forward the traffic to the localhost for socket processing. Could a developer please make the following change? /*/* Add the following on line 33 of /include/common/compact.h */*//* *//*#ifdef *//*IP_BINDANY*//* *//* /* FreeBSD define variables */*//* *//* #define SOL_IP IPPROTO_IP*//* *//* #define SOL_IPV6 IPPROTO_IPV6*//* *//* #define IP_TRANSPARENT IP_BINDANY*//* *//*#endif*/ It's quite hard to exactly understand what needs to be changed with such a syntax, could you please send a standard patch ? For this, just do a diff -urN between the original source directory and the modified one. Also I'm wondering whether we should define USE_FREEBSD_TPROXY instead of USE_LINUX_TPROXY for this. Maybe we should rename CONFIG_HAP_LINUX_TPROXY to CONFIG_HAP_FULL_TPROXY and adapt it depending on the OS. After this haproxy can be successfully compiled on FreeBSD8.3 with the USE_LINUX_TPROXY=yes build option and transparent proxying works when the fwd firewall rule is made active. On my pfSense2.1 system the following worked to load ipfw and add the fwd rule in ipfw.. : /sbin/kldload ipfw /sbin/sysctl net.inet.ip.pfil.inbound=pf net.inet6.ip6.pfil.inbound=pf net.inet.ip.pfil.outbound=pf net.inet6.ip6.pfil.outbound=pf /sbin/sysctl net.link.ether.ipfw=1 ipfw_context -a haproxy ipfw_context -s haproxy ipfw_context -a haproxy -n em0 *ipfw -x haproxy add 20 fwd localhost tcp from IP-BACKEND-SERVER 80 to any in recv em0* (This firewall rule should actually also check if the correct 'uid' of the haproxy process is set to also allow directly contacting the backendserver, but i could not get that part to work though that is not a HAProxy issue so should get fixed elsewhere.) And ideally it should be possible with 'pf' instead of 'ipfw', but that is still something i'm trying to investigate.. Maybe such information should go into a dedicated file in the doc/ directory. If this is not the correct way to fix/change this for FreeBSD could someone please advice on what is.? Thanks in advance. PiBa-NL Thanks, Willy
Re: Follow-up on thread 'SSL handshake failure' from 2/5/2013
On Fri, Apr 26, 2013 at 06:22:57PM +, Connelly, Zachary (CGI Federal) wrote: Two things: 1. After taking the two patches, ran version and am definitely getting different versions. I'll have to look into how this could be with the admins some more. Built with OpenSSL version : OpenSSL 1.0.0a 1 Jun 2010 Running on OpenSSL version : OpenSSL 0.9.8y 5 Feb 2013 (VERSIONS DIFFER!) 2. The fix for the SSL dereference looks to have solved the issue! I am no longer getting a crash and SSL seems to be handling the offload correctly without issue. Thank you so much again, I really appreciate the quick support and patience (as you can probably guess I am not the strongest Linux/C developer)! Thank you for the tests and reports, Zack. I tend to be confident that if it runs OK for you it should be stable, but I have no idea how your lib might handle some 1.0-only extensions. Cheers, Willy
Re: HAProxy on FreeBSD 8.3 with transparent proxying (TProxy?)
Hi, On Fri, Apr 26, 2013 at 08:40:49PM +0200, PiBa-NL wrote: Hi Willy, Sorry for the weird syntax.. I made the text 'bold', but that seams to have come out differently... As you can guess, there is no bold attribute in source code, so it must necessarily appear differently at some point. Anyway i hope the 'patch' below is something you can work with.? As for renaming the CONFIG_HAP_LINUX_TPROXY to something different would require everyone that on a regular basis builds HAProxy with this feature to change their build flags.. So i don't think it should be renamed/removed. Also while adding another flag for clarity purposes, i don't think it really adds that much ease of use, and would require new make scripts and several other changes though-out where transparent proxying is implemented. I think it would not cause real issues, unless people are forcing all CFLAGS, which would be a bit hasardous, but still possible. So I think we'll stick to not changing it. Ive changed the defines a little more to i think be 'best compatible' with i think any circumstances.. Is this something that you could 'apply'?: Yes, definitely, thank you ! Well, your mailer seems to have wrapped lines, but they're just a few so I can fix that by hand : --- workoriginal/haproxy-1.5-dev18/include/common/compat.h 2013-04-26 19:36:15.0 + +++ work/haproxy-1.5-dev18/include/common/compat.h 2013-04-26 20:32:15.0 + @@ -81,7 +81,16 @@ #endif /* On Linux, IP_TRANSPARENT and/or IP_FREEBIND generally require a kernel patch */ +/* On FreeBSD, IP_BINDANY is supported from FreeBSD 8 and up */ #if defined(CONFIG_HAP_LINUX_TPROXY) + #if defined(BSD) defined(IP_BINDANY) defined(IPV6_BINDANY) +/* FreeBSD defines */ +#define SOL_IP IPPROTO_IP +#define SOL_IPV6 IPPROTO_IPV6 +#define IP_TRANSPARENT IP_BINDANY +#define IPV6_TRANSPARENT IPV6_BINDANY + #endif + #if !defined(IP_FREEBIND) #define IP_FREEBIND 15 #endif /* !IP_FREEBIND */ I'll add a comment in the README about this option being available in FreeBSD 8+ as well. If you could add a small file with your config example, it would be nice, so that people don't ask how to do it all the time on the mailing list. Thanks, Willy
Re: HAProxy on FreeBSD 8.3 with transparent proxying (TProxy?)
Now that I'm seeing the patch in its context, I think it's not the cleanest way to do it, because we redefine IPV6_TRANSPARENT and IP_TRANSPARENT when IP_FREEBIND is not defined, while we don't use this one and the other ones are defined below. Also I'm concerned about the result of running this with an unsupported kernel, which will fail the IP_TRANSPARENT syscall and fall back to IP_FREEBIND, arbitrarily forced to 15 (since it's for Linux) and which I don't know what it means on FreeBSD. So I'm thinking again about having a separate USE_FREEBSD_TPROXY option, I'll see what I can come up with. Regards, Willy
haproxy ssl termination stats
Is there a way to debug ssl handshake failures? I occasionally see an error message in the logs which says Connection error during SSL handshake. It rarely happens so debugging it is difficult with something like packet captures because we have over 5000 ssl requests per second. What I was hoping for was a way to get additional information in the log entry to identify why the ssl handshake failed. The second thing that I am interested in knowing is how long it took for the SSL handshake to complete and where the time was spent during the handshake. In the current logging we see very detailed information about connection times, but it seams that the ssl handshake time is included in the client connect time. It is difficult to know if ssl handshake slowdowns are due to a server side capacity issue or a client side issue. The third thing that would be great to know is how many ssl connections were new vs reuse. Is there a way to capture this information either on the stats page / stats socket, or in the logs? Thanks, David T.
RE: HAProxy on FreeBSD 8.3 with transparent proxying (TProxy?)
Hi, throwing in my two cents here, based on a few uneducated guesses reading the Makefile, etc. Feel free to disagree/correct/shout at me :) (actually I wrote this before Willy answered) As for renaming the CONFIG_HAP_LINUX_TPROXY to something different would require everyone that on a regular basis builds HAProxy with this feature to change their build flags.. The name CONFIG_HAP_LINUX_TPROXY or USE_LINUX_TPROXY suggests this is for Linux. Implementing compatibility changes for FreeBSD in those flags is misleading, whether they are internal (like CONFIG_HAP_LINUX_TPROXY) or external (USE_LINUX_TPROXY). I think we should avoid that. would require new make scripts and several other changes though-out where transparent proxying is implemented. If you built haproxy before on FreeBSD and used transparent proxying, then it probably didn't work at all (like in your case) or those values have been defined in another place, like by libc or by a manual definition. Either way, we don't break anything that currently works by introducing a new build flag. So you would only have to adjust your make line if you actually need it and I think thats does less long-term harm than defining those things under the USE_LINUX_TPROXY/CONFIG_HAP_LINUX_TPROXY hat. Also I'm wondering whether we should define USE_FREEBSD_TPROXY instead of USE_LINUX_TPROXY for this. Maybe we should rename CONFIG_HAP_LINUX_TPROXY to CONFIG_HAP_FULL_TPROXY and adapt it depending on the OS. Yes, that makes more sense to me. We should probably clarify the condition with OpenBSD. I assume those defines are the same for all BSD flavors? So should we introduce a more generic flag like USE_BSD_TPROXY instead to avoid a USE flag for every BSD or does the difference between them justify a per-BSD USE flag? Regards, Lukas
Re: HAProxy on FreeBSD 8.3 with transparent proxying (TProxy?)
Hi Lukas, On Fri, Apr 26, 2013 at 10:26:33PM +0200, Lukas Tribus wrote: Hi, throwing in my two cents here, based on a few uneducated guesses reading the Makefile, etc. Feel free to disagree/correct/shout at me :) Thanks for sharing your thoughts, I feel less alone sometimes when I can discuss choices. (actually I wrote this before Willy answered) As for renaming the CONFIG_HAP_LINUX_TPROXY to something different would require everyone that on a regular basis builds HAProxy with this feature to change their build flags.. The name CONFIG_HAP_LINUX_TPROXY or USE_LINUX_TPROXY suggests this is for Linux. Implementing compatibility changes for FreeBSD in those flags is misleading, whether they are internal (like CONFIG_HAP_LINUX_TPROXY) or external (USE_LINUX_TPROXY). I think we should avoid that. OK, that was my first impression as well. It looks unpolished but can be understood sometimes during a transition, but not for the final state. would require new make scripts and several other changes though-out where transparent proxying is implemented. If you built haproxy before on FreeBSD and used transparent proxying, then it probably didn't work at all (like in your case) or those values have been defined in another place, like by libc or by a manual definition. Either way, we don't break anything that currently works by introducing a new build flag. So you would only have to adjust your make line if you actually need it and I think thats does less long-term harm than defining those things under the USE_LINUX_TPROXY/CONFIG_HAP_LINUX_TPROXY hat. Also I'm wondering whether we should define USE_FREEBSD_TPROXY instead of USE_LINUX_TPROXY for this. Maybe we should rename CONFIG_HAP_LINUX_TPROXY to CONFIG_HAP_FULL_TPROXY and adapt it depending on the OS. Yes, that makes more sense to me. We should probably clarify the condition with OpenBSD. I assume those defines are the same for all BSD flavors? So should we introduce a more generic flag like USE_BSD_TPROXY instead to avoid a USE flag for every BSD or does the difference between them justify a per-BSD USE flag? OK I have reviewed the existing code a bit. Most of the usages of CONFIG_HAP_LINUX_TPROXY are : 1) define the appropriate flags when they're not defined (kernel newer than libc) 2) enable parsing the option 3) enable the setsockopt calls (one of which is wrong for FBSD). So what I'm thinking about is to change that : 1) solely rely on the various per-OS flags to decide whether or not transparent proxy is supported (eg: IP_FREEBIND, IP_TRANSPARENT, IP_BINDANY, ...). That way we don't need an OS-specific option for something that automatically comes with the OS and that can be detected using a #ifdef and is enabled using a config setting anyway (eg: the transparent or usesrc keyword). 2) keep CONFIG_HAP_LINUX_TPROXY to force setting the values on linux when they're not set (as it initially was made for) 3) only implement the setsockopt() that have their appropriate define. 4) report in the -vv output what options are supported. Thus it will become trivial to add support for other OSes (I believe OpenBSD also supports it). What do you think about this ? Regards, Willy
Re: HAProxy on FreeBSD 8.3 with transparent proxying (TProxy?)
Hi Willy / Lukas, It seams to me OpenBSD doesn't support the IP_BINDANY flag..: http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/netinet/in.h http://www.openbsd.org/cgi-bin/cvsweb/%7Echeckout%7E/src/sys/netinet/in.h While FreeBSD does: http://svnweb.freebsd.org/base/head/sys/netinet/in.h?view=markup But then again neither of them supports SOL_IP, so i would expect compilation to simply 'fail'. When trying to compile with the USE_LINUX_TPROXY option. The combination i think is unlikely to cause problems for other currently working builds/systems.. If you want i can probably come up with a combination that makes it work for FreeBSD with a special USE_FREEBSD_TPROXY make option. Or go for the 'full automatic inclusion' depending on available flags. Which i think is even 'nicer'. But probably needs more testing to confirm proper working.. I would be willing to make these changes. Is this the way to go? Thanks for reviewing my proposed changes sofar. PiBa-NL Op 26-4-2013 22:40, Willy Tarreau schreef: Hi Lukas, On Fri, Apr 26, 2013 at 10:26:33PM +0200, Lukas Tribus wrote: Hi, throwing in my two cents here, based on a few uneducated guesses reading the Makefile, etc. Feel free to disagree/correct/shout at me :) Thanks for sharing your thoughts, I feel less alone sometimes when I can discuss choices. (actually I wrote this before Willy answered) As for renaming the CONFIG_HAP_LINUX_TPROXY to something different would require everyone that on a regular basis builds HAProxy with this feature to change their build flags.. The name CONFIG_HAP_LINUX_TPROXY or USE_LINUX_TPROXY suggests this is for Linux. Implementing compatibility changes for FreeBSD in those flags is misleading, whether they are internal (like CONFIG_HAP_LINUX_TPROXY) or external (USE_LINUX_TPROXY). I think we should avoid that. OK, that was my first impression as well. It looks unpolished but can be understood sometimes during a transition, but not for the final state. would require new make scripts and several other changes though-out where transparent proxying is implemented. If you built haproxy before on FreeBSD and used transparent proxying, then it probably didn't work at all (like in your case) or those values have been defined in another place, like by libc or by a manual definition. Either way, we don't break anything that currently works by introducing a new build flag. So you would only have to adjust your make line if you actually need it and I think thats does less long-term harm than defining those things under the USE_LINUX_TPROXY/CONFIG_HAP_LINUX_TPROXY hat. Also I'm wondering whether we should define USE_FREEBSD_TPROXY instead of USE_LINUX_TPROXY for this. Maybe we should rename CONFIG_HAP_LINUX_TPROXY to CONFIG_HAP_FULL_TPROXY and adapt it depending on the OS. Yes, that makes more sense to me. We should probably clarify the condition with OpenBSD. I assume those defines are the same for all BSD flavors? So should we introduce a more generic flag like USE_BSD_TPROXY instead to avoid a USE flag for every BSD or does the difference between them justify a per-BSD USE flag? OK I have reviewed the existing code a bit. Most of the usages of CONFIG_HAP_LINUX_TPROXY are : 1) define the appropriate flags when they're not defined (kernel newer than libc) 2) enable parsing the option 3) enable the setsockopt calls (one of which is wrong for FBSD). So what I'm thinking about is to change that : 1) solely rely on the various per-OS flags to decide whether or not transparent proxy is supported (eg: IP_FREEBIND, IP_TRANSPARENT, IP_BINDANY, ...). That way we don't need an OS-specific option for something that automatically comes with the OS and that can be detected using a #ifdef and is enabled using a config setting anyway (eg: the transparent or usesrc keyword). 2) keep CONFIG_HAP_LINUX_TPROXY to force setting the values on linux when they're not set (as it initially was made for) 3) only implement the setsockopt() that have their appropriate define. 4) report in the -vv output what options are supported. Thus it will become trivial to add support for other OSes (I believe OpenBSD also supports it). What do you think about this ? Regards, Willy
Re: HAProxy on FreeBSD 8.3 with transparent proxying (TProxy?)
On Fri, Apr 26, 2013 at 11:03:00PM +0200, PiBa-NL wrote: Hi Willy / Lukas, It seams to me OpenBSD doesn't support the IP_BINDANY flag..: http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/netinet/in.h http://www.openbsd.org/cgi-bin/cvsweb/%7Echeckout%7E/src/sys/netinet/in.h it seems it has, but differently : http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2008-07/msg00399.html While FreeBSD does: http://svnweb.freebsd.org/base/head/sys/netinet/in.h?view=markup But then again neither of them supports SOL_IP, so i would expect compilation to simply 'fail'. When trying to compile with the USE_LINUX_TPROXY option. Which is exactly the reason I don't want to remap these things which are linux-specific, and instead use the proper call depending on the available flags. Eg something like this : #if defined(SOL_IP) defined(IP_TRANSPARENT) /* linux */ ret = setsockop(fd, SOL_IP, IP_TRANSPARENT, one, sizeof(one)); #elif defined (IP_PROTOIP) defined(IP_BINDANY) /* freebsd */ ret = setsockop(fd, IP_PROTOIP, IP_BINDANY, one, sizeof(one)); #elif defined (IP_PROTOIP) defined(IP_BINDANY) /* openbsd */ ret = setsockop(fd, SOL_SOCKET, SO_BINDANY, one, sizeof(one)); #else /* unsupported platform */ ret = -1; #endif The combination i think is unlikely to cause problems for other currently working builds/systems.. If you want i can probably come up with a combination that makes it work for FreeBSD with a special USE_FREEBSD_TPROXY make option. No, really I think something like above is much better for the long term. It's more work to adapt existing code first but will pay in the long term, even in the short term if it allows us to support OpenBSD at the same time. Or go for the 'full automatic inclusion' depending on available flags. Which i think is even 'nicer'. But probably needs more testing to confirm proper working.. I would be willing to make these changes. Is this the way to go? As you like, if you feel comfortable with changing the way the current code works (the linux-specific one), feel free to try, otherwise I can do it over the week-end, and then a second patch derived from yours will bring in support for FreeBSD then OpenBSD if someone here is able to test it. Thanks for reviewing my proposed changes sofar. you're welcome :-) Willy
Re: VS: Haparoxy hangs in one minute on config reload
Hi Willy, Le 26/04/2013 11:50, Willy Tarreau a écrit : Hi again Cyril, On Thu, Apr 25, 2013 at 11:04:03PM +0200, Willy Tarreau wrote: So I'll see how to enable this by default for health checks. The code will be different for 1.4 and 1.5 but it's worth doing it anyway. OK i've fixed it now in 1.4. In fact 1.5 already does this so no change was needed there. Thanks ! That was fast, as usual :-) I'll provide them a new package which includes this patch. -- Cyril Bonté
Re: HAProxy on FreeBSD 8.3 with transparent proxying (TProxy?)
Hi Willy, Ill give it a try and send the patch as an attachment, though im not 100% comfortable with the code. I think i can do it. Will take me a few days though.. Thanks sofar. Op 26-4-2013 23:12, Willy Tarreau schreef: On Fri, Apr 26, 2013 at 11:03:00PM +0200, PiBa-NL wrote: Hi Willy / Lukas, It seams to me OpenBSD doesn't support the IP_BINDANY flag..: http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/netinet/in.h http://www.openbsd.org/cgi-bin/cvsweb/%7Echeckout%7E/src/sys/netinet/in.h it seems it has, but differently : http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2008-07/msg00399.html While FreeBSD does: http://svnweb.freebsd.org/base/head/sys/netinet/in.h?view=markup But then again neither of them supports SOL_IP, so i would expect compilation to simply 'fail'. When trying to compile with the USE_LINUX_TPROXY option. Which is exactly the reason I don't want to remap these things which are linux-specific, and instead use the proper call depending on the available flags. Eg something like this : #if defined(SOL_IP) defined(IP_TRANSPARENT) /* linux */ ret = setsockop(fd, SOL_IP, IP_TRANSPARENT, one, sizeof(one)); #elif defined (IP_PROTOIP) defined(IP_BINDANY) /* freebsd */ ret = setsockop(fd, IP_PROTOIP, IP_BINDANY, one, sizeof(one)); #elif defined (IP_PROTOIP) defined(IP_BINDANY) /* openbsd */ ret = setsockop(fd, SOL_SOCKET, SO_BINDANY, one, sizeof(one)); #else /* unsupported platform */ ret = -1; #endif The combination i think is unlikely to cause problems for other currently working builds/systems.. If you want i can probably come up with a combination that makes it work for FreeBSD with a special USE_FREEBSD_TPROXY make option. No, really I think something like above is much better for the long term. It's more work to adapt existing code first but will pay in the long term, even in the short term if it allows us to support OpenBSD at the same time. Or go for the 'full automatic inclusion' depending on available flags. Which i think is even 'nicer'. But probably needs more testing to confirm proper working.. I would be willing to make these changes. Is this the way to go? As you like, if you feel comfortable with changing the way the current code works (the linux-specific one), feel free to try, otherwise I can do it over the week-end, and then a second patch derived from yours will bring in support for FreeBSD then OpenBSD if someone here is able to test it. Thanks for reviewing my proposed changes sofar. you're welcome :-) Willy
RE: Question on feature stability in 1.5
Hi Lukas Horribly late response but thanks for the thorough reply. I've been doing additional testing and HAProxy is filling all our needs thus far (I've got one implementation that I'll send to the DL separately). No bugs or odd behavior to report yet. - Ahmed Osman -Original Message- From: Lukas Tribus [mailto:luky...@hotmail.com] Sent: Tuesday, April 09, 2013 3:01 AM To: Ahmed Osman Cc: haproxy@formilux.org Subject: RE: Question on feature stability in 1.5 Hi Ahmed, I wanted to find out if the features I'm using can be considered complete for 1.5. [...] if these are feature complete (or stable) The latest 1.5 snapshot should be fairly usable also in production, but since there is no feature freeze, that will very likely change with new features beeing commited to 1.5. If you would like to run development software in production, you need to do extensive testing prior to deploying it and be aware that troubleshooting bugs will likely be needed. If thats something you are willing to do - great (that way you help making 1.5 more stable). On the other hand, if you would like a stable solution which is as stable as possibile, you better not use to haproxy 1.5. Nginx may be a solution an alternative at that point (it does not have all those fancy load- balancing features haproxy has, but it may be enough for your deployment). Regards, Lukas
Keeping LB pools status in sync
Hello Everyone, I'm wondering if anyone is able to tell me if this is default behavior or if I need to configure this. In a nutshell I have this setup: LB_Pool1 Server1:6060 Server2:6060 LB_Pool2 Server1:80 Server2:80 I can do a check pretty easily on LB_Pool2 however I don't have a method for doing so on LB_Pool1. If something goes wrong with Server1 then the check in LB_Pool2 will detect it immediately and remove it from the pool until it's back up. Will Server1 be removed from LB_Pool1 at the same time? And if not, how would I set it up so that happens? Ahmed Osman DevOps Engineer Infrastructure Support Services TIBCO Spotfire
Re: Keeping LB pools status in sync
On 4/26/13 8:09 PM, Ahmed Osman wrote: Hello Everyone, I'm wondering if anyone is able to tell me if this is default behavior or if I need to configure this. In a nutshell I have this setup: LB_Pool1 Server1:6060 Server2:6060 LB_Pool2 Server1:80 Server2:80 I can do a check pretty easily on LB_Pool2 however I don't have a method for doing so on LB_Pool1. If something goes wrong with Server1 then the check in LB_Pool2 will detect it immediately and remove it from the pool until it's back up. Will Server1 be removed from LB_Pool1 at the same time? And if not, how would I set it up so that happens? No, but you can set the check port to 80 on pool 1 - Is there some reason why you can't check port 6060?
Re: Keeping LB pools status in sync
It sounds like you're asking how to use a server's health state in one backend as the health state in another. If so you can use the track option on the servers backend pool1 server server1 1.1.1.1:6060 track pool2/server1 server server2 1.1.1.2:6060 track pool2/server2 backend pool2 server server1 1.1.1.1:80 check server server2 1.1.1.2:80 check Is that what you want? -Bryan On Fri, Apr 26, 2013 at 5:09 PM, Ahmed Osman aos...@tibco.com wrote: Hello Everyone, ** ** I’m wondering if anyone is able to tell me if this is default behavior or if I need to configure this. In a nutshell I have this setup: ** ** LB_Pool1 Server1:6060 Server2:6060 ** ** LB_Pool2 Server1:80 Server2:80 ** ** ** ** I can do a check pretty easily on LB_Pool2 however I don’t have a method for doing so on LB_Pool1. If something goes wrong with Server1 then the check in LB_Pool2 will detect it immediately and remove it from the pool until it’s back up. Will Server1 be removed from LB_Pool1 at the same time? And if not, how would I set it up so that happens? ** ** ** ** ** ** ** ** *Ahmed Osman* *DevOps Engineer* *Infrastructure Support Services* *TIBCO Spotfire* ** **
Re: urls in stick-table, any timeline?
Is this in the latest stable release?
On Thu, Apr 25, 2013 at 11:38 AM, Baptiste bed...@gmail.com wrote:
Hi,
So basically, you want to rate limit on the URL including the query string.
something like:
frontend webservice
[...]
acl url_to_protect path /something/object /something_else/whatever
stick-table type string len 128 size 1m expire 10m store gpc0
tcp-request content track-sc1 url if url_to_protect
tcp-request content reject if { sc1_get_gpc0 gt 0 }
[...]
backend webservice
[...]
acl url_to_protect path /something/object /something_else/whatever
stick-table type string len 128 size 1m expire 10m store http_req_rate(1m)
tcp-request content track-sc2 url if url_to_protect
acl abuser sc2_http_req_rate gt 100
acl mark_as_abuser sc1_inc_gpc0 gt 0
tcp-request content reject if abuser mark_as_abuser
[...]
Basically, you're going to track only the URLs which matches the
url_to_protect acl.
On the frontend, you just store the URLs + a counter (gpc0) which will
be used to track the banned URLs.
In the backend, you store the URLs + the HTTP request rate over 1
minute associated to each of them. A couple of ACLs monitor the
request rate and increments gpc0 from frontend table if the req rate
is over a limit (100 in this case).
Note that it can be easy to forge a URL, so you could drop all the
URLs which does not look like regular.
I mean /other?id=123 and /other?id=123foo=bar will be 2 URLs for the same
user.
Otherwise, instead of tracking on 'url' you can track a single url
parameter like using 'urlp(id)' .
I have not tested the configuration above, I made it out of my head,
any issues, please let me know.
And please let me know if it works in your case.
Baptiste
On Thu, Apr 25, 2013 at 4:49 PM, S Ahmed sahmed1...@gmail.com wrote:
Each client (might be upto 100K of them) will have a unique URL, let me
clarify the url:
client#123
api.example.com/some_thing/other?clientId=123
client#123
api.example.com/some_thing/other?clientId=124
etc.
So each client has a unique URL, but the source IP of the client might be
different as they will be connecting to this service from multiple
servers.
I want to rate limit each client individually, giving them e.g. 100
requests
per minute, if they go over, just drop the connection as fast as
possible.
Also, is it possible to rate limit each client with a different rate
limit?
e.g. some may be 50 requests per minute, while others maybe be 100.
On Thu, Apr 25, 2013 at 1:24 AM, Baptiste bed...@gmail.com wrote:
Hi,
Last question: Will you have one URL per client? I mean will the query
string change with each client?
Then do you want to rate limit each client individually or do you want
to rate limit the number of call to the script named other as a
whole in your example?
Baptiste
On Wed, Apr 24, 2013 at 7:49 PM, S Ahmed sahmed1...@gmail.com wrote:
Nice!
Is this in the latest 1.4 release or a dev release?
I need to rate limit on a URL (that includes query string values)
like:
api.example.com/some_thing/other?id=asdf234asdf234id2=asdf234234
Multiple sources are possible, but I don't care of the source IP I
just
want
to rate limit on the URL (customers will be using this endpoint from
their
servers, but I want to rate limit to x number of requests per minute,
if
they go over, just drop the request until the rate limit has expired).
On Tue, Apr 23, 2013 at 1:39 AM, Baptiste bed...@gmail.com wrote:
Hi Ahmed,
Yes, it has been implemented.
You can store a URL and rate limited on it.
Baptiste
On Mon, Apr 22, 2013 at 11:15 PM, S Ahmed sahmed1...@gmail.com
wrote:
Hello,
Has this feature been released yet by any change? :)
Again my initial request was to do:
I was told that soon you will be able to store a URL in a
stick-table,
so I
could block a particular url and then remove the block by making a
request.
I situation is I will be blocking up to 250K urls (for rate
limiting,
hard
drop any connection.for a given period of time, then I need to
un-block
them).
Any rough timelines on when this might be released?
Soon, you'll be able to store an URL in a stick-table, so you'll be
able to update a gpc counter by setting up a particular header on
the
server side which tells HAProxy to block this request.
For the cancellation of this blocking system, you could request the
URL with a particular header to unblock it.
On Tue, Aug 21, 2012 at 2:04 PM, Baptiste bed...@gmail.com
wrote:
Hey,
Nothing coming right now.
Maybe for Christmas :)
cheers
On Tue, Aug 21, 2012 at 5:19 PM, S Ahmed sahmed1...@gmail.com
wrote:
Hello,
Any updates or guestimates on if sticky-table feature will be
released?
Just haven't been watching
Re: Follow-up on thread 'SSL handshake failure' from 2/5/2013
Hi, If it can help, I've been in touch with Emeric about SSL handshake failure since some times now but it's maybe preferable to use the ML to share experience. I'm using the following cipher filter list : 'ALL:!SSLv2:!eNULL:!aNULL:!LOW:!EXPORT:!kECDH:!MD5:@STRENGTH' The PEM file I used is composed by the following : -BEGIN CERTIFICATE- = Leaf cert -BEGIN CERTIFICATE- = Intermediate cert -BEGIN CERTIFICATE- = Root cert -BEGIN DH PARAMETERS- = openssl dhparam 4096 result -BEGIN DSA PARAMETERS- = openssl dsaparam 4096 result -BEGIN EC PARAMETERS- = openssl ecparam -name prime256v1 result -BEGIN RSA PRIVATE KEY- = Dumbo jacket Here is the result on trying to use each cipher on the list : $ openssl ciphers -v 'ALL:!SSLv2:!eNULL:!aNULL:!LOW:!EXPORT:!kECDH:!MD5:@STRENGTH' \ | while read C dumb; do echo -n # $C openssl s_client -connect 176.31.104.63:443 -cipher $C /dev/null /dev/null 21 \ echo OK \ || echo FAIL \ done \ | sort -k 3 \ | column -t # DHE-DSS-AES128-GCM-SHA256 FAIL # DHE-DSS-AES128-SHA256 FAIL # DHE-DSS-AES128-SHA FAIL # DHE-DSS-AES256-GCM-SHA384 FAIL # DHE-DSS-AES256-SHA256 FAIL # DHE-DSS-AES256-SHA FAIL # DHE-DSS-CAMELLIA128-SHAFAIL # DHE-DSS-CAMELLIA256-SHAFAIL # DHE-DSS-SEED-SHA FAIL # ECDHE-ECDSA-AES128-GCM-SHA256 FAIL # ECDHE-ECDSA-AES128-SHA256 FAIL # ECDHE-ECDSA-AES128-SHA FAIL # ECDHE-ECDSA-AES256-GCM-SHA384 FAIL # ECDHE-ECDSA-AES256-SHA384 FAIL # ECDHE-ECDSA-AES256-SHA FAIL # ECDHE-ECDSA-DES-CBC3-SHA FAIL # ECDHE-ECDSA-RC4-SHAFAIL # EDH-DSS-DES-CBC3-SHA FAIL # PSK-3DES-EDE-CBC-SHA FAIL # PSK-AES128-CBC-SHA FAIL # PSK-AES256-CBC-SHA FAIL # PSK-RC4-SHAFAIL # SRP-DSS-3DES-EDE-CBC-SHA FAIL # SRP-DSS-AES-128-CBC-SHAFAIL # SRP-DSS-AES-256-CBC-SHAFAIL # SRP-RSA-3DES-EDE-CBC-SHA FAIL # SRP-RSA-AES-128-CBC-SHAFAIL # SRP-RSA-AES-256-CBC-SHAFAIL # AES128-GCM-SHA256 OK # AES128-SHA256 OK # AES128-SHA OK # AES256-GCM-SHA384 OK # AES256-SHA256 OK # AES256-SHA OK # CAMELLIA128-SHAOK # CAMELLIA256-SHAOK # DES-CBC3-SHA OK # DHE-RSA-AES128-GCM-SHA256 OK # DHE-RSA-AES128-SHA256 OK # DHE-RSA-AES128-SHA OK # DHE-RSA-AES256-GCM-SHA384 OK # DHE-RSA-AES256-SHA256 OK # DHE-RSA-AES256-SHA OK # DHE-RSA-CAMELLIA128-SHAOK # DHE-RSA-CAMELLIA256-SHAOK # DHE-RSA-SEED-SHA OK # ECDHE-RSA-AES128-GCM-SHA256OK # ECDHE-RSA-AES128-SHA256OK # ECDHE-RSA-AES128-SHA OK # ECDHE-RSA-AES256-GCM-SHA384OK # ECDHE-RSA-AES256-SHA384OK # ECDHE-RSA-AES256-SHA OK # ECDHE-RSA-DES-CBC3-SHA OK # ECDHE-RSA-RC4-SHA OK # EDH-RSA-DES-CBC3-SHA OK # IDEA-CBC-SHA OK # RC4-SHAOK # SEED-SHA OK On the client (openssl s_client) it give : error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:741: --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE On the server : SSL handshake failure Also, while debugging haproxy v1.5-dev18-34-gf27af0d I can see that PEM_read_bio_DHparams() called in ssl_sock_load_dh_params() return the origin (in PEM file) DH parameter and that ssl_sock_load_dh_params() return 1. beber On 2013-04-19 20:53, Connelly, Zachary (CGI Federal) wrote: HAProxy list, I am currently working to implement SSL within HAProxy using the 1.5-dev18 version. Much like the thread started by Samat Galimov [1] on 2/5/2013, I am seeing the same behavior where the first time I send a request via SSL the request is serviced and everything is fine; the next time the same request is attempted I receive 'ERROR:Exception in request: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake.' I noticed the attached code in the thread was not put into the dev18 version (I believe). Did that code end up resolving the issue or is the issue still being reviewed? I can supply my config file if that would help. Is there any way to get more info out of HAProxy to see what it is doing while it handles the SSL Handshake (the log does not seem to write anything when the request fails)? Any assistance would be appreciated. Thanks, Zack Connelly Links: -- [1] http://search.gmane.org/?author=Samat#43;Galimovamp;sort=date
RE: Keeping LB pools status in sync
Hey Bryan, That's exactly what I want, thanks! Looks like usage of track is pretty straightforward too. Re: Davids response, port 6060 only returns an auth prompt and depends on the application on port 80 working. If something weird happens to the application on port 80 that auth prompt will still occur (and possibly accept valid credentials). Using track would allow me to guarantee that users will always been using a good node on both ports. -Ahmed From: Bryan Talbot [btal...@aeriagames.com] Sent: Friday, April 26, 2013 5:34 PM To: Ahmed Osman Cc: haproxy@formilux.org Subject: Re: Keeping LB pools status in sync It sounds like you're asking how to use a server's health state in one backend as the health state in another. If so you can use the track option on the servers backend pool1 server server1 1.1.1.1:6060http://1.1.1.1:6060 track pool2/server1 server server2 1.1.1.2:6060http://1.1.1.2:6060 track pool2/server2 backend pool2 server server1 1.1.1.1:80http://1.1.1.1:80 check server server2 1.1.1.2:80http://1.1.1.2:80 check Is that what you want? -Bryan On Fri, Apr 26, 2013 at 5:09 PM, Ahmed Osman aos...@tibco.commailto:aos...@tibco.com wrote: Hello Everyone, I’m wondering if anyone is able to tell me if this is default behavior or if I need to configure this. In a nutshell I have this setup: LB_Pool1 Server1:6060 Server2:6060 LB_Pool2 Server1:80 Server2:80 I can do a check pretty easily on LB_Pool2 however I don’t have a method for doing so on LB_Pool1. If something goes wrong with Server1 then the check in LB_Pool2 will detect it immediately and remove it from the pool until it’s back up. Will Server1 be removed from LB_Pool1 at the same time? And if not, how would I set it up so that happens? Ahmed Osman DevOps Engineer Infrastructure Support Services TIBCO Spotfire
