1

I work on a web app that regularly makes AJAX calls to a REST server that (in production) is accessed via the same domain. While developing locally, I have been redirecting REST calls to a dev server using haproxy to get around browser cross origin request restrictions.

haproxy.cfg

global
 maxconn 4096
 pidfile ~/tmp/haproxy.pid

defaults
 log global
 log 127.0.0.1 local0
 log 127.0.0.1 local1 notice  
 mode http
 timeout connect 300000
 timeout client 300000
 timeout server 300000
 maxconn 2000
 option redispatch
 retries 3
 option httpclose
 option httplog
 option forwardfor
 option httpchk HEAD / HTTP/1.0


frontend dev
   bind *:8080 ssl crt /path/to/proxy.pem

    acl                             allow_php               path_beg /app/
    acl                             allow_rest              path_beg /rest/

    use_backend                     be_php                  if allow_php
    use_backend                     be_rest                 if allow_rest

backend be_php
 balance roundrobin
 server localhost_80 localhost:80

backend be_rest
 balance roundrobin
 server dev_80 dev.example.com:80

This works as expected:

  • https://localhost:8080/app/login displays the same as http://localhost/app/login
  • https://localhost:8080/rest/test response is the same as http://dev.example.com/rest/test

The problem arises when I attempt to configure haproxy for SSL between HAproxy and the backends (which expect SSL).

According to all the documentation I have read, the following changes should have me all set:

backend be_php
    balance roundrobin
    server localhost_443 localhost:443 ssl verify none

backend be_rest
    balance roundrobin
    server dev_443 dev.example.com:443 ssl verify none

But after making these changes, https://localhost:8080 requests time out. Both the php backend and REST backend can be accessed directly via https://localhost/app/... and https://dev.example.com/rest/...

Any ideas as to what I am doing wrong?

EDIT: Updated to reflect @Michael-sqlbot's comment

thedarklord47
  • 111
  • 4
  • Pass-through means pass-through. For the most part, it's opaque. You can't use layer 7 fetches like `path_beg` when you're trying to do pass-through. Far simpler would be to put an self-signed or free (Lets Encrypt, StartSSL) cert on the proxy and let it make an SSL connection to the back-ends so you can continue to operate in HTTP mode. – Michael - sqlbot Jun 14 '16 at 01:55
  • ah got it. I was able to get it working with a self-signed cert and operate in http mode, but I am unable to re-encrypt before sending to the backends. adding `ssl verify none` to the `server` lines in the backends causes requests to timeout – thedarklord47 Jun 14 '16 at 02:13
  • I updated my question to reflect your comment – thedarklord47 Jun 14 '16 at 02:38
  • Check the logs. There is a 4-character code for [session state at disconnect](http://cbonte.github.io/haproxy-dconv/configuration-1.6.html#8.5), which is `----` for a normal connection where everything worked as expected. Usually, the first two characters will give you a good idea what went wrong, otherwise. Note that they are case sensitive, so the first position might have e.g. `S` or `s`, which means two different things. – Michael - sqlbot Jun 14 '16 at 03:02

0 Answers0