Indeed, I've only seen it happen after we got the system into production, when there were a lot of connections going through. As I understand from quickly reading the RFC, the mpath routing algorithm tries to keep the same path, unless things change, so it's likely not gonna show up in a lab.
Anyway, I think I found the answer, it's in the thread you linked too and pretty clearly explained in pf.conf's man page (the *Routing* section even, who would've guessed, eh?):
Code:
reply-to
The reply-to option is similar to route-to, but routes packets that
pass in the opposite direction (replies) to the specified
interface. Opposite direction is only defined in the context of a
state entry, and reply-to is useful only in rules that create
state. It can be used on systems with multiple external
connections to route all outgoing packets of a connection through
the interface the incoming connection arrived through (symmetric
routing enforcement).
Maybe I should test more, but for now it seems to work fine. So, basically, this line:
Code:
pass in on $ext1_if proto tcp to $www_out port $www_tcp_ports rdr-to $www_in
becomes:
Code:
pass in on $ext1_if proto tcp to $www_out port $www_tcp_ports rdr-to $www_in reply-to ($ext1_if $ext1_gw)
or, in my actual case:
Code:
match in on $ext1_if proto tcp to $www_out port $www_tcp_ports rdr-to $www_in
[... other rules ...]
pass in on $ext1_if proto tcp to $www_in port $www_tcp_ports reply-to ($ext1_if $ext1_gw)
$www_out is the public IP of the webserver, $www_in is the private one. In this second case the pass rule has the internal address of the webserver, the packet is already headed to 192.168.x.x by the time it gets to it. Guess match rules actually change the packets, didn't know that, thought it would only happen after the pass rule.
Well, maybe it'll help some future googler.
Thanks, all seems good for now, even though I didn't get to do much testing, I'll se what else pops up. Mpath + NAT works for me.