Re: problems with hoststated and relayd
On Thu, Mar 06, 2008 at 08:58:01PM +0100, Sebastian Reitenbach wrote:
Reyk Floeter [EMAIL PROTECTED] wrote:
btw., did you test it with the latest code from -current?
the sparch64 was installed from a snapshot not very long ago:
OpenBSD 4.2-current (GENERIC.MP) #113: Wed Feb 13 20:47:18 MST 2008
[EMAIL PROTECTED]:/usr/src/sys/arch/sparc64/compile/GENERIC.MP
the system is from the same download.
Sebastian
Feb 13 and 4.2-current is long ago ;) Some things have been changed in
March... please try the latest snapshot or even -current.
On Mon, Mar 03, 2008 at 07:37:53PM +0100, Sebastian Reitenbach wrote:
Reyk Floeter [EMAIL PROTECTED] wrote:
hi!
it tested your config and it works fine without problems, there is no
bug in relayd here...
...you seem to make a common mistake:
forward to ogohosts port http mode hash \
check http / code 200
you expect that the webservers always return the HTTP error code 200
OK. this is not how HTTP works. your webserver may return another
error based on the site, state, or configuration (moved, not allowed,
not found, server error, ...).
please test the following:
$ lynx -head http://10.0.0.121/
This was done on the host running relayd:
HTTP/1.1 200 OK
Date: Mon, 03 Mar 2008 18:22:37 GMT
Server: Apache
Last-Modified: Tue, 28 Aug 2007 16:00:16 GMT
ETag: fccbb0109d4b4b44b551e2fe7cc156404b93a785
Accept-Ranges: bytes
Content-Length: 2216
Connection: close
Content-Type: text/html
On the 4.2 host, this check works also well with hoststated, there its
embedded in the table definition, see last configuration snippet. But
with
hoststated, I have the other problem mentioned below.
The / on the apache instances is just serving the apache index page.
The application itself sits behind a location, but I think checking just
the
apache availability, and then assuming the application is there too, is
fine
for testing.
and you will see the HTTP header. for example, the following header
would require you to change your check to 'check http / code 302'
(or even 'check http /oxid/ code 200'):
HTTP/1.1 302 Found
Date: Mon, 03 Mar 2008 17:24:10 GMT
Server: Apache
Location: /oxid/
Connection: close
Content-Type: text/html
i normally use a special monitor script to check the state on the
webservers, for example the Zend platform provides the following
self-test:
check http '/ZendPlatform/client/getPing.php' code 200
there is unfortunately no such thing in the app I want to use, at least
not
that I am aware of, but I think the ordinary http check is ok for now.
Sebastian
reyk
On Mon, Mar 03, 2008 at 07:45:00AM +0100, Sebastian Reitenbach wrote:
Hi,
this is the first time I play around with hoststated/relayd.
I have a stateful web application, and try to use hoststated/relayd
in
front
of it. Because the application is stateful, the client has to be
redirected
to the same instance for the session lifetime. The session id is
encoded
as
GET parameter wosid. Further I have the problem that many of the
users
are
either sitting behind a proxy or a NAT'ed IP address, so these
should
not be
redirected to the same application instance.
I tried with hoststated on OpenBSD 4.2 i386 and with relayd on
OpenBSD -snapshot sparc64 from beginning of February 08.
I'm not sure, whether I see the same problems, as described here in
that
thread:
http://www.nabble.com/relayd-http-check-connection-failures--hoststated-
Well, I do not fiddle around with carp interfaces, and I also tried
the
patch with the timeout, that did not fixed my problem.
First I tried to use relayd, until I came across above mentioned
thread,
however, first I tried to setup a ssl accelerator as in the example:
ext_addr=10.0.0.24
ogo1=10.0.0.121
ogo2=10.0.0.122
ogo3=10.0.0.123
ogo4=10.0.0.124
ogo5=10.0.0.125
timeout
table ogohosts { $ogo1 $ogo2 $ogo3 $ogo4 $ogo5 }
http protocol httpssl {
header append $REMOTE_ADDR to X-Forwarded-For
header append $SERVER_ADDR:$SERVER_PORT to X-Forwarded-
header change Connection to close
cookie hash wosid
url hash wosid
url log wosid
# Various TCP performance options
# tcp { nodelay, sack, socket buffer 65536, backlog 128 }
# ssl { no sslv2, sslv3, tlsv1, ciphers HIGH }
# ssl session cache disable
}
relay wwwssl {
# Run as a SSL accelerator
listen on $ext_addr port 443 ssl
protocol httpssl
#
Re: problems with hoststated and relayd
Reyk Floeter [EMAIL PROTECTED] wrote:
btw., did you test it with the latest code from -current?
the sparch64 was installed from a snapshot not very long ago:
OpenBSD 4.2-current (GENERIC.MP) #113: Wed Feb 13 20:47:18 MST 2008
[EMAIL PROTECTED]:/usr/src/sys/arch/sparc64/compile/GENERIC.MP
the system is from the same download.
Sebastian
On Mon, Mar 03, 2008 at 07:37:53PM +0100, Sebastian Reitenbach wrote:
Reyk Floeter [EMAIL PROTECTED] wrote:
hi!
it tested your config and it works fine without problems, there is no
bug in relayd here...
...you seem to make a common mistake:
forward to ogohosts port http mode hash \
check http / code 200
you expect that the webservers always return the HTTP error code 200
OK. this is not how HTTP works. your webserver may return another
error based on the site, state, or configuration (moved, not allowed,
not found, server error, ...).
please test the following:
$ lynx -head http://10.0.0.121/
This was done on the host running relayd:
HTTP/1.1 200 OK
Date: Mon, 03 Mar 2008 18:22:37 GMT
Server: Apache
Last-Modified: Tue, 28 Aug 2007 16:00:16 GMT
ETag: fccbb0109d4b4b44b551e2fe7cc156404b93a785
Accept-Ranges: bytes
Content-Length: 2216
Connection: close
Content-Type: text/html
On the 4.2 host, this check works also well with hoststated, there its
embedded in the table definition, see last configuration snippet. But
with
hoststated, I have the other problem mentioned below.
The / on the apache instances is just serving the apache index page.
The application itself sits behind a location, but I think checking just
the
apache availability, and then assuming the application is there too, is
fine
for testing.
and you will see the HTTP header. for example, the following header
would require you to change your check to 'check http / code 302'
(or even 'check http /oxid/ code 200'):
HTTP/1.1 302 Found
Date: Mon, 03 Mar 2008 17:24:10 GMT
Server: Apache
Location: /oxid/
Connection: close
Content-Type: text/html
i normally use a special monitor script to check the state on the
webservers, for example the Zend platform provides the following
self-test:
check http '/ZendPlatform/client/getPing.php' code 200
there is unfortunately no such thing in the app I want to use, at least
not
that I am aware of, but I think the ordinary http check is ok for now.
Sebastian
reyk
On Mon, Mar 03, 2008 at 07:45:00AM +0100, Sebastian Reitenbach wrote:
Hi,
this is the first time I play around with hoststated/relayd.
I have a stateful web application, and try to use hoststated/relayd
in
front
of it. Because the application is stateful, the client has to be
redirected
to the same instance for the session lifetime. The session id is
encoded
as
GET parameter wosid. Further I have the problem that many of the
users
are
either sitting behind a proxy or a NAT'ed IP address, so these
should
not be
redirected to the same application instance.
I tried with hoststated on OpenBSD 4.2 i386 and with relayd on
OpenBSD -snapshot sparc64 from beginning of February 08.
I'm not sure, whether I see the same problems, as described here in
that
thread:
http://www.nabble.com/relayd-http-check-connection-failures--hoststated-
Well, I do not fiddle around with carp interfaces, and I also tried
the
patch with the timeout, that did not fixed my problem.
First I tried to use relayd, until I came across above mentioned
thread,
however, first I tried to setup a ssl accelerator as in the example:
ext_addr=10.0.0.24
ogo1=10.0.0.121
ogo2=10.0.0.122
ogo3=10.0.0.123
ogo4=10.0.0.124
ogo5=10.0.0.125
timeout
table ogohosts { $ogo1 $ogo2 $ogo3 $ogo4 $ogo5 }
http protocol httpssl {
header append $REMOTE_ADDR to X-Forwarded-For
header append $SERVER_ADDR:$SERVER_PORT to X-Forwarded-
header change Connection to close
cookie hash wosid
url hash wosid
url log wosid
# Various TCP performance options
# tcp { nodelay, sack, socket buffer 65536, backlog 128 }
# ssl { no sslv2, sslv3, tlsv1, ciphers HIGH }
# ssl session cache disable
}
relay wwwssl {
# Run as a SSL accelerator
listen on $ext_addr port 443 ssl
protocol httpssl
# Forward to hosts in the webhosts table using a src/dst
hash
forward to ogohosts port http mode hash \
check http / code 200
}
# relayd -d -vv -f /etc/relayd.conf
startup
init_filter: filter init done
init_tables: created 0 tables
relay_privinit: adding relay wwwssl
protocol 0: name
Re: problems with hoststated and relayd
btw., did you test it with the latest code from -current?
On Mon, Mar 03, 2008 at 07:37:53PM +0100, Sebastian Reitenbach wrote:
Reyk Floeter [EMAIL PROTECTED] wrote:
hi!
it tested your config and it works fine without problems, there is no
bug in relayd here...
...you seem to make a common mistake:
forward to ogohosts port http mode hash \
check http / code 200
you expect that the webservers always return the HTTP error code 200
OK. this is not how HTTP works. your webserver may return another
error based on the site, state, or configuration (moved, not allowed,
not found, server error, ...).
please test the following:
$ lynx -head http://10.0.0.121/
This was done on the host running relayd:
HTTP/1.1 200 OK
Date: Mon, 03 Mar 2008 18:22:37 GMT
Server: Apache
Last-Modified: Tue, 28 Aug 2007 16:00:16 GMT
ETag: fccbb0109d4b4b44b551e2fe7cc156404b93a785
Accept-Ranges: bytes
Content-Length: 2216
Connection: close
Content-Type: text/html
On the 4.2 host, this check works also well with hoststated, there its
embedded in the table definition, see last configuration snippet. But with
hoststated, I have the other problem mentioned below.
The / on the apache instances is just serving the apache index page.
The application itself sits behind a location, but I think checking just the
apache availability, and then assuming the application is there too, is fine
for testing.
and you will see the HTTP header. for example, the following header
would require you to change your check to 'check http / code 302'
(or even 'check http /oxid/ code 200'):
HTTP/1.1 302 Found
Date: Mon, 03 Mar 2008 17:24:10 GMT
Server: Apache
Location: /oxid/
Connection: close
Content-Type: text/html
i normally use a special monitor script to check the state on the
webservers, for example the Zend platform provides the following
self-test:
check http '/ZendPlatform/client/getPing.php' code 200
there is unfortunately no such thing in the app I want to use, at least not
that I am aware of, but I think the ordinary http check is ok for now.
Sebastian
reyk
On Mon, Mar 03, 2008 at 07:45:00AM +0100, Sebastian Reitenbach wrote:
Hi,
this is the first time I play around with hoststated/relayd.
I have a stateful web application, and try to use hoststated/relayd in
front
of it. Because the application is stateful, the client has to be
redirected
to the same instance for the session lifetime. The session id is encoded
as
GET parameter wosid. Further I have the problem that many of the users
are
either sitting behind a proxy or a NAT'ed IP address, so these should
not be
redirected to the same application instance.
I tried with hoststated on OpenBSD 4.2 i386 and with relayd on
OpenBSD -snapshot sparc64 from beginning of February 08.
I'm not sure, whether I see the same problems, as described here in that
thread:
http://www.nabble.com/relayd-http-check-connection-failures--hoststated-operates-correctly-to15646508.html
Well, I do not fiddle around with carp interfaces, and I also tried the
patch with the timeout, that did not fixed my problem.
First I tried to use relayd, until I came across above mentioned thread,
however, first I tried to setup a ssl accelerator as in the example:
ext_addr=10.0.0.24
ogo1=10.0.0.121
ogo2=10.0.0.122
ogo3=10.0.0.123
ogo4=10.0.0.124
ogo5=10.0.0.125
timeout
table ogohosts { $ogo1 $ogo2 $ogo3 $ogo4 $ogo5 }
http protocol httpssl {
header append $REMOTE_ADDR to X-Forwarded-For
header append $SERVER_ADDR:$SERVER_PORT to X-Forwarded-By
header change Connection to close
cookie hash wosid
url hash wosid
url log wosid
# Various TCP performance options
# tcp { nodelay, sack, socket buffer 65536, backlog 128 }
# ssl { no sslv2, sslv3, tlsv1, ciphers HIGH }
# ssl session cache disable
}
relay wwwssl {
# Run as a SSL accelerator
listen on $ext_addr port 443 ssl
protocol httpssl
# Forward to hosts in the webhosts table using a src/dst hash
forward to ogohosts port http mode hash \
check http / code 200
}
# relayd -d -vv -f /etc/relayd.conf
startup
init_filter: filter init done
init_tables: created 0 tables
relay_privinit: adding relay wwwssl
protocol 0: name httpssl
flags: 0x0004
type: http
request change Connection to close
request cookie hash wosid
request url hash wosid
request url log wosid
request append $SERVER_ADDR:$SERVER_PORT
to X-Forwarded-By
request append $REMOTE_ADDR to X-Forwarded-For
Re: problems with hoststated and relayd
Sebastian Reitenbach wrote: cut Also a http redirect did not work. I get a timeout in the browser. With tcpdump I see incoming SYN packets to port 80, but they are not answered: cut I am having the same problem with Feb 25 snapshot. It seems no rdr rules are getting loaded into PF. And I was just about to showcase and brag about a very hip setup ;-) Wijnand
Re: problems with hoststated and relayd
On Mon Mar 03, 2008 at 07:45:00 +0100, Sebastian Reitenbach wrote:
Hi,
this is the first time I play around with hoststated/relayd.
I have a stateful web application, and try to use hoststated/relayd in front
of it. Because the application is stateful, the client has to be redirected
to the same instance for the session lifetime. The session id is encoded as
GET parameter wosid. Further I have the problem that many of the users are
either sitting behind a proxy or a NAT'ed IP address, so these should not be
redirected to the same application instance.
I tried with hoststated on OpenBSD 4.2 i386 and with relayd on
OpenBSD -snapshot sparc64 from beginning of February 08.
I'm not sure, whether I see the same problems, as described here in that
thread:
http://www.nabble.com/relayd-http-check-connection-failures--hoststated-operates-correctly-to15646508.html
Well, I do not fiddle around with carp interfaces, and I also tried the
patch with the timeout, that did not fixed my problem.
First I tried to use relayd, until I came across above mentioned thread,
however, first I tried to setup a ssl accelerator as in the example:
ext_addr=10.0.0.24
ogo1=10.0.0.121
ogo2=10.0.0.122
ogo3=10.0.0.123
ogo4=10.0.0.124
ogo5=10.0.0.125
timeout
table ogohosts { $ogo1 $ogo2 $ogo3 $ogo4 $ogo5 }
http protocol httpssl {
header append $REMOTE_ADDR to X-Forwarded-For
header append $SERVER_ADDR:$SERVER_PORT to X-Forwarded-By
header change Connection to close
cookie hash wosid
url hash wosid
url log wosid
# Various TCP performance options
# tcp { nodelay, sack, socket buffer 65536, backlog 128 }
# ssl { no sslv2, sslv3, tlsv1, ciphers HIGH }
# ssl session cache disable
}
relay wwwssl {
# Run as a SSL accelerator
listen on $ext_addr port 443 ssl
protocol httpssl
# Forward to hosts in the webhosts table using a src/dst hash
forward to ogohosts port http mode hash \
check http / code 200
}
# relayd -d -vv -f /etc/relayd.conf
startup
init_filter: filter init done
init_tables: created 0 tables
relay_privinit: adding relay wwwssl
protocol 0: name httpssl
flags: 0x0004
type: http
request change Connection to close
request cookie hash wosid
request url hash wosid
request url log wosid
request append $SERVER_ADDR:$SERVER_PORT
to X-Forwarded-By
request append $REMOTE_ADDR to X-Forwarded-For
hce_notify_done: 10.0.0.121 (tcp_send_req: timeout)
relay_init: max open files 1024
relay_init: max open files 1024
host 10.0.0.121, check http code (9ms), state unknown - down, availability
0.00%
hce_notify_done: 10.0.0.122 (tcp_send_req: timeout)
host 10.0.0.122, check http code (51ms), state unknown - down, availability
0.00%
hce_notify_done: 10.0.0.123 (tcp_send_req: timeout)
host 10.0.0.123, check http code (52ms), state unknown - down, availability
0.00%
hce_notify_done: 10.0.0.124 (tcp_send_req: timeout)
host 10.0.0.124, check http code (53ms), state unknown - down, availability
0.00%
hce_notify_done: 10.0.0.125 (tcp_send_req: timeout)
host 10.0.0.125, check http code (53ms), state unknown - down, availability
0.00%
pfe_dispatch_imsg: state -1 for host 9 10.0.0.121
pfe_dispatch_imsg: state -1 for host 8 10.0.0.122
pfe_dispatch_imsg: state -1 for host 7 10.0.0.123
pfe_dispatch_imsg: state -1 for host 6 10.0.0.124
pfe_dispatch_imsg: state -1 for host 5 10.0.0.125
relay_ssl_ctx_create: loading certificate
relay_init: max open files 1024
relay_ssl_ctx_create: loading certificate
relay_ssl_ctx_create: loading certificate
relay_ssl_ctx_create: loading private key
relay_init: max open files 1024
adding 5 hosts from table ogohosts:80
relay_init: max open files 1024
relay_launch: running relay wwwssl
relay_ssl_ctx_create: loading private key
adding 5 hosts from table ogohosts:80
relay_ssl_ctx_create: loading private key
relay_launch: running relay wwwssl
adding 5 hosts from table ogohosts:80
relay_ssl_ctx_create: loading certificate
relay_launch: running relay wwwssl
relay_ssl_ctx_create: loading certificate
relay_ssl_ctx_create: loading private key
adding 5 hosts from table ogohosts:80
relay_ssl_ctx_create: loading private key
relay_launch: running relay wwwssl
adding 5 hosts from table ogohosts:80
relay_launch: running relay wwwssl
relay wwwssl, session 1 established (1 active)
relay_from_table: no active hosts
relay wwwssl, session 1 (1 active), 0, 10.0.0.9 - :80, session failed
relay wwwssl, session 2 established (1 active)
relay_from_table: no active hosts
relay wwwssl, session 2 (1 active), 0, 10.0.0.9 - :80, session failed
tcp_write: connect timed out
hce_notify_done: 10.0.0.124 (tcp_write: connect failed)
tcp_write: connect timed out
hce_notify_done: 10.0.0.125
Re: problems with hoststated and relayd
On Mon, Mar 03, 2008 at 10:29:30AM +0100, Wijnand Wiersma wrote: Sebastian Reitenbach wrote: cut Also a http redirect did not work. I get a timeout in the browser. With tcpdump I see incoming SYN packets to port 80, but they are not answered: cut I am having the same problem with Feb 25 snapshot. It seems no rdr rules are getting loaded into PF. ? the previous bug report was about relays only, it does not load any rdr rules into PF. in your case, have you added the relayd anchor to pf.conf? rdr-anchor relayd/* And I was just about to showcase and brag about a very hip setup ;-) Wijnand
Re: problems with hoststated and relayd
hi!
it tested your config and it works fine without problems, there is no
bug in relayd here...
...you seem to make a common mistake:
forward to ogohosts port http mode hash \
check http / code 200
you expect that the webservers always return the HTTP error code 200
OK. this is not how HTTP works. your webserver may return another
error based on the site, state, or configuration (moved, not allowed,
not found, server error, ...).
please test the following:
$ lynx -head http://10.0.0.121/
and you will see the HTTP header. for example, the following header
would require you to change your check to 'check http / code 302'
(or even 'check http /oxid/ code 200'):
HTTP/1.1 302 Found
Date: Mon, 03 Mar 2008 17:24:10 GMT
Server: Apache
Location: /oxid/
Connection: close
Content-Type: text/html
i normally use a special monitor script to check the state on the
webservers, for example the Zend platform provides the following
self-test:
check http '/ZendPlatform/client/getPing.php' code 200
reyk
On Mon, Mar 03, 2008 at 07:45:00AM +0100, Sebastian Reitenbach wrote:
Hi,
this is the first time I play around with hoststated/relayd.
I have a stateful web application, and try to use hoststated/relayd in front
of it. Because the application is stateful, the client has to be redirected
to the same instance for the session lifetime. The session id is encoded as
GET parameter wosid. Further I have the problem that many of the users are
either sitting behind a proxy or a NAT'ed IP address, so these should not be
redirected to the same application instance.
I tried with hoststated on OpenBSD 4.2 i386 and with relayd on
OpenBSD -snapshot sparc64 from beginning of February 08.
I'm not sure, whether I see the same problems, as described here in that
thread:
http://www.nabble.com/relayd-http-check-connection-failures--hoststated-operates-correctly-to15646508.html
Well, I do not fiddle around with carp interfaces, and I also tried the
patch with the timeout, that did not fixed my problem.
First I tried to use relayd, until I came across above mentioned thread,
however, first I tried to setup a ssl accelerator as in the example:
ext_addr=10.0.0.24
ogo1=10.0.0.121
ogo2=10.0.0.122
ogo3=10.0.0.123
ogo4=10.0.0.124
ogo5=10.0.0.125
timeout
table ogohosts { $ogo1 $ogo2 $ogo3 $ogo4 $ogo5 }
http protocol httpssl {
header append $REMOTE_ADDR to X-Forwarded-For
header append $SERVER_ADDR:$SERVER_PORT to X-Forwarded-By
header change Connection to close
cookie hash wosid
url hash wosid
url log wosid
# Various TCP performance options
# tcp { nodelay, sack, socket buffer 65536, backlog 128 }
# ssl { no sslv2, sslv3, tlsv1, ciphers HIGH }
# ssl session cache disable
}
relay wwwssl {
# Run as a SSL accelerator
listen on $ext_addr port 443 ssl
protocol httpssl
# Forward to hosts in the webhosts table using a src/dst hash
forward to ogohosts port http mode hash \
check http / code 200
}
# relayd -d -vv -f /etc/relayd.conf
startup
init_filter: filter init done
init_tables: created 0 tables
relay_privinit: adding relay wwwssl
protocol 0: name httpssl
flags: 0x0004
type: http
request change Connection to close
request cookie hash wosid
request url hash wosid
request url log wosid
request append $SERVER_ADDR:$SERVER_PORT
to X-Forwarded-By
request append $REMOTE_ADDR to X-Forwarded-For
hce_notify_done: 10.0.0.121 (tcp_send_req: timeout)
relay_init: max open files 1024
relay_init: max open files 1024
host 10.0.0.121, check http code (9ms), state unknown - down, availability
0.00%
hce_notify_done: 10.0.0.122 (tcp_send_req: timeout)
host 10.0.0.122, check http code (51ms), state unknown - down, availability
0.00%
hce_notify_done: 10.0.0.123 (tcp_send_req: timeout)
host 10.0.0.123, check http code (52ms), state unknown - down, availability
0.00%
hce_notify_done: 10.0.0.124 (tcp_send_req: timeout)
host 10.0.0.124, check http code (53ms), state unknown - down, availability
0.00%
hce_notify_done: 10.0.0.125 (tcp_send_req: timeout)
host 10.0.0.125, check http code (53ms), state unknown - down, availability
0.00%
pfe_dispatch_imsg: state -1 for host 9 10.0.0.121
pfe_dispatch_imsg: state -1 for host 8 10.0.0.122
pfe_dispatch_imsg: state -1 for host 7 10.0.0.123
pfe_dispatch_imsg: state -1 for host 6 10.0.0.124
pfe_dispatch_imsg: state -1 for host 5 10.0.0.125
relay_ssl_ctx_create: loading certificate
relay_init: max open files 1024
relay_ssl_ctx_create: loading certificate
relay_ssl_ctx_create: loading certificate
relay_ssl_ctx_create: loading private key
relay_init: max open files 1024
adding 5 hosts from table ogohosts:80
relay_init: max open files 1024
Re: problems with hoststated and relayd
Hi,
Reyk Floeter [EMAIL PROTECTED] wrote:
On Mon, Mar 03, 2008 at 10:29:30AM +0100, Wijnand Wiersma wrote:
Sebastian Reitenbach wrote:
cut
Also a http redirect did not work. I get a timeout in the browser. With
tcpdump I see incoming SYN packets to port 80, but they are not
answered:
cut
I am having the same problem with Feb 25 snapshot.
It seems no rdr rules are getting loaded into PF.
? the previous bug report was about relays only, it does not load any
rdr rules into PF.
in your case, have you added the relayd anchor to pf.conf?
rdr-anchor relayd/*
yeah, I have, below my pf.conf:
ext_if=hme0
table possible_ogohosts persist { 10.0.0.121, 10.0.0.122, 10.0.0.123,
10.0.0.124, 10.0.0.125 }
set skip on lo
scrub in
rdr-anchor relayd/*
block in log
pass out log
antispoof quick for { lo }
pass in log on $ext_if proto tcp to ($ext_if) port ssh
pass in log on $ext_if proto tcp to ($ext_if) port https
pass in log on $ext_if proto tcp to ($ext_if) port http
pass in log on $ext_if proto tcp to possible_ogohosts port http
the table, and the last pass rule is because these connections got blocked,
without that rule. But I assume, if everything would work correctly, I
wouldn't need it.
Sebastian
Re: problems with hoststated and relayd
Reyk Floeter [EMAIL PROTECTED] wrote:
hi!
it tested your config and it works fine without problems, there is no
bug in relayd here...
...you seem to make a common mistake:
forward to ogohosts port http mode hash \
check http / code 200
you expect that the webservers always return the HTTP error code 200
OK. this is not how HTTP works. your webserver may return another
error based on the site, state, or configuration (moved, not allowed,
not found, server error, ...).
please test the following:
$ lynx -head http://10.0.0.121/
This was done on the host running relayd:
HTTP/1.1 200 OK
Date: Mon, 03 Mar 2008 18:22:37 GMT
Server: Apache
Last-Modified: Tue, 28 Aug 2007 16:00:16 GMT
ETag: fccbb0109d4b4b44b551e2fe7cc156404b93a785
Accept-Ranges: bytes
Content-Length: 2216
Connection: close
Content-Type: text/html
On the 4.2 host, this check works also well with hoststated, there its
embedded in the table definition, see last configuration snippet. But with
hoststated, I have the other problem mentioned below.
The / on the apache instances is just serving the apache index page.
The application itself sits behind a location, but I think checking just the
apache availability, and then assuming the application is there too, is fine
for testing.
and you will see the HTTP header. for example, the following header
would require you to change your check to 'check http / code 302'
(or even 'check http /oxid/ code 200'):
HTTP/1.1 302 Found
Date: Mon, 03 Mar 2008 17:24:10 GMT
Server: Apache
Location: /oxid/
Connection: close
Content-Type: text/html
i normally use a special monitor script to check the state on the
webservers, for example the Zend platform provides the following
self-test:
check http '/ZendPlatform/client/getPing.php' code 200
there is unfortunately no such thing in the app I want to use, at least not
that I am aware of, but I think the ordinary http check is ok for now.
Sebastian
reyk
On Mon, Mar 03, 2008 at 07:45:00AM +0100, Sebastian Reitenbach wrote:
Hi,
this is the first time I play around with hoststated/relayd.
I have a stateful web application, and try to use hoststated/relayd in
front
of it. Because the application is stateful, the client has to be
redirected
to the same instance for the session lifetime. The session id is encoded
as
GET parameter wosid. Further I have the problem that many of the users
are
either sitting behind a proxy or a NAT'ed IP address, so these should
not be
redirected to the same application instance.
I tried with hoststated on OpenBSD 4.2 i386 and with relayd on
OpenBSD -snapshot sparc64 from beginning of February 08.
I'm not sure, whether I see the same problems, as described here in that
thread:
http://www.nabble.com/relayd-http-check-connection-failures--hoststated-operates-correctly-to15646508.html
Well, I do not fiddle around with carp interfaces, and I also tried the
patch with the timeout, that did not fixed my problem.
First I tried to use relayd, until I came across above mentioned thread,
however, first I tried to setup a ssl accelerator as in the example:
ext_addr=10.0.0.24
ogo1=10.0.0.121
ogo2=10.0.0.122
ogo3=10.0.0.123
ogo4=10.0.0.124
ogo5=10.0.0.125
timeout
table ogohosts { $ogo1 $ogo2 $ogo3 $ogo4 $ogo5 }
http protocol httpssl {
header append $REMOTE_ADDR to X-Forwarded-For
header append $SERVER_ADDR:$SERVER_PORT to X-Forwarded-By
header change Connection to close
cookie hash wosid
url hash wosid
url log wosid
# Various TCP performance options
# tcp { nodelay, sack, socket buffer 65536, backlog 128 }
# ssl { no sslv2, sslv3, tlsv1, ciphers HIGH }
# ssl session cache disable
}
relay wwwssl {
# Run as a SSL accelerator
listen on $ext_addr port 443 ssl
protocol httpssl
# Forward to hosts in the webhosts table using a src/dst hash
forward to ogohosts port http mode hash \
check http / code 200
}
# relayd -d -vv -f /etc/relayd.conf
startup
init_filter: filter init done
init_tables: created 0 tables
relay_privinit: adding relay wwwssl
protocol 0: name httpssl
flags: 0x0004
type: http
request change Connection to close
request cookie hash wosid
request url hash wosid
request url log wosid
request append $SERVER_ADDR:$SERVER_PORT
to X-Forwarded-By
request append $REMOTE_ADDR to X-Forwarded-For
hce_notify_done: 10.0.0.121 (tcp_send_req: timeout)
relay_init: max open files 1024
relay_init: max open files 1024
host 10.0.0.121, check http code (9ms), state unknown - down,
availability
0.00%
hce_notify_done: 10.0.0.122 (tcp_send_req: timeout)
host
Re: problems with hoststated and relayd
Hi Reyk,
thank you for your reply.
Reyk Floeter schreef:
On Mon, Mar 03, 2008 at 10:29:30AM +0100, Wijnand Wiersma wrote:
Sebastian Reitenbach wrote:
cut
Also a http redirect did not work. I get a timeout in the browser. With
tcpdump I see incoming SYN packets to port 80, but they are not answered:
cut
I am having the same problem with Feb 25 snapshot.
It seems no rdr rules are getting loaded into PF.
? the previous bug report was about relays only, it does not load any
rdr rules into PF.
I quoted the part where Sebastian mentioned ordinary redirects failing
too. Maybe I cut too much. Correct Sebastian?
in your case, have you added the relayd anchor to pf.conf?
rdr-anchor relayd/*
Yes, sure I did.
Here is the full config:
# grep -v ^# /etc/relayd.conf
ext_addr=85.158.207.27
webhost1=10.10.11.36
webhost2=10.10.11.37
table webhosts { $webhost1 $webhost2 }
table fallback { 127.0.0.1 }
redirect www {
listen on $ext_addr port http interface carp0
# tag every packet that goes thru the rdr rule with RELAYD
tag RELAYD
forward to webhosts timeout 200 check http / code 200
forward to fallback check icmp
}
# grep -v ^# /etc/pf.conf
ext_if=pcn0
int_if=pcn1
set skip on lo
scrub in
rdr-anchor relayd/*
nat on $ext_if from (carp1:network) - (carp0:0)
block in log
pass out
pass quick on $int_if
pass quick on carp1
antispoof quick for { lo $int_if carp1}
pass quick proto carp
pass quick proto icmp
pass in on $ext_if proto tcp to ($ext_if) port ssh
pass quick proto tcp from any to any port http
I am using the 1 March snapshot now.
Wijnand
problems with hoststated and relayd
Hi,
this is the first time I play around with hoststated/relayd.
I have a stateful web application, and try to use hoststated/relayd in front
of it. Because the application is stateful, the client has to be redirected
to the same instance for the session lifetime. The session id is encoded as
GET parameter wosid. Further I have the problem that many of the users are
either sitting behind a proxy or a NAT'ed IP address, so these should not be
redirected to the same application instance.
I tried with hoststated on OpenBSD 4.2 i386 and with relayd on
OpenBSD -snapshot sparc64 from beginning of February 08.
I'm not sure, whether I see the same problems, as described here in that
thread:
http://www.nabble.com/relayd-http-check-connection-failures--hoststated-operates-correctly-to15646508.html
Well, I do not fiddle around with carp interfaces, and I also tried the
patch with the timeout, that did not fixed my problem.
First I tried to use relayd, until I came across above mentioned thread,
however, first I tried to setup a ssl accelerator as in the example:
ext_addr=10.0.0.24
ogo1=10.0.0.121
ogo2=10.0.0.122
ogo3=10.0.0.123
ogo4=10.0.0.124
ogo5=10.0.0.125
timeout
table ogohosts { $ogo1 $ogo2 $ogo3 $ogo4 $ogo5 }
http protocol httpssl {
header append $REMOTE_ADDR to X-Forwarded-For
header append $SERVER_ADDR:$SERVER_PORT to X-Forwarded-By
header change Connection to close
cookie hash wosid
url hash wosid
url log wosid
# Various TCP performance options
# tcp { nodelay, sack, socket buffer 65536, backlog 128 }
# ssl { no sslv2, sslv3, tlsv1, ciphers HIGH }
# ssl session cache disable
}
relay wwwssl {
# Run as a SSL accelerator
listen on $ext_addr port 443 ssl
protocol httpssl
# Forward to hosts in the webhosts table using a src/dst hash
forward to ogohosts port http mode hash \
check http / code 200
}
# relayd -d -vv -f /etc/relayd.conf
startup
init_filter: filter init done
init_tables: created 0 tables
relay_privinit: adding relay wwwssl
protocol 0: name httpssl
flags: 0x0004
type: http
request change Connection to close
request cookie hash wosid
request url hash wosid
request url log wosid
request append $SERVER_ADDR:$SERVER_PORT
to X-Forwarded-By
request append $REMOTE_ADDR to X-Forwarded-For
hce_notify_done: 10.0.0.121 (tcp_send_req: timeout)
relay_init: max open files 1024
relay_init: max open files 1024
host 10.0.0.121, check http code (9ms), state unknown - down, availability
0.00%
hce_notify_done: 10.0.0.122 (tcp_send_req: timeout)
host 10.0.0.122, check http code (51ms), state unknown - down, availability
0.00%
hce_notify_done: 10.0.0.123 (tcp_send_req: timeout)
host 10.0.0.123, check http code (52ms), state unknown - down, availability
0.00%
hce_notify_done: 10.0.0.124 (tcp_send_req: timeout)
host 10.0.0.124, check http code (53ms), state unknown - down, availability
0.00%
hce_notify_done: 10.0.0.125 (tcp_send_req: timeout)
host 10.0.0.125, check http code (53ms), state unknown - down, availability
0.00%
pfe_dispatch_imsg: state -1 for host 9 10.0.0.121
pfe_dispatch_imsg: state -1 for host 8 10.0.0.122
pfe_dispatch_imsg: state -1 for host 7 10.0.0.123
pfe_dispatch_imsg: state -1 for host 6 10.0.0.124
pfe_dispatch_imsg: state -1 for host 5 10.0.0.125
relay_ssl_ctx_create: loading certificate
relay_init: max open files 1024
relay_ssl_ctx_create: loading certificate
relay_ssl_ctx_create: loading certificate
relay_ssl_ctx_create: loading private key
relay_init: max open files 1024
adding 5 hosts from table ogohosts:80
relay_init: max open files 1024
relay_launch: running relay wwwssl
relay_ssl_ctx_create: loading private key
adding 5 hosts from table ogohosts:80
relay_ssl_ctx_create: loading private key
relay_launch: running relay wwwssl
adding 5 hosts from table ogohosts:80
relay_ssl_ctx_create: loading certificate
relay_launch: running relay wwwssl
relay_ssl_ctx_create: loading certificate
relay_ssl_ctx_create: loading private key
adding 5 hosts from table ogohosts:80
relay_ssl_ctx_create: loading private key
relay_launch: running relay wwwssl
adding 5 hosts from table ogohosts:80
relay_launch: running relay wwwssl
relay wwwssl, session 1 established (1 active)
relay_from_table: no active hosts
relay wwwssl, session 1 (1 active), 0, 10.0.0.9 - :80, session failed
relay wwwssl, session 2 established (1 active)
relay_from_table: no active hosts
relay wwwssl, session 2 (1 active), 0, 10.0.0.9 - :80, session failed
tcp_write: connect timed out
hce_notify_done: 10.0.0.124 (tcp_write: connect failed)
tcp_write: connect timed out
hce_notify_done: 10.0.0.125 (tcp_write: connect failed)
hce_notify_done: 10.0.0.121 (tcp_send_req: timeout)
hce_notify_done: 10.0.0.122 (tcp_send_req: timeout)
hce_notify_done: 10.0.0.123 (tcp_send_req: timeout)
