Re: Haproxy 1.5 ssl redirect
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
Re: Haproxy 1.5 ssl redirect
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(:[0-9]+)?)?(/.*) Location:\ \3 if hdr_location which works only for the frontend localtest.test123.com. i have another domain 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(:[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
Re: Haproxy 1.5 ssl redirect
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 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(:[0-9]+)?)?(/.*) Location:\ \3 if hdr_location which works only for the frontend localtest.test123.com. i have another domain 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(:[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
Re: Haproxy 1.5 ssl redirect
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 5 timeout connect 5 timeout server 5 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
Re: Haproxy 1.5 ssl redirect
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 5 timeout connect 5 timeout server 5 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
Re: Haproxy 1.5 ssl redirect
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 5 timeout connect 5 timeout server 5 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
Re: Haproxy 1.5 ssl redirect
Hi Sean! You're welcome :) I still have in my TODO list to contact you about your AVI network experience ;) Talk to you soon. Baptiste On Wed, Mar 18, 2015 at 7:06 PM, Sean Patronis spatro...@add123.com 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(:[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 5 timeout connect 5 timeout server 5 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
Re: Haproxy 1.5 ssl redirect
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 5 timeout connect 5 timeout server 5 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
Re: Haproxy 1.5 ssl redirect
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? --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 5 timeout connect 5 timeout server 5 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
Re: Haproxy 1.5 ssl redirect
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 5 timeout connect 5 timeout server 5 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