redirect prefix in v1.5.14 and v1.4.22
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
invalid chars in header name
Hi,
I would like to validate a statement in option accept-invalid-http-request
section:
http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#option%20accept-invalid-http-request
By default, HAProxy complies with RFC2616 in terms of message parsing. This
means that invalid characters in header names are not permitted and cause an
error to be returned to the client. This is the desired behaviour as such
forbidden characters are essentially used to build attacks exploiting server
weaknesses, and bypass security filtering. Sometimes, a buggy browser or
server will emit invalid header names for whatever reason (configuration,
implementation) and the issue will not be immediately fixed. In such a case,
it is possible to relax HAProxy's header name parser to accept any character
even if that does not make sense, by specifying this option. Similarly, the
list of characters allowed to appear in a URI is well defined by RFC3986, and
chars 0-31, 32 (space), 34 (''), 60 (''), 62 (''), 92 ('\'), 94 ('^'), 96
('`'), 123 ('{'), 124 ('|'), 125 ('}'), 127 (delete) and anything above are
not allowed at all. Haproxy always blocks a number of them (0..32, 127). The
remaining ones are blocked by default unless this option is enabled.
What does it mean by HAProxy always blocks a number of them (0..32, 127).?
Does it mean HAProxy will not block the request with invalid char (0..32, 127)
in the header name all the time? Does HAProxy randomly block the bad request
with invalid char (0..32, 127) in the header name?
We have an application receiving Bad Request 400 and the tcpdump shows an
invalid char %20 (space) in some of the header names.
However, application owner claimed sometimes these requests were not blocked by
HAProxy and went through without Bad Request 400 error.
Please advise.
Thanks
Diana
maxconn question
Hi, In our HAProxy, we have maxconn defined in both global and defaults sections, and there are total 5 frontend listeners configured: global maxconn 10240 … defaults mode http maxconn 5000 …. frontend FE-1 … frontend FE-2 … frontend FE-3 … frontend FE-4 … frontend FE-5 Among these frontend listeners, only FE-1 and FE-2 are heavy-traffic, the other 3 are very light-traffic. Do you see any potential performance issue on FE-1 and FE-2 with maxconn=5000 defined in defaults section? Thanks Diana
Re: HAProxy equivalent to ProxyPreserveHost off
Hi Willy, We are migrating applications from siteA to siteB, the technology used to run the applications is different in these 2 sites. All the applications in siteA share the same domain sitea.sample.com, but each application has its unique uri (ex: /proxy1, /proxy2, /proxy3 ..). We want to migrate applications in siteA to start using new technology that is offered in siteB, however migrated applications need to keep existing domain name sitea.sample.com. siteB is managed by the different group and we have no privilege to change siteB's configuration. Each application provisioned in siteB is configured to have its own vanity name (ex: abc.sample.com, xyz.sample.com, ..) which is the CNAME(alias) of siteb.sample.com. siteB's HAProxy uses Host header matching to route the requests to the proper backend application servers, for example: acl ABC hdr_dom(host) -i abc.sample.com use_backend SFARM-ABC if ABC How can we configure in siteA's HAProxy to meet above requirement? Should we configure HAProxy as reverse-proxy in siteA? Thanks, Diana From: Willy Tarreau w...@1wt.eumailto:w...@1wt.eu Date: Saturday, September 6, 2014 12:48 AM To: Microsoft Office User dit...@cisco.commailto:dit...@cisco.com Cc: haproxy@formilux.orgmailto:haproxy@formilux.org haproxy@formilux.orgmailto:haproxy@formilux.org Subject: Re: HAProxy equivalent to ProxyPreserveHost off Hi Diana, On Sat, Sep 06, 2014 at 02:37:21AM +, Diana Hsu (ditsai) wrote: Hi, Is there a HAProxy setting equivalent to apache's ProxyPreserveHost ? I want to proxy the request from siteA to siteB , both sites have HAProxy service configured: siteA: sitea.sample.com backend SFARM-PROXY1 server PROXY1 abc.sample.com:80 backend SFARM-PROXY2 server PROXY2 xyz.sample.com:80 acl PROXY1 path_reg ^/proxy1$|^/proxy1/ use_backend SFARM-PROXY1 if PROXY1 acl PROXY2 path_reg ^/proxy2$|^/proxy2/ use_backend SFARM-PROXY2 if PROXY2 siteB: siteb.sample.com (it has many CNAMEs created, including abc.sample.com, xyz.sample.com, ?etc) acl ABC hdr_dom(host) -i abc.sample.com use_backend SFARM-ABC if ABC acl XYZ hdr_dom(host) -i xyz.sample.com use_backend SFARM-XYZ if XYZ acl ?... When I access http://sitea.sample.com/proxy1 , the browser throws 502 Gateway Error and siteB haproxy.log shows 503 Service Not Available. The reason is that Host header contains sitea.sample.com when it reaches siteB and there is no acl matched. I tried using rewrite rule on Host header in siteA config: backend SFARM-PROXY1 reqirep ^Host: Host:\ abc.sample.com server PROXY1 abc.sample.com:80 It didn't work because accessing http://sitea.sample.com/proxy1 returned http://abc.sample.com/proxy1http://sitea.sample.com/proxy1 in the browser. We want browser to stay on sitea.sample.com and not change to abc.sample.com. It's not clear to me, I think you're confusing two concepts : - request routing - request rewriting. What I understand above is that you want haproxy to rewrite the Host request header, and you forgot to rewrite the Location response header. Please note: rewriting a Host header is a very dirty thing to do which is always unreliable, especially when you don't know all the exact details of the application behind the proxy. The reason is that the server and the browser disagree on what the server name is. So if the server emits cookies for a specific domain, it will not work fine. If the server has hardcoded links in pages, it will not work. If the server delivers some javascript which builds requests from hardcoded domains, it will not work either. In fact, I don't really understand why you want to rewrite these Host headers instead of doing the proper thing which consists in binding the server to the correct names. Also, by rewriting, the server loses the information of the original host which is probably not what you want (or what you will ultimately want). Could you please bring in a few more explanations about what you want to do ? Maybe there's another way to do it cleanly. Regards, Willy
Re: backend server ca-file load from directory not working
Hi Lukas,
/opt/etc/ca.d directory is under local file system in both platforms and with
the same permission.
Below is the snapshot of strace output, 1st block showing error if loading
ca-file from directory and 2nd block showing no error if loading ca-file from a
file:
open(/opt/etc/ca.d/, O_RDONLY)= 3
fstat(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2aad6e255000
read(3, 0x2aad6e255000, 4096) = -1 EISDIR (Is a directory)
close(3)= 0
munmap(0x2aad6e255000, 4096)= 0
write(2, [ALERT] 179/020423 (2993) : , 28[ALERT] 179/020423 (2993) : ) = 28
write(2, Proxy 'SFARM-SSL-PROXY', server 'RE..., 104Proxy 'SFARM-SSL-PROXY',
server 'REMOTE' [../conf/haproxy.cfg:34] unable to load CA file
'/opt/etc/ca.d/'.
) = 104
open(/opt/etc/ca.d/ca.crt, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=1220, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2aad6e255000
read(3, -BEGIN CERTIFICATE-\r\nMII..., 4096) = 1220
read(3, , 4096) = 0
close(3)= 0
munmap(0x2aad6e255000, 4096)= 0
I will rebuild HAProxy to 1.5.1 and see if it helps.
Thanks
Diana
From: Lukas Tribus luky...@hotmail.commailto:luky...@hotmail.com
Date: Saturday, June 28, 2014 3:52 AM
To: Microsoft Office User dit...@cisco.commailto:dit...@cisco.com
Cc: haproxy@formilux.orgmailto:haproxy@formilux.org
haproxy@formilux.orgmailto:haproxy@formilux.org
Subject: Re: backend server ca-file load from directory not working
Hi Diana,
The ca-file loading from directory failed in 2.6.18 system with this
message during startup:
unable to load CA file '/opt/etc/ca.d/'.
It seems to me the HAProxy in this system doesn't support directory
loading ca-file?
However, in 2.6.32 system the HAProxy started up successfully.
Here a few suggestions:
- double check filesystems permission
- check if both filesystems are local or if they are remote (e.g. NFS)
- upgrade both haproxy instances to latests stable 1.5.1 (dev21 is unstable)
If that doesn't help, than please run haproxy through strace (for example):
$ strace haproxy -f /etc/haproxy.cfg
And post the outputs when it fails.
Does directory load for ca-file only work if HAProxy is built with
TARGET=linux2628 ?
No, that doesn't matter, the TARGET directive enables or disable certain
kernel assisted features, but none if it matters for SSL or filesystem
access.
Regards,
Lukas
Re: backend server ca-file load from directory not working
Hi Lukas, I did a strace on WORKING platform and noticed HAProxy v1.5.dev21 ignores ca-file /opt/etc/ca.d/ in the backend server line if verify required is not enabled. I think that is the reason why there is no error during startup. When I enabled verify required ca-file /opt/etc/ca.d/ in the backend server line, it throws the same error as in HAProxy v1.5.0 platform: [ALERT] 179/122107 (31559) : Proxy 'SFARM-SSL-PROXY', server 'REMOTE' |haproxy.cfg:34] unable to load CA file '/opt/etc/ca.d/'. In HAProxy v1.5.0 platform, it throws above error regardless verify required is enabled or not. Thanks for the advice. I will enable verify required ca-file ... in both platforms and load ca-file from a file instead of a directory. Regards, Diana From: Lukas Tribus luky...@hotmail.commailto:luky...@hotmail.com Date: Sunday, June 29, 2014 3:06 AM To: Microsoft Office User dit...@cisco.commailto:dit...@cisco.com Cc: haproxy@formilux.orgmailto:haproxy@formilux.org haproxy@formilux.orgmailto:haproxy@formilux.org Subject: RE: backend server ca-file load from directory not working Hi, Below is the snapshot of strace output, 1st block showing error if loading ca-file from directory and 2nd block showing no error if loading ca-file from a file: I think ca-file doesn't support directories, only the crt option supports directories. If you need to specify a CA (to authenticate SSL clients) you need to point directly to the file. If on the other hand you just need the CA file to send towards the client as an intermediate certificate, so that the client can authenticate the final certificate, just point to the directory with the crt keyword. Also read: ca-file doc: http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#ca-file%20%28Bind%20options%29 crt doc: http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#5.1-crt Since you didn't configure any verify keywords on the bind line, I suspect you don't want to do any client SSL authentication at all and replacing ca-file with crt on the bind line will achieve what you need. Regards, Lukas
backend server ca-file load from directory not working
Hi, We tested HAProxy to load ca-file from directory for backend encryption in 2 different systems (Redhat 2.6.18 and 2.6.32). backend SFARM-SSL-PROXY server REMOTE remote.sample.com:443 ssl ca-file /opt/etc/ca.d/ The ca-file loading from directory failed in 2.6.18 system with this message during startup: unable to load CA file '/opt/etc/ca.d/'. It seems to me the HAProxy in this system doesn't support directory loading ca-file? However, in 2.6.32 system the HAProxy started up successfully. Here is the HAProxy build info for 2 systems: 2.6.18 (ca-file load from directory NOT working) HA-Proxy version 1.5.0 2014/06/19 Copyright 2000-2014 Willy Tarreau w...@1wt.eu Build options : TARGET = linux26 CPU = generic CC = gcc CFLAGS = -m64 -march=x86-64 -O2 -g -fno-strict-aliasing OPTIONS = USE_ZLIB=1 USE_OPENSSL=1 USE_PCRE=1 Default settings : maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200 Encrypted password support via crypt(3): yes Built with zlib version : 1.2.3 Compression algorithms supported : identity, deflate, gzip Built with OpenSSL version : OpenSSL 1.0.1h 5 Jun 2014 Running on OpenSSL version : OpenSSL 1.0.1h 5 Jun 2014 OpenSSL library supports TLS extensions : yes OpenSSL library supports SNI : yes OpenSSL library supports prefer-server-ciphers : yes Built with PCRE version : 6.6 06-Feb-2006 PCRE library supports JIT : no (USE_PCRE_JIT not set) 2.6.32 (ca-file load from directory working) HA-Proxy version 1.5-dev21-6b07bf7 +2013/12/17 Copyright 2000-2013 Willy Tarreau w...@1wt.eu Build options : TARGET = linux2628 CPU = generic CC = gcc CFLAGS = -O2 -g -fno-strict-aliasing OPTIONS = USE_LIBCRYPT=1 USE_ZLIB=yes USE_OPENSSL=1 USE_STATIC_PCRE=1 Default settings : maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200 Encrypted password support via crypt(3): yes Built with zlib version : 1.2.3 Compression algorithms supported : identity, deflate, gzip Built with OpenSSL version : OpenSSL 1.0.0-fips 29 Mar 2010 Running on OpenSSL version : OpenSSL 1.0.0-fips 29 Mar 2010 OpenSSL library supports TLS extensions : yes OpenSSL library supports SNI : yes OpenSSL library supports prefer-server-ciphers : yes Built with PCRE version : 7.8 2008-09-05 PCRE library supports JIT : no (USE_PCRE_JIT not set) Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT IP_FREEBIND Does directory load for ca-file only work if HAProxy is built with TARGET=linux2628 ? Please advise. Diana
