[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: load balance (rdr) with tables



Hi Daniel,

Based on your rule, it works fine if I do this:
rdr pass on $ext_if proto tcp from any to $ext_if port {25 80 110 143 443} -> <smtp> sticky-address


But if I do as specified in the pf FAQ, it doesn't:
rdr pass on $ext_if proto tcp from any to any port {25 80 110 143 443} -> <smtp> sticky-address


Is this the correct behaviour? tested on openbsd 3.6 as well with the same results.

thanks




----- Original Message ----- From: "Daniel Hartmeier" <[email protected]>
To: "Gustavo A. Baratto" <[email protected]>
Cc: <[email protected]>
Sent: Monday, January 17, 2005 4:05 PM
Subject: Re: load balance (rdr) with tables



On Mon, Jan 17, 2005 at 01:21:02PM -0800, Gustavo A. Baratto wrote:

So, it just looks like pf cannot match the rdr rule when a table is used.
Again, I'm using the version of PF that comes with freebsd 5.3.

It works for me on both OpenBSD 3.6-current and FreeBSD 5.3-stable.


Here's the ruleset I tried:

 table <rdrtest> persist { 127.0.0.1, 127.0.0.2 }
 rdr on em0 inet proto tcp from any to em0 port ssh \
     -> <rdrtest>
 pass all

(where 127.0.0.2 is an alias on lo0, ifconfig lo0 inet alias 127.0.0.2)

Then I establish (and close) several ssh connections through em0, and see

# pfctl -ss
self tcp 127.0.0.1:22 <- 10.1.1.111:22 <- 10.1.1.1:10090 FIN_WAIT_2:FIN_WAIT_2
self tcp 127.0.0.2:22 <- 10.1.1.111:22 <- 10.1.1.1:29848 FIN_WAIT_2:FIN_WAIT_2
self tcp 127.0.0.1:22 <- 10.1.1.111:22 <- 10.1.1.1:6638 FIN_WAIT_2:FIN_WAIT_2


(10.1.1.111 is em0's address, 10.1.1.1 the ssh client)

So the rdr rule is applying and replacing the destination address. It's
cycling through both addresses in the table (round-robin is default,
even if not specified, here). When I add 'sticky-address', I get the expected
stickyness based on source address.


There have been several bugfixes related to the code parts that select a
replacement address for translations. They have been merged back into
OpenBSD 3.6-stable and FreeBSD 5.3-stable. If you're not running a
recent 5.3-stable, please update (-rRELENG_5_3) and try again.

If you can't reproduce the problem with a simple test ruleset like mine
above, but can with your real ruleset, that would mean we should take a
closer look at the verbatim ruleset.

Daniel