Hello,
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.
Regards, Mikael

Hi!
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.
reyk
Index: parse.y

===================================================================

RCS file: /cvs/src/usr.sbin/relayd/parse.y,v

retrieving revision 1.122

diff -u -p -I$OpenBSD.*$ -r1.122 parse.y

--- parse.y	22 Jul 2008 23:17:37 -0000	1.122

+++ parse.y	17 Sep 2008 19:21:53 -0000

@@ -30,6 +30,7 @@

 #include <sys/queue.h>
 #include <net/if.h>

+#include <net/pfvar.h>

 #include <netinet/in.h>

 #include <arpa/inet.h>

 #include <arpa/nameser.h>

@@ -100,11 +101,12 @@ static in_port_t	 tableport = 0;

 struct address	*host_v4(const char *);

 struct address	*host_v6(const char *);

 int		 host_dns(const char *, struct addresslist *,

-		    int, in_port_t, const char *);

+		    int, struct portrange *, const char *);

 int		 host(const char *, struct addresslist *,

-		    int, in_port_t, const char *);

+		    int, struct portrange *, const char *);
 struct table	*table_inherit(struct table *);

+int		 getservice(char *);
 typedef struct {

 	union {

@@ -113,6 +115,7 @@...
[ message continues ]

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

no, it is not ugly.  it is a reasonable solution for a very common

case.  you can easilly block other incoming connections with

restrictive pf rules.  but please face reality - not everyone is in

control of their backend web servers since it is VERY common that the

loadbalancers (networking group) are handled by a different group than

the backend webservers (servers group).  and it is also very common

that you run your fancy nice openbsd box in front of some other

"stuff".  indeed, it is very common for loadbalancers and firewalls to
of course this is a better solution if you're in control of the

backend servers.  some people also use solutions like a clustered

database backend (eg. mysql), proprietary solutions like zend cache,

...

I can relate to that, having load balancers fix"ing" backend services.
If you have the time, you will probably find "pound reverse proxy"

http://www.apsis.ch/pound/ to be a nice alternative to try out in your lab.

I have pound on openbsd for several years and can recommend it for http

-> https redirects, SSL termination and back-end load balancing with

health checks (not to mention the dynamic scaling ) and and weighted

priority between backend nodes.
Check it out

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