Hello,

I am having a few issues using round-robin sticky-addr for load balancing
outgoing connections over two tun interfaces. I've got two DSL lines which
I would like to route outgoing traffic over, using rules similar to the
following:

-- snip --

ext1_if="tun0"
ext2_if="tun1"
int_if="em0"
int_net="192.168.1.0/24"

set timeout src.track 38400

nat on $ext1_if from $int_net to any -> ($ext1_if)
nat on $ext2_if from $int_net to any -> ($ext2_if)

block in all
block out all

pass in on $int_if \
    route-to { ($ext1_if ($ext1_if:peer)), ($ext2_if, ($ext2_if:peer)) \
    round-robin sticky-address \
    from $int_net to any \
    keep state

pass out on $ext1_if all keep state
pass out on $ext2_if all keep state

pass out on $ext1_if \
    route-to ($ext2_if ($ext2_if:peer)) \
    from $ext2_if to any
pass out on $ext2_if \
    route-to ($ext1_if ($ext1_if:peer)) \
    from $ext1_if to any

-- snap --

This does not work as expected (at least not as how I would expect it to
work :). The routing target selection works fine at first glance
(selecting one target and creating a source track entry), however after
a while it will select another routing target for a source address which
exists in the tracking table - this process seems to come up randomly and
is documented by the log output when I set pf's log level to 'misc'.
Existing states seem not to be affected by this phenomena.

This is extremely annoying especially when people are using web applications
that tie sessions to source IP adresses getting booted every other minute.
For now, I've used a dirty hack: I've split up the internal network 
definition into two subnets and use two rules for internal traffic, one
routes to $ext1_if and the other to $ext2_if. My users can probably
live with it (as long as one line doesn't fail) but for me it's a rather
sub-optimal solution.

Is this expected behaviour of round-robin sticky-address, am I doing some-
thing utterly wrong or did I hit a bug? Any pointers would be appreciated.

OS used is OpenBSD 3.9/amd64.

Cheers,
Jann

Reply via email to