Thanks for your replies! I agree that this should be solved in the web-app,
but in the meantime I'll try reyks workaround.
Regards, Mikael
2008/9/17 Michiel van Baak <[EMAIL PROTECTED]>:
> On 21:39, Wed 17 Sep 08, Reyk Floeter wrote:
>> Hi!
>>
>> On Wed, Sep 17, 2008 at 05:45:23PM +0200, Mikael Jansson wrote:
>> > I use relayd with redirects to loadbalance between two webservers
>> > one redirect is used for http requests and the other for https.
>> > the redirects looks like the following:
>> >
>> > redirect web_http {
>> > listen on $ext_ip1 port http
>> > sticky-address
>> > forward to <webservers> port http check script "/usr/local/sbin/chksrvs"
>> > }
>> >
>> > redirect web_https {
>> > listen on $ext_ip1 port https
>> > sticky-address
>> > forward to <webservers> port https check script "/usr/local/sbin/chksrvs"
>> > }
>> >
>> > The redirects works fine separately and sticks to the same machine,
>> > but when the user navigates from http to https the requests sometimes
>> > move over to the other machine. I need the same source-ip to always
>> > stay on the same server regardless of which destination port (http or
>> > https)
>> > is being used. Any suggestions on how to achive this would be greatly
>> > appreciated.
>> >
>>
>> it does not work without a patch. the problem is that the pf Source
>> Tracking table includes a reference to the rule but your example above
>> will load two different rules into pf - one matching http and another
>> one matching https.
>>
>> the trick is to combine both statements into one rule. we don't
>> support "port tables" in pf yet (which whould be very helpful in many
>> cases) but there is support for a port range. so the "hack" is to
>> allow port ranges in the relayd redirection block
>>
>> redirect web {
>> listen on $ext_ip1 port 80:443
>> sticky-address
>> forward to <webservers> port http check script
>> "/usr/local/sbin/chksrvs"
>> }
>>
>> note that this will match any traffic in the 80 - 443 port range, make
>> sure that you add additional pf rules to filter any other ports except
>> 80 and 443. but it works with Source Tracking and should allow your
>> clients to move between http and https on the same server. another
>> limitation is that it only runs checks on one of the ports.
>
> ugh, this looks ugly ;)
> Instead of going this route I would say: find the source of why the
> visitor should access the same host, and solve that.
>
> We use relayd in front of 6 servers, doing http and https.
> It doesn't matter what backend box the user go. Hell, they can even go
> to another box on a reload.
> This of course means we are storing sessions etc on shared storage (NFS
> in our case, and the new sharedance port looks like an alternative for
> that)
>
> --
>
> Michiel van Baak
> [EMAIL PROTECTED]
> http://michiel.vanbaak.eu
> GnuPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x71C946BD
>
> "Why is it drug addicts and computer aficionados are both called users?"
