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