Hello, I have a web server on my intranet that I did not build nor administer. However I was asked to set up a reverse proxy which would allow to access the web service from the internet in a secure way. I set up a server within our DMZ where I configured haproxy and stunnel. My idea is to receive any http request comming to my proxy server through the port 80 and respond to it with a redirect to the port 443 using https pointing to the same IP address (the one were both haproxy and stunnel are running). Once the client request comes from the port 443 using https, the stunnel software would take the request, decrypt it and route it to the same server by the port 81. Once again the haproxy software would pick up the request and transfer it to the actual web server (wich uses a specific port, 50100) The server would respond through the port 50100, then the haproxy would send it to Stunnel (in the same box as haproxy). Stunnel would encrypt the response and route it to the client through the port 443. This scheme seems to work, but ... When navigating the web page... when clicking on certain links, the server responds with a redirection to some other internal web sites within our intranet. These redirect messages travel to the client browser which then tries to access these internal web sites from outside our network and then it fails. I thought that there might be a way to have my haproxy to follow these redirects instead of handing them on to the client browser. The following is my haproxy's config file: # this config needs haproxy-1.1.28 or haproxy-1.2.1 global maxconn 16834 pidfile /etc/haproxy/haproxy.pid daemon defaults mode http timeout connect 5000ms timeout client 50000ms timeout server 50000ms frontend http-afuera bind *:80 acl is_initial_session hdr_beg myWeb.com.ar acl is_irj hdr_sub -i irj use_backend login if is_initial_session ! is_irj default_backend portal_safe frontend http-interno bind *:81 default_backend irj backend irj server portal <actual web server's IP addr.>:50100 backend portal_safe redirect prefix https://myWeb.com.ar:443 backend login redirect location https://myWeb.com.ar:443/irj/portal The following is my stunnel config file: sslVersion = all options = NO_SSLv2 setuid = root setgid = root pid = /var/run/stunnel.pid socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 output = /var/log/stunnel.log [portal.gcgestion.com.ar] cert = /root/stunnel-4.53/myCert_com_ar.crt key = /root/stunnel-4.53/server.key accept = <this server's IP addr>:443 connect = <this server's IP addr>:81 TIMEOUTclose = 0 Any help will be immensely appreciated!!
Logs Hi this is an excerpt of the log file: [root@GCLXPRD1 haproxy-1.4.20]# vi /var/log/stunnel.log 2012.09.03 14:01:41 LOG5[790:139859179976464]: myWeb.com.ar accepted connection from 192.xxx.xxx.2:28906 2012.09.03 14:01:41 LOG5[790:139859180046096]: myWeb.com.ar accepted connection from 192.xxx.xxx.2:28907 2012.09.03 14:01:41 LOG5[790:139859180115728]: myWeb.com.ar accepted connection from 192.xxx.xxx.2:28908 2012.09.03 14:01:41 LOG5[790:139859179906832]: myWeb.com.ar accepted connection from 192.xxx.xxx.2:28909 2012.09.03 14:01:41 LOG5[790:139859179767568]: connect_blocking: connected 192.xxx.xxx.71:81 2012.09.03 14:01:41 LOG5[790:139859179767568]: myWeb.com.ar connected remote server from 192.168.80.71:60950 2012.09.03 14:01:41 LOG5[790:139859179976464]: connect_blocking: connected 192.xxx.xxx.71:81 2012.09.03 14:01:41 LOG5[790:139859179976464]: myWeb.com.ar connected remote server from 192.168.80.71:60952 2012.09.03 14:01:41 LOG5[790:139859180046096]: connect_blocking: connected 192.xxx.xxx.71:81 2012.09.03 14:01:41 LOG5[790:139859180046096]: myWeb.com.ar connected remote server from 192.xxx.xxx.71:60954 2012.09.03 14:01:41 LOG5[790:139859180115728]: connect_blocking: connected 192.xxx.xxx.71:81 2012.09.03 14:01:41 LOG5[790:139859180115728]: myWeb.com.ar connected remote server from 192.xxx.xxx.71:60955 2012.09.03 14:01:41 LOG5[790:139859179906832]: connect_blocking: connected 192.xxx.xxx.71:81 2012.09.03 14:01:41 LOG5[790:139859179906832]: myWeb.com.ar connected remote server from 192.xxx.xxx.71:60957 2012.09.03 14:01:56 LOG5[790:139859179976464]: Connection closed: 1134 bytes sent to SSL, 11757 bytes sent to socket 2012.09.03 14:01:56 LOG5[790:139859179767568]: Connection closed: 1260 bytes sent to SSL, 12709 bytes sent to socket 2012.09.03 14:01:56 LOG5[790:139859180115728]: Connection closed: 5462 bytes sent to SSL, 11434 bytes sent to socket 2012.09.03 14:01:56 LOG5[790:139859179906832]: Connection closed: 1134 bytes sent to SSL, 11790 bytes sent to socket 2012.09.03 14:01:56 LOG5[790:139859179837200]: Connection closed: 20370 bytes sent to SSL, 16508 bytes sent to socket 2012.09.03 14:01:56 LOG5[790:139859180046096]: Connection closed: 1260 bytes sent to SSL, 12574 bytes sent to socket 2012.09.03 14:03:05 LOG5[790:139859180046096]: myWeb.com.ar accepted connection from 192.xxx.xxx.2:28927 2012.09.03 14:03:05 LOG5[790:139859180046096]: connect_blocking: connected 192.xxx.xxx.71:81 2012.09.03 14:03:05 LOG5[790:139859180046096]: myWeb.com.ar connected remote server from 192.xxx.xxx.71:46042 2012.09.03 14:03:22 LOG5[790:139859180046096]: Connection closed: 12010 bytes sent to SSL, 9577 bytes sent to socket ---------------------------------------------------- 192.xxx.xxx.71 is where haproxy and stunnel live. 192.xxx.xxx.2: Is a nat server Best regards
stunnel behaviour on redirects Folks, Is there a way to have Stunnel or haproxy software follow the redirections on clients behalf? I mean, if my web server's response is "go to url http://other.website.com" I want my haproxy to resend the request to "http://other.website.com" instead of telling the client to send the request by itself. Is it possible? Is that a normal configuration? If not, is there another approach? best regards & have a nice day!
No, it is not possible, and doing so would be terribly wrong as the browser would believe it's accessing one site while the server would believe the browser asked for a different location. Playing with URLs and redirects between clients and servers creates browsing issues and even security issues (think about cookies returned for wrong site or wrong path, incorrect referrers in subsequent requests, unexpected content types being returned and cached, etc...). A few hacky products are able to do this but you should never ever do this, this is the wrong solution to a probably more complex issue.
