Re: About maxconn and minconn

[Baptiste]

Hi Dmitry,

It says what it says: you configured HAProxy to manage queue to
protect your servers. during your workload, a request remain in queue
for too long (1s) so HAProxy simply return an error.

Now the question is why such situation. Simply because your queue
management is improperly setup (either increase minconn and or
decrease fullconn) and combined to a server which might be quite slow
to answer leading HAProxy to use queues.

Or you met a bug :)

We need the full configuration and log lines around the sQ event
(right before and right after), so we may help.

Baptiste




On Wed, Oct 7, 2015 at 3:18 PM, Dmitry Sivachenko  wrote:
> Hello,
>
> I am using haproxy-1.5.14 and sometimes I see the following errors in the log:
>
> Oct  7 08:33:03 srv1 haproxy[77565]: unix:1 [07/Oct/2015:08:33:02.428] 
> MT-front MT_RU_EN-back/ 0/1000/-1/-1/1000 503 212 - - sQ-- 
> 125/124/108/0/0 0/28 "POST /some/url HTTP/1.1"
> (many similar at one moment)
>
> Common part in these errors is "1000" in Tw and Tt, and "sQ--" termination 
> state.
>
> Here is the relevant part on my config (I can post more if needed):
>
> defaults
> balance roundrobin
> maxconn 1
> timeout queue 1s
> fullconn 3000
> default-server inter 5s downinter 1s fastinter 500ms fall 3 rise 1 
> slowstart 60s maxqueue 1 minconn 5 maxconn 150
>
> backend MT_RU_EN-back
> mode http
> timeout server 30s
> server mt1-34 mt1-34:19016 track MT-back/mt1-34 weight 38
> server mt1-35 mt1-35:19016 track MT-back/mt1-35 weight 38
> 
>
> So this error log indicates that request was sitting in the queue for timeout 
> queue==1s and his turn did not come.
>
> In the stats web interface for MT_RU_EN-back backend I see the following 
> numbers:
>
> Sessions: limit=3000, max=126 (for the whole backend)
> Limit=150, max=5 or 6 (for each server)
>
> If I understand minconn/maxconn meaning right, each server should accept up 
> to min(150, 3000/18) connections
>
> So according to stats the load were far from limits.
>
> What can be the cause of such errors?
>
> Thanks!

Re: About maxconn and minconn

[Dmitry Sivachenko]

> On 7 окт. 2015 г., at 16:18, Dmitry Sivachenko  wrote:
> 
> Hello,
> 
> I am using haproxy-1.5.14 and sometimes I see the following errors in the log:
> 
> Oct  7 08:33:03 srv1 haproxy[77565]: unix:1 [07/Oct/2015:08:33:02.428] 
> MT-front MT_RU_EN-back/ 0/1000/-1/-1/1000 503 212 - - sQ-- 
> 125/124/108/0/0 0/28 "POST /some/url HTTP/1.1"
> (many similar at one moment)
> 
> Common part in these errors is "1000" in Tw and Tt, and "sQ--" termination 
> state.
> 
> Here is the relevant part on my config (I can post more if needed):
> 
> defaults
>balance roundrobin
>maxconn 1
>timeout queue 1s
>fullconn 3000
>default-server inter 5s downinter 1s fastinter 500ms fall 3 rise 1 
> slowstart 60s maxqueue 1 minconn 5 maxconn 150
> 
> backend MT_RU_EN-back
>mode http
>timeout server 30s
>server mt1-34 mt1-34:19016 track MT-back/mt1-34 weight 38
>server mt1-35 mt1-35:19016 track MT-back/mt1-35 weight 38
>
> 
> So this error log indicates that request was sitting in the queue for timeout 
> queue==1s and his turn did not come.
> 
> In the stats web interface for MT_RU_EN-back backend I see the following 
> numbers:
> 
> Sessions: limit=3000, max=126 (for the whole backend)
> Limit=150, max=5 or 6 (for each server)


I also forgot to mention the "Queue" values from stats web-interface:
Queue max = 0 for all servers
Queue limit = 1 for all servers (as configured in default-server)
So according to stats queue was never used.


Right under the servers list, there is a "Backend" line, which has the value of 
"29" in "Queue Max" column.
What does it mean?


> 
> If I understand minconn/maxconn meaning right, each server should accept up 
> to min(150, 3000/18) connections
> 
> So according to stats the load were far from limits.
> 
> What can be the cause of such errors?
> 
> Thanks!

Re: Try request again if response body is empty?

[Joseph Lynch]

Hi Shawn,

I am pretty sure that HAProxy cannot retry requests themselves because
it does not know what side effects the request had. It can retry
connections but once the session is assigned it returns results or
fails.

See Willy's response for some more detail:
http://marc.info/?l=haproxy=141225667313851=2 (you can also search
the mailing list archives and this has come up a lot).

Good luck finding the bug!
-Joey

On Wed, Oct 7, 2015 at 1:44 PM, Shawn Heisey  wrote:
> Before I get started with this, I know and acknowledge that the problem
> I'm trying to solve is not in haproxy.  I suspect that haproxy cannot do
> what I'm going to ask, but I was asked if it could do it, so I am
> passing the question along to make sure.
>
> We are having a problem with our Liferay webapp (running in tomcat,
> fronted by apache) where it sometimes returns a completely blank page.
> If the user refreshes, it works.  Near as I can tell, when this problem
> happens, the response that haproxy gets from Apache only contains
> headers, the body is empty.
>
> Can haproxy be configured to retry the request if it gets an empty
> response body from the server?
>
> Thanks,
> Shawn
>

TCP compression

[Kadir SALKI]

hi ,

I develop an app so I need compress the data but haproxy support http
compress I need tcp compress . Can you help me about this ,
thanks.

[PATCH] MINOR: http: Add OPTIONS in supported http methods (found by, find_http_meth)

[Christopher Faulet]

Hi,

The 'OPTIONS' method was not in the list of supported HTTP methods and 
find_http_meth return HTTP_METH_OTHER instead of HTTP_METH_OPTIONS.


Regards
--
Christopher Faulet
>From ec4669273b06bee074389baa2d00ef0202dbea1c Mon Sep 17 00:00:00 2001
From: Christopher Faulet 
Date: Fri, 31 Jul 2015 14:26:57 +0200
Subject: [PATCH] MINOR: http: Add OPTIONS in supported http methods (found by
 find_http_meth)

---
 src/proto_http.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/proto_http.c b/src/proto_http.c
index 6d4a6b3..32b9063 100644
--- a/src/proto_http.c
+++ b/src/proto_http.c
@@ -458,6 +458,9 @@ const struct http_method_desc http_methods[26][3] = {
 	['H' - 'A'] = {
 		[0] = {	.meth = HTTP_METH_HEAD, .len=4, .text="HEAD"},
 	},
+	['O' - 'A'] = {
+		[0] = {	.meth = HTTP_METH_OPTIONS , .len=7, .text="OPTIONS" },
+	},
 	['P' - 'A'] = {
 		[0] = {	.meth = HTTP_METH_POST, .len=4, .text="POST"},
 		[1] = {	.meth = HTTP_METH_PUT , .len=3, .text="PUT" },
-- 
2.4.3

Re: About maxconn and minconn

[Dmitry Sivachenko]

> On 8 окт. 2015 г., at 11:03, Baptiste  wrote:
> 
> Hi Dmitry,
> 
> 
> 
> Now the question is why such situation. Simply because your queue
> management is improperly setup (either increase minconn and or
> decrease fullconn) and combined to a server which might be quite slow
> to answer leading HAProxy to use queues.
> 

What do you mean "improperly setup"?  From the stats I provided I got an 
impression that no limits were reached for request to get into the waiting 
queue.

Or am I wrong?

(I will send you full config and logs in private soon)

Re: NOSRV error

[Juriy Strashnov]

Maybe

*option tcpka *
*option httpclose*

can help.

We've got similar behaviour with HAProxy LBs running inside OpenStack
Private Cloud. Lots of 503/ while backend servers are actually
working.

On Mon, Oct 5, 2015 at 6:43 PM, Baptiste  wrote:

> On Mon, Oct 5, 2015 at 5:24 PM, Kevin COUSIN 
> wrote:
> > Hi,
> >
> > - Mail original -
> >> De: "Conrad Hoffmann" 
> >> À: "Kevin COUSIN" , haproxy@formilux.org
> >> Envoyé: Lundi 5 Octobre 2015 15:49:36
> >> Objet: Re: NOSRV error
> >
> >> Hi,
> >>
> >> (comments inline)
> >>
> >> On 10/05/2015 03:23 PM, Kevin COUSIN wrote:
> >>> Hi list
> >>>
> >>
> >> This usually means that there is no server in the backend because they
> were
> >> either misconfigured or taken out of the rotation, e.g. due to failed
> >> health checks.
> >>
> >
> > We disabled server tests to debug.
>
> Kevin, bear in mind that checks are never the problem, but they are
> the solution ;)
>
>
> >>
> >> Not sure what exactly you want to achieve here. If you want to
> loadbalance
> >> on TCP level, HAProxy doesn't need to know anything about any TLS
> parameters.
> >
> >
> > It's a lab HAproxy instance, the ssl ciphers options are for some other
> Layer 7 LB configuration.
> > 43
> >>>
> >>> I got the certificate on my server If I use openssl s_client.
> >>
> >> Can you elaborate on this? Are you connecting with s_client to haproxy
> or
> >> to your server?
> >> Can you confirm that you want you web server to do the actual TLS
> handshake
> >> and not HAProxy?
> >
> > I'm connecting to my server with openssl, from the haproxy (to check if
> SSL certificate is installed on the target).
> >
> > Yes, we want the backend server to do the TLS handshake.
> >
> > We try to LB the Citrix Broker :
> >
> > User -> Citrix Netscaler Gateway -> HAproxy --> Citrix
> Brokers
> >
> > We used the Windows NLB between Citrix NS Gateway and Citrix Brokers and
> we want to replace it with HAproxy.
> > With the HTTP frontend, we can see "HTTP/XML 479 POST
> /Scripts/CtxSTA.dll HTTP/1.1". It doesn't work with HTTPS, the Netscaler
> gateway seems to close the connection with FIN,ACK.
>
>
> Why mixing HAProxy between citrix products?
>
> As Conrad said, there are servers available for your connection. you
> should investigate first why the citrix brokers reject the traffic.
>
> Baptiste
>
>


-- 
Best regards, Juriy Strashnov

Please consider the environment before printing this email.

Re: About maxconn and minconn

[Daren Sefcik]

How about kern.ipc.somaxconn

On Thu, Oct 8, 2015 at 5:22 AM, Dmitry Sivachenko 
wrote:

>
> > On 8 окт. 2015 г., at 3:51, Igor Cicimov 
> wrote:
> >
> >
> > The only thing I can think of is you have left net.core.somaxconn = 128,
> try increasing it to 4096 lets say to match your planned capacity of 3000
> >
>
>
> I forgot to mention that I am using FreeBSD, I don't think it has similar
> sysctl.
>

Re: About maxconn and minconn

[Dmitry Sivachenko]

> On 8 окт. 2015 г., at 3:51, Igor Cicimov  
> wrote:
> 
> 
> The only thing I can think of is you have left net.core.somaxconn = 128, try 
> increasing it to 4096 lets say to match your planned capacity of 3000
> 


I forgot to mention that I am using FreeBSD, I don't think it has similar 
sysctl.

Re: About maxconn and minconn

[Dmitry Sivachenko]

> On 8 окт. 2015 г., at 15:30, Daren Sefcik  wrote:
> 
> How about kern.ipc.somaxconn


I have this set to 4096, and when it overflows it prints a line in the log 
(Listen queue overflow...)

I have no these errors in logs.

Moreover, connections sitting in socket accept queue are not seen by haproxy 
and haproxy can't count this time and trigger timeouts.



> 
> On Thu, Oct 8, 2015 at 5:22 AM, Dmitry Sivachenko  wrote:
> 
> > On 8 окт. 2015 г., at 3:51, Igor Cicimov  
> > wrote:
> >
> >
> > The only thing I can think of is you have left net.core.somaxconn = 128, 
> > try increasing it to 4096 lets say to match your planned capacity of 3000
> >
> 
> 
> I forgot to mention that I am using FreeBSD, I don't think it has similar 
> sysctl.
> 

Minor SSL fixes

[Christopher Faulet]

Hi,

Here are some SSL fixes. The last one is a fix to a bug reported in a 
previous thread[1].


[1] https://www.mail-archive.com/haproxy@formilux.org/msg19243.html

Regards,
--
Christopher Faulet
>From 4994166ef6be91e768607c67e431d5fc20fbde1e Mon Sep 17 00:00:00 2001
From: Christopher Faulet 
Date: Tue, 28 Jul 2015 16:03:47 +0200
Subject: [PATCH 1/3] BUG/MINOR: ssl: fix management of the cache where forged
 certificates are stored

First, the LRU cache must be initialized after the configuration parsing to
correctly set its size.
Next, the function 'ssl_sock_set_generated_cert' returns -1 when an error occurs
(0 if success). In that case, the caller is responsible to free the memory
allocated for the certificate.
Finally, when a SSL certificate is generated by HAProxy but cannot be inserted
in the cache, it must be freed when the SSL connection is closed. This happens
when 'tune.ssl.ssl-ctx-cache-size' is set to 0.
---
 include/proto/ssl_sock.h |  2 +-
 src/ssl_sock.c   | 38 --
 2 files changed, 21 insertions(+), 19 deletions(-)

diff --git a/include/proto/ssl_sock.h b/include/proto/ssl_sock.h
index c2156bb..1b6c081 100644
--- a/include/proto/ssl_sock.h
+++ b/include/proto/ssl_sock.h
@@ -72,7 +72,7 @@ int ssl_sock_load_global_dh_param_from_file(const char *filename);
 
 SSL_CTX *ssl_sock_create_cert(const char *servername, unsigned int serial, X509 *cacert, EVP_PKEY *capkey);
 SSL_CTX *ssl_sock_get_generated_cert(unsigned int serial, X509 *cacert);
-void ssl_sock_set_generated_cert(SSL_CTX *ctx, unsigned int serial, X509 *cacert);
+int ssl_sock_set_generated_cert(SSL_CTX *ctx, unsigned int serial, X509 *cacert);
 unsigned int ssl_sock_generated_cert_serial(const void *data, size_t len);
 
 #endif /* _PROTO_SSL_SOCK_H */
diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index 401ff67..deb658e 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -1127,8 +1127,9 @@ ssl_sock_get_generated_cert(unsigned int serial, X509 *cacert)
 	return NULL;
 }
 
-/* Set a certificate int the LRU cache used to store generated certificate. */
-void
+/* Set a certificate int the LRU cache used to store generated
+ * certificate. Return 0 on success, otherwise -1 */
+int
 ssl_sock_set_generated_cert(SSL_CTX *ssl_ctx, unsigned int serial, X509 *cacert)
 {
 	struct lru64 *lru = NULL;
@@ -1136,11 +1137,13 @@ ssl_sock_set_generated_cert(SSL_CTX *ssl_ctx, unsigned int serial, X509 *cacert)
 	if (ssl_ctx_lru_tree) {
 		lru = lru64_get(serial, ssl_ctx_lru_tree, cacert, 0);
 		if (!lru)
-			return;
+			return -1;
 		if (lru->domain && lru->data)
 			lru->free((SSL_CTX *)lru->data);
 		lru64_commit(lru, ssl_ctx, cacert, 0, (void (*)(void *))SSL_CTX_free);
+		return 0;
 	}
+	return -1;
 }
 
 /* Compute the serial that will be used to create/set/get a certificate. */
@@ -1164,13 +1167,13 @@ ssl_sock_generate_certificate(const char *servername, struct bind_conf *bind_con
 		lru = lru64_get(serial, ssl_ctx_lru_tree, cacert, 0);
 		if (lru && lru->domain)
 			ssl_ctx = (SSL_CTX *)lru->data;
-	}
-
-	if (!ssl_ctx) {
-		ssl_ctx = ssl_sock_create_cert(servername, serial, cacert, capkey);
-		if (lru)
+		if (!ssl_ctx && lru) {
+			ssl_ctx = ssl_sock_create_cert(servername, serial, cacert, capkey);
 			lru64_commit(lru, ssl_ctx, cacert, 0, (void (*)(void *))SSL_CTX_free);
+		}
 	}
+	else
+		ssl_ctx = ssl_sock_create_cert(servername, serial, cacert, capkey);
 	return ssl_ctx;
 }
 
@@ -2489,6 +2492,10 @@ ssl_sock_load_ca(struct bind_conf *bind_conf, struct proxy *px)
 	if (!bind_conf || !bind_conf->generate_certs)
 		return err;
 
+	if (global.tune.ssl_ctx_cache)
+		ssl_ctx_lru_tree = lru64_new(global.tune.ssl_ctx_cache);
+	ssl_ctx_lru_seed = (unsigned int)time(NULL);
+
 	if (!bind_conf->ca_sign_file) {
 		Alert("Proxy '%s': cannot enable certificate generation, "
 		  "no CA certificate File configured at [%s:%d].\n",
@@ -2838,7 +2845,6 @@ int ssl_sock_handshake(struct connection *conn, unsigned int flag)
 	}
 
 reneg_ok:
-
 	/* Handshake succeeded */
 	if (!SSL_session_reused(conn->xprt_ctx)) {
 		if (objt_server(conn->target)) {
@@ -3082,6 +3088,11 @@ static int ssl_sock_from_buf(struct connection *conn, struct buffer *buf, int fl
 static void ssl_sock_close(struct connection *conn) {
 
 	if (conn->xprt_ctx) {
+		if (!ssl_ctx_lru_tree && objt_listener(conn->target)) {
+			SSL_CTX *ctx = SSL_get_SSL_CTX(conn->xprt_ctx);
+			if (ctx != objt_listener(conn->target)->bind_conf->default_ctx)
+SSL_CTX_free(ctx);
+		}
 		SSL_free(conn->xprt_ctx);
 		conn->xprt_ctx = NULL;
 		sslconns--;
@@ -5344,21 +5355,12 @@ static void __ssl_sock_init(void)
 #ifndef OPENSSL_NO_DH
 	ssl_dh_ptr_index = SSL_CTX_get_ex_new_index(0, NULL, NULL, NULL, NULL);
 #endif
-
-#ifdef SSL_CTRL_SET_TLSEXT_HOSTNAME
-	/* Add a global parameter for the LRU cache size */
-	if (global.tune.ssl_ctx_cache)
-		ssl_ctx_lru_tree = lru64_new(global.tune.ssl_ctx_cache);
-	ssl_ctx_lru_seed = (unsigned int)time(NULL);
-#endif
 }
 

RE: req_ssl_ver ACL not working

[Julien Vehent]

On 2015-10-05 17:03, Lukas Tribus wrote:

I would argue that HAProxy is doing the wrong thing here: the
req_ssl_ver variable
should return the handshake version, not the record layer version.


Agreed.


We really should ignore the record layer and use the client hello
version instead (smp_fetch_ssl_hello_sni() has code checking for both
if anyone has time to come up with a patch for req_ssl_ver).


Attached is a patch that should work but doesn't. (bare with me, I'm in 
unknown codebase territory here).


I also tried to match directly using req.payload, and I can't get the 
ACL to match:

acl tls12 req.payload(9,2) -m bin 0303
acl tls12 req.payload(10,2) -m bin 0303
acl tls12 req.payload(11,1) -m bin 03

None of the above work. Any thoughts?

- JulienFrom a92b78ebc52b855284c177f67c081508c843f1fb Mon Sep 17 00:00:00 2001
From: Julien Vehent 
Date: Thu, 8 Oct 2015 09:53:12 -0400
Subject: [PATCH] BUG/MINOR: use SSL handshake instead of record layer when
 checking version

---
 src/payload.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/payload.c b/src/payload.c
index f62163c..4700f3c 100644
--- a/src/payload.c
+++ b/src/payload.c
@@ -148,10 +148,10 @@ smp_fetch_req_ssl_ver(struct proxy *px, struct session *s, void *l7, unsigned in
 	data = (const unsigned char *)s->req->buf->p;
 	if ((*data >= 0x14 && *data <= 0x17) || (*data == 0xFF)) {
 		/* SSLv3 header format */
-		if (bleft < 5)
+		if (bleft < 11)
 			goto too_short;
 
-		version = (data[1] << 16) + data[2]; /* version: major, minor */
+		version = (data[9] << 16) + data[10]; /* version: major, minor */
 		msg_len = (data[3] <<  8) + data[4]; /* record length */
 
 		/* format introduced with SSLv3 */
@@ -162,7 +162,7 @@ smp_fetch_req_ssl_ver(struct proxy *px, struct session *s, void *l7, unsigned in
 		if (msg_len < 1 || msg_len > ((1<<14) + 2048))
 			goto not_ssl;
 
-		bleft -= 5; data += 5;
+		bleft -= 11; data += 11;
 	} else {
 		/* SSLv2 header format, only supported for hello (msg type 1) */
 		int rlen, plen, cilen, silen, chlen;
-- 
2.5.3

Re: Proposed patch to allow for /etc/sysconfig/haproxy settings in RHEL pre systemd versions

[Pavlos Parissis]

On 07/10/2015 11:35 πμ, Joakim Fallsjö wrote:
> Hi,
> 
> please consider this modifications to the rc.d/init.d script used by the 
> RPM-spec file for Redhat/Centos versions prior to systemd.
> 
> The patch modifies the init script to allow for out of RPM package
> modifications that can persist across RPM updates, while still being
> compatible to older versions of the init-script.
> 
> 
> 
> 
> 
> 
> /JockeF
> 

This will allow someone to do:
% cat /etc/default/hapee-lb
export HOSTNAME=foo.bar.com
%
% grep HOSTANAME /etc/hapee/hapee-lb.cfg
http-response set-header X-Lb-Node %[env(HOSTNAME)]


May I suggest to use /etc/default rather /etc/sysconfig, as the former
will work all Linux distributions.

Cheers,
Pavlos



signature.asc
Description: OpenPGP digital signature

RE: req_ssl_ver ACL not working

[Lukas Tribus]

> Attached is a patch that should work but doesn't. (bare with me, I'm in
> unknown codebase territory here).
>
> I also tried to match directly using req.payload, and I can't get the
> ACL to match:
> acl tls12 req.payload(9,2) -m bin 0303

"req.payload(9,2) -m bin 0303" is imho correct, this should work.
You did configure inspect-delay [1], right? Something like:
tcp-request inspect-delay 2s


Regards,

Lukas

[1] 
http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#4.2-tcp-request%20inspect-delay

  

HA-Proxy IP ranges for acl

[Sébastien LECOMTE]

Hi!

I'd like to report a bug I do experience,
maybe I'm not the first one to report it:
it's about IP network ranges and acl in haproxy (1.5.8).
It's working… sometimes.
I have no issue with ranges like /24 (like 10.10.200.0/24)
But it is not working with a range like /22 ; /28 ; /27 or /25.

For example without any ACL,
this IP will reach backend : 213.254.248.97

But with the range 213.254.248.96/27 with acl, it is rejected (#403).
At this time acl are working fine with single IPs.
And this IP adress (213.254.248.97) *should be* authorized by
the 213.254.248.96/27 range, right ?
  (Min:   213.254.248.97)
  (Max:   213.254.248.126)

Is there any hope that this is my fault, or that it could be corrected?

Thanks anyway and sorry it's bothersome.

-- 
Seb

RE: req_ssl_ver ACL not working

[Julien Vehent]

On 2015-10-08 11:28, Lukas Tribus wrote:
Attached is a patch that should work but doesn't. (bare with me, I'm 
in

unknown codebase territory here).

I also tried to match directly using req.payload, and I can't get the
ACL to match:
acl tls12 req.payload(9,2) -m bin 0303


"req.payload(9,2) -m bin 0303" is imho correct, this should work.
You did configure inspect-delay [1], right? Something like:
tcp-request inspect-delay 2s



I did. Here's the conf sample. The sslv3 acl works, not the tls12 one.

frontend https-in
bind 0.0.0.0:443
mode tcp
tcp-request inspect-delay 5s
tcp-request content accept if { req_ssl_hello_type 1 }

acl sni_jve req.ssl_sni -i jve.linuxwall.info
acl tls12 req.payload(9,2) -m bin 0301
acl sslv3 req_ssl_ver 3.0

use_backend jve_https if sni_jve tls12
use_backend jve_https_sha1_ssl3 if sslv3
# fallback to backward compatible sha1
default_backend jve_https_sha1

Could you (or someone else) test it and verify my results?

- Julien

RE: req_ssl_ver ACL not working

[Julien Vehent]

On 2015-10-08 12:05, Julien Vehent wrote:

acl tls12 req.payload(9,2) -m bin 0301


Oops... typo while copy/pasting my conf. The right config is below:

frontend https-in
bind 0.0.0.0:443
mode tcp
tcp-request inspect-delay 5s
tcp-request content accept if { req_ssl_hello_type 1 }

acl sni_jve req.ssl_sni -i jve.linuxwall.info
acl tls12 req.payload(9,2) -m bin 0303
acl sslv3 req_ssl_ver 3.0

use_backend jve_https if sni_jve tls12
use_backend jve_https_sha1_ssl3 if sslv3
# fallback to backward compatible sha1
default_backend jve_https_sha1


- Julien

RE: req_ssl_ver ACL not working

[Lukas Tribus]

> frontend https-in
> bind 0.0.0.0:443
> mode tcp
> tcp-request inspect-delay 5s
> tcp-request content accept if { req_ssl_hello_type 1 }
>
> acl sni_jve req.ssl_sni -i jve.linuxwall.info
> acl tls12 req.payload(9,2) -m bin 0303
> acl sslv3 req_ssl_ver 3.0
>
> use_backend jve_https if sni_jve tls12
> use_backend jve_https_sha1_ssl3 if sslv3
> # fallback to backward compatible sha1
> default_backend jve_https_sha1

Are you sure your TLSv1.2 client is actually sending
jve.linuxwall.info as SNI value? I suggest to remove the
SNI if statement while testing the TLS ACL.

The ACL works fine for me:

frontend https-in
 bind 10.0.0.55:443
 mode tcp
 tcp-request inspect-delay 5s
 tcp-request content accept if { req_ssl_hello_type 1 }
 
 acl tls12 req.payload(9,2) -m bin 0303
 use_backend google if tls12
 
 default_backend microsoft

backend google
 server google google.com:443

backend microsoft
 server hotmail microsoft.com:443


"curl -k -v https://10.0.0.55 --tlsv1.2" --> connects to Google
"curl -k -v https://10.0.0.55 --tlsv1.1" --> connects to MS



  

welded mesh panel

[Anna]

We are the manufacturer of welded wire mesh.

1. for construction and building material  :

to be used for coal mine tunnel protection ,tunnel liner ,house floor , 
roof, reinforce the concrete and brick for the wall,bridge,road,for fence

  1)Weded wire mesh panel fence: to fence the road,house,railway,runway and so 
on

  2)Brick block reinforcement ladder mesh/truss
  
  3)Underground coal mine supporting net 

  4)Stucco welded wire mesh:Also called stucco welded wire lath, estazolam 
plate net,external wall insulation welded wire mesh.
  
 A new wall building material,can 
instead of the brick to be the load bearing wall,floor,balcony.
  
  5)Floor warming mesh, radiant floor heating mesh

  6)Gabion mesh

2. other usage

  1)Corn welded wire mesh

  2)Seeding bed mesh:also called flower breeding growing mesh,greenhouse 
seeding bed net


If you import,then welcome your inquiry. 

-
 
Best Regards

Anna

Shenzhou Sirun Wire Mesh Products Co. Ltd.
　　
Mobile: 15333187692   Tel: 0318-3608999 Fax: 0318-3601999

Skype:weldedwirenetting

Address: Shenzhou City Song Jia Ying Industrial Park,Hengshui,Hebei,China

www.chinaweldedmeshfence.comwww.sirunwangye.com

RE: HA-Proxy IP ranges for acl

[Lukas Tribus]

> Hi!
>
> I'd like to report a bug I do experience,
> maybe I'm not the first one to report it:
> it's about IP network ranges and acl in haproxy (1.5.8).
> It's working… sometimes.
> I have no issue with ranges like /24 (like 10.10.200.0/24)
> But it is not working with a range like /22 ; /28 ; /27 or /25.
>
> For example without any ACL,
> this IP will reach backend : 213.254.248.97
>
> But with the range 213.254.248.96/27 with acl, it is rejected (#403).
> At this time acl are working fine with single IPs.
> And this IP adress (213.254.248.97) *should be* authorized by
> the 213.254.248.96/27 range, right?

You really need to post the actual configuration, because we don't
have any idea what you are trying to do and how you configured it.

But yes, 213.254.248.96/27 covers 32 IPs starting from 213.254.248.96
until 213.254.248.127.


Lukas

  

Re: About maxconn and minconn

[Igor Cicimov]

On Thu, Oct 8, 2015 at 7:15 PM, Dmitry Sivachenko 
wrote:

>
> > On 7 окт. 2015 г., at 16:18, Dmitry Sivachenko 
> wrote:
> >
> > Hello,
> >
> > I am using haproxy-1.5.14 and sometimes I see the following errors in
> the log:
> >
> > Oct  7 08:33:03 srv1 haproxy[77565]: unix:1 [07/Oct/2015:08:33:02.428]
> MT-front MT_RU_EN-back/ 0/1000/-1/-1/1000 503 212 - - sQ--
> 125/124/108/0/0 0/28 "POST /some/url HTTP/1.1"
> > (many similar at one moment)
> >
> > Common part in these errors is "1000" in Tw and Tt, and "sQ--"
> termination state.
> >
> > Here is the relevant part on my config (I can post more if needed):
> >
> > defaults
> >balance roundrobin
> >maxconn 1
> >timeout queue 1s
> >fullconn 3000
> >default-server inter 5s downinter 1s fastinter 500ms fall 3 rise 1
> slowstart 60s maxqueue 1 minconn 5 maxconn 150
> >
> > backend MT_RU_EN-back
> >mode http
> >timeout server 30s
> >server mt1-34 mt1-34:19016 track MT-back/mt1-34 weight 38
> >server mt1-35 mt1-35:19016 track MT-back/mt1-35 weight 38
> >
> >
> > So this error log indicates that request was sitting in the queue for
> timeout queue==1s and his turn did not come.
> >
> > In the stats web interface for MT_RU_EN-back backend I see the following
> numbers:
> >
> > Sessions: limit=3000, max=126 (for the whole backend)
> > Limit=150, max=5 or 6 (for each server)
>
>
> I also forgot to mention the "Queue" values from stats web-interface:
> Queue max = 0 for all servers
> Queue limit = 1 for all servers (as configured in default-server)
> So according to stats queue was never used.
>
>
> Right under the servers list, there is a "Backend" line, which has the
> value of "29" in "Queue Max" column.
> What does it mean?
>
>
Well that means you had up to 29 requests in the backend queue waiting for
connection. In my case I have never seen this queue be more then 0 on the
backend or any of the backend servers for that matter. Also the queue limit
per server is 128 not 1 (I think you confuse queue limit with queue timeout
which you have set to 1 sec indeed).

So, as mentioned before, and pointed by Baptiste, your servers are not that
fast as you expect them to be, ie you have set your queues size and timeout
too low. First, is haproxy on the same LAN segment as the backend servers?
For example what is the value of the LastChk column, it should be ms
(milliseconds) if your servers are close to haproxy and not under big load.

If I were in your shoes I would:

- drop the fullconn setting and let haproxy do the math for me
- definitely increase the queue timeout to more than 1 sec (why would you
risk loosing messages, except if you are short on ram)
- set connect timeout as per the excerpt I sent previously

and see how I go.


>
> >
> > If I understand minconn/maxconn meaning right, each server should accept
> up to min(150, 3000/18) connections
> >
> > So according to stats the load were far from limits.
> >
> > What can be the cause of such errors?
> >
> > Thanks!
>
>
>

Re: New SMD flood light from Asia Boslin.

[lauren]

 Tothosewhoconcernon 
Gooddays!ThisisLaurenfromAsiaBoslin(=www.simaoled.com),whichisfactoryforLEDproducts.MainproductisLEDfloodlight,LEDstreetlight,LEDpanellighte=tc...NowwehavepromotionfornewitemSMD5630floodlight.Seeifyouwillbeinterestedinalso.Welcometoaskfordetails.
  Waitingforyourcomments. BestRegardsThanksLauren Ng
Asia-BOSLIN=OptoelectronicsSciTechGroupCo.,LTD  
Mobile+8613425113530(whatsapp/Viber)Skype:simaoled39Email:lau...@simaoled.com&=nbsp;Web:=www.simaoled.com
 Address:TaiHeRongIndustria=lBldgA.LiaoKeng.Shiyan,Shenzhen,China

redirect prefix in v1.5.14 and v1.4.22

[Diana Hsu (ditsai)]

Hello,

I have two hosts, one has haproxy 1.4.22 installed and the other has haproxy 
1.5.14 installed.
The following rewrite config works as expected in 1.5.14, but not in v1.4.22:

1.5.14

frontend HTTP-IN

bind 10.10.10.1:8080

acl URL-REWRITE path_beg /test

reqirep ^([^\ ]*)\ /test/(.*)\1\ /xyz/\2

redirect prefix / code 301 if URL-REWRITE

1.4.22

listen HTTP-IN 10.10.10.2:8080

acl URL-REWRITE path_beg /test

reqirep ^([^\ ]*)\ /test/(.*)\1\ /xyz/\2

redirect prefix / code 301 if URL-REWRITE


If I access http://10.10.10.1:8080/test/mytest.jsp  it returns 
http://10.10.10.1:8080/xyz/mytest.jsp
If I access http://10.10.10.2:8080/test/mytest.jsp  it returns same url 
http://10.10.10.2:8080/test/mytest.jsp

Seems to me "redirect prefix" in 1.4.22 has no effect at all?  Is this a known 
behavior in 1.4.22?  Since the version is too old, I can't get much info from 
googling.

Thanks and Regards,
Diana

RE: redirect prefix in v1.5.14 and v1.4.22

[Lukas Tribus]

Hi Diana,


> Hello, 
>  
> I have two hosts, one has haproxy 1.4.22 installed and the other has  
> haproxy 1.5.14 installed. 
> The following rewrite config works as expected in 1.5.14, but not in v1.4.22:

You probably want to check whether both 1.4.22 and 1.5.14 executables
have been build with PCRE.

Compare "haproxy -vv" output for this.

I think maybe the 1.4.22 has been compiled without PCRE. What then
happens is that haproxy falls back to the libc's regex engine, which may
not support the syntax you are using.



Regards,

Lukas