Baptiste,
Thanks for the links, I had run across them earlier this morning in my
google searching, but your post made me pay more attention to them... I
have it working now, and the trick that seemed to do it for me was
making all the paths absolute (since I am forcing https anyhow, and each
since frontend/backend combo is unique) with this line in my backend config:
# ProxyPassReverse /mirror/foo/ http://bk.dom.com/bar
# Note: we turn the urls into absolute in the mean time
acl hdr_location res.hdr(Location) -m found
rspirep ^Location:\ (https?://localtest.test123.com(:[0-9]+)?)?(/.*)
Location:\ \3 if hdr_location
Thanks for all the help from everyone is this thread!
--Sean Patronis
Auto Data Direct Inc.
850.877.8804
On 03/18/2015 12:06 PM, Baptiste wrote:
Hi Sean,
You may find some useful information here:
http://blog.haproxy.com/2014/04/28/howto-write-apache-proxypass-rules-in-haproxy/
and here:
http://blog.haproxy.com/2013/02/26/ssl-offloading-impact-on-web-applications/
Baptiste
On Wed, Mar 18, 2015 at 3:39 PM, Sean Patronis <spatro...@add123.com> wrote:
Thanks for the link. That looks promising, but testing did not change
anything and I am waiting on the developers to give me some indication of
what headers they may expect. Maybe we can tackle this a different way
since we know it works in apache. I am attempting to replace the following
VirtualHost in apache and put it into haproxy:
## [test.test123.com]
<VirtualHost 10.0.60.5:443>
ServerName test.test123.com
SSLEngine on
SSLProtocol all -SSLv3
SSLHonorCipherOrder On
SSLCipherSuite
ECDHE-RSA-AES256-SHA384:AES256-SHA256:!RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM:!SSLV2:!eNULL
ProxyPassReverse / http://10.0.60.5/
ProxyPass / http://10.0.60.5/
</VirtualHost>
what haproxy frontend settings do I need to make this match whatever apache
and mod_proxy is doing?
10.0.60.5:80 is already in haproxy.... I think the problem may be that
there are some headers getting set by ProxyPass and ProxyPassReverse that I
am not setting in haproxy. More specifically, I think that the apache
ProxyPassReverse is rewiting the problem URI to https, and haproxy is not.
--Sean Patronis
Auto Data Direct Inc.
850.877.8804
On 03/17/2015 06:24 PM, Cyril Bonté wrote:
Hi,
Le 17/03/2015 20:42, Sean Patronis a écrit :
Unfortunately that did not fix it. I mirrored your config and the
problem still exists. I am not quite sure how the URL is getting built
on the backend (the developers say it is all relative URL/URI), but
whatever haproxy is doing, it is doing it differently than apache (with
mod_proxy). Just for fun, I swapped back the ssl termination to apache
to prove that is does not have an issue (once it passes through apache
for ssl, it still goes through Haproxy and all of the backends/acl etc).
My goal in all of this was to ditch apache and go all haproxy on the
front end.
Any other ideas?
Have a look at this answer :
http://permalink.gmane.org/gmane.comp.web.haproxy/10361
I assume that your application is not aware of an SSL termination, so you
have to notify it with the right configuration, which depends on your
backends softwares. Can you provide some information on them ?
--Sean Patronis
Auto Data Direct Inc.
850.877.8804
On 03/17/2015 11:51 AM, Scott McKeown|redIT wrote:
Hi Sean,
I've got a setup that is somewhat like what you are after. I have
however, done it in a very dirrerent way for this very same reason.
Example below:
global
log /dev/log local4 debug
maxconn 4096
daemon
tune.ssl.default-dh-param 2048
ssl-default-bind-ciphers
ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES256-SHA:HIGH:!RC4:!MD5:!aNULL:!EDH
ssl-default-bind-options no-sslv3
ssl-default-server-ciphers
ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES256-SHA:HIGH:!RC4:!MD5:!aNULL:!EDH
ssl-default-server-options no-sslv3
defaults
log global
option httplog
retries 3
timeout client 50000
timeout connect 50000
timeout server 50000
listen http-in
bind x.x.x.x:80
mode http
default_backend www_redit
listen https-in
bind x.x.x.x:443 ssl crt /etc/certs/server_2015.pem
mode http
acl samson_vpn_gateway src 10.8.0.1
acl missing_nagios_slash path_reg -i ^/nagios3[^/]*$
acl missing_cacti_slash path_reg -i ^/cacti[^/]*$
acl missing_dradis_slash path_reg -i ^/customers[^/]*$
redirect code 301 prefix / drop-query append-slash if
missing_nagios_slash
redirect code 301 prefix / drop-query append-slash if
missing_cacti_slash
redirect code 301 prefix / drop-query append-slash if
missing_dradis_slash
acl is_nagios path_reg -i /nagios3/
acl is_cacti path_reg -i /cacti/
acl is_dradis path_reg -i /customers/
#VPN Access Only
use_backend services if is_nagios samson_vpn_gateway
use_backend services if is_cacti samson_vpn_gateway
use_backend dradis if is_dradis
default_backend corp_site
listen corp_site
mode http
log global
option httpclose
source 0.0.0.0 usesrc clientip
option forwardfor
server websites01 172.16.0.10:80 check inter 3000 fall 3
server services1 172.16.0.5:80 check inter 3000 fall 3
listen www_redit
mode http
redirect scheme https
This should do the trick for you you may want to try putting your
reqrep in or play around with the acl list and re-test with your
Headers but I've got mine built with TProxy enabled.
~Scott
On 17/03/2015 15:36, Sean Patronis wrote:
I seem to be having an interesting issue with forced ssl redirects in
Haproxy 1.5.11
Sorry if this sounds clear as mud, but here goes:
When I load a domain that is served by haproxy that is supposed to
force https, it initially forces the connection to be https (if you
attempt to connect over http), but I get a Mixed content warning when
it attempts to load another url that is based on the same domain. If
I allow the mixed content through the browser, it does not get
redirected to https. I am sure I just have something configured
incorrectly, but I am not sure where.....
I go to URL:
https://localcaleb.test123.com/apps/test123/test.html
inside the test123 app it makes a protocol-less request to another
app which ends up using http (since the backend is http balanced)
using this URL:
http://localcaleb.test23.com/apps/testgw/login.jsp
Since the we have a redirect for ssl in place, shouldn't the request
get forced to https? It worked this way when apache was acting as
our SSL reverse proxy. What am I doing incorrectly? If I allow mixed
content in the browser, the haproxy logs show that it indeed connects
over port 80 without getting redirected to 443.
here is the fontend:
frontend localcaleb.test123.com ## local Backends
bind 10.0.60.5:80
bind 10.0.60.5:443 ssl crt /etc/certs/test.bundle no-sslv3
ciphers
ECDHE-RSA-AES256-SHA384:AES256-SHA256:!RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM:!SSLV3:!eNULL
redirect scheme https if !{ ssl_fc }
option http-server-close
acl is_apps_match url_beg /apps/
use_backend caleblocal.test123.com if is_apps_match
default_backend caleb.test123.com
here are the relevant backends:
backend caleblocal.test123.com
reqrep ^([^\ ]*)\ /apps/(.*) \1\ /\2
server caleb-pc.staff.test123.com 192.168.166.182:8080 weight 50
check
server maint maint.test123.com:81 check backup
http-request set-header X-Forwarded-Port %[dst_port]
http-request add-header X-Forwarded-Proto https if { ssl_fc }
backend caleb.test123.com
reqrep ^([^\ ]*)\ /apps/(.*) \1\ /\2
server caleb 10.0.3.216:80 weight 50 check
server maint maint.test123.com:81 check backup
http-request set-header X-Forwarded-Port %[dst_port]
http-request add-header X-Forwarded-Proto https if { ssl_fc }
Thanks.
---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com