Haproxy + stunnel. Strange https behaviour in tomcat and url_sub-based redirection

From: Sergio Toledo <stoledo#visual-engin.com>
Date: Wed, 5 May 2010 19:58:30 +0200


Dear subscribers;

My name is Sergio. I am quite a newbie in Haproxy and Stunnel. I am to set up haproxy in order to perform redirections depending on url substring as well as configuring as a high availability for two web backends (imms_be is a tomcat cluster and tallerpin_be is going to be an IIS-w2K8 cluster).

On the other hand, I have a stunnel decrypting ssl before haproxy. I have some issues regarding this configuration that I am displaying in the next "diagram" (or whatever it is)

Diagram


                |-------------------------|


|---------------->|TOMCAT1 (8080)| (round robin)
(if url_sub tomcat) | |-------------------------| |----------------------------------------------| /----------->| | STUNNEL + HAPROXY BOX | / | | | / | |-------------------------| Browser --------------------->| Stunnel (443) --> Haproxy (80)| |/ |---------------->|TOMCAT1 (8080)| (round robin) | |\ |-------------------------| |----------------------------------------------| \ (if url_sub app1 or if
url_sub app2)
\                |------------|

\------------>| IIS (80) | |------------|

Here are my conf files in order to clarify a bit my scenario.

haproxy.cfg



global
log 127.0.0.1 local0
user root
group root

frontend www *:80
mode http
option forwardfor except 192.168.0.134
option httplog
log global
acl stunnel src 192.168.0.134/32
redirect prefix https://192.168.0.134 unless stunnel

acl java_acl url_sub -i tomcat
acl app1_acl url_sub -i app1
acl app2_acl url_sub -i app2
use_backend java_be if java_acl

use_backend iis_be if app1_acl
use_backend iis_be if app2_acl
default_backend java_be
reqadd X-Proto:\ https
reqadd X-Port:\ 443

backend java_be
mode http
balance roundrobin
contimeout 5000
srvtimeout 50000
server tomcat1 192.168.0.34:8080
server tomcat2 192.168.0.51:8081

backend iis_be
mode http
server iis_server 192.168.0.28:80

stunnel.conf



cert=/usr/local/etc/stunnel/stunnel.pem
#setuid=z26n
#setgid=users

socket=l:TCP_NODELAY=1
socket=r:TCP_NODELAY=1
output = stunnel.log

[https]
accept=192.168.0.134:443
connect=192.168.0.134:80
xforwardedfor=yes

 firma visual

The issues I have are:
1. This scenario works fine for IIS box. But I haven't been able to make it run for java scenario. My suspects aim at base href in tomcat applications. The thing is java web application has a base href in each page it serves to client's browser, and it seems that href is overwriting somehow the url it should be delivered to the browser, that is, https://<server_ip>/<context>/whatever..., but unfortunately, the browser shows http instead. Does the base tag in jsp file have something to do with this strange behaviour? Is the base tag overwriting the https url?
2. One of the workarounds we have tried is to add two headers in haproxy in order to tell the java backend how to build the url. Those headers are X-Proto and X-Port, as you can see in conf file. And although the url is build correctly (with https), and the browser shows it ok, if I sniff the traffic, I can see it in clear text, and not under ssl. 3. Finally, url_sub also has an unexpected behaviour. If I open a browser and surf to https://stunnel+haproxybox/tomcat, it works perfect, but if I open a new tab in the browser or overwrite the url in the same tab, and surf to https://stunnel+haproxybox/app1 or https://stunnel+haproxybox/app2, the browser tries to open app1 or app2 in java backend instead of iis backend. However, if I wait for a while (5 minutes or something), the browser goes to the right backend.

I would like the https to work correctly as well as url_sub-based redirection.

Any help would be appreciated;

Kind regards;

SERGIO TOLEDO
Project Manager

stoledo#visual-engin.com
skypeme: sergio.toledo.urena

Passeig de Grącia 67 1r 2a
08008 Barcelona
T.+34 93 215 77 35
F.+34 93 396 08 57
http://www.visual-engin.com Received on 2010/05/05 19:58

This archive was generated by hypermail 2.2.0 : 2010/05/05 20:00 CEST