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 <[email protected]> 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 >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> > >
