On 21:39, Wed 17 Sep 08, Reyk Floeter wrote:

quoted text
> 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  port http check script "/usr/local/sbin/chksrvs"

> > }

> >

> > redirect web_https {

> >   listen on $ext_ip1 port https

> >   sticky-address

> >   forward to  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  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

michiel@vanbaak.eu

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?"