Unfortunately, that did not solve all the problems that proxypass and
proxypassreverse does in Apache's mod_proxy. It may be an artifact of
how we do our internal load balancing, but the information Baptiste sent
me about mirroring the proxypass rules here:
http://blog.haproxy.com/2014/04/28/howto-write-apache-proxypass-rules-in-haproxy/
did seem to work (but with only single hostnames). Now I am just trying
to get those redirects to be dynamically set based on host (i.e. domain
name)
--Sean Patronis
Auto Data Direct Inc.
850.877.8804
On 05/27/2015 12:03 PM, Nathan Williams wrote:
we use "redirect scheme https code 301 if !{ ssl_fc }" on our SSL-only
backends, many of which are accessed by multiple hostnames. if i
understand correctly what you're trying to accomplish, i think that
should do the trick?
On Wed, May 27, 2015 at 8:38 AM Sean Patronis <spatro...@add123.com
<mailto:spatro...@add123.com>> wrote:
I have another question to add to the mix..... While attempting to
mirror the proxypass and proxypassreverse capabilities of Apache's
mod_proxy and force https connections across everything through
haproxy,
I have run into a small snag and want to try and work around it.
We have multiple front ends that use the same backends.... but since I
am forcing the URLs to be absolute to rewrite them to https, we
need to
have a variable host name. What is the most efficient way to
accomplish
that?
example: in a backend we have :
# 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
<http://localtest.test123.com>(:[0-9]+)?)?(/.*)
Location:\ \3 if hdr_location
which works only for the frontend localtest.test123.com..... i have
another domain dev.test123.com <http://dev.test123.com> that needs
to use the same backend. What
is the best way to make the host from the request into a variable? how
can we do something like this so that any frontend can use this
backend?
acl hdr_location res.hdr(Location) -m found
rspirep ^Location:\ (https?://%[host](:[0-9]+)?)?(/.*) Location:\ \3
if hdr_location
This is all in haproxy 1.5
Thanks.
--Sean Patronis
Auto Data Direct Inc.
850.877.8804
On 03/18/2015 02:06 PM, Sean Patronis wrote:
> 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
<http://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 <mailto: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 <http://test.test123.com>]
>>> <VirtualHost 10.0.60.5:443 <http://10.0.60.5:443>>
>>> ServerName test.test123.com <http://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 <http://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
<http://172.16.0.10:80> check inter 3000 fall 3
>>>>>> server services1 172.16.0.5:80
<http://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
<http://localcaleb.test123.com> ## local Backends
>>>>>>> bind 10.0.60.5:80 <http://10.0.60.5:80>
>>>>>>> bind 10.0.60.5:443 <http://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
<http://caleblocal.test123.com> if is_apps_match
>>>>>>> default_backend caleb.test123.com
<http://caleb.test123.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> here are the relevant backends:
>>>>>>>
>>>>>>> backend caleblocal.test123.com <http://caleblocal.test123.com>
>>>>>>> reqrep ^([^\ ]*)\ /apps/(.*) \1\ /\2
>>>>>>> server caleb-pc.staff.test123.com
<http://caleb-pc.staff.test123.com> 192.168.166.182:8080
<http://192.168.166.182:8080>
>>>>>>> weight 50
>>>>>>> check
>>>>>>> server maint maint.test123.com:81
<http://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 <http://caleb.test123.com>
>>>>>>> reqrep ^([^\ ]*)\ /apps/(.*) \1\ /\2
>>>>>>> server caleb 10.0.3.216:80 <http://10.0.3.216:80>
weight 50 check
>>>>>>> server maint maint.test123.com:81
<http://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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>
