>> But if a connection arrives on 10.100.1.5, things are less good.
>> 10.101.0.4 hears about it, and it looks right from its point of
>> view, but the response traffic goes out ex0, presumably because
>> that's where the default route points, despite coming from
>> 10.100.1.5, despite the state table entry and state-policy, despite
>> even the pass line trying to send it out rtk0!
> I'm picking an example external address as source.  [...]

> So the src 10.101.0.4 is never translated back, and 62.65.145.30 gets
> a reply from 10.101.0.4, which it will ignore.

This is not what I'm seeing.  The return packet makes it back out with
its ip_src correctly NATted; the connection 'works".  The only thing
wrong with it is that the return traffic uses the wrong interface.

> The most common solution is to make the state created from step 1 not
> if-bound, but floating, so it matches replies attempting to go out
> through ex0.

> Then, add an explicit pass rule for the initial packet creating that
> state, and add 'reply-to' there.

Switching to floating state policy and using a reply-to pass rule makes
it behave exactly the way I wanted.  I must have missed reply-to in my
various readings-over of the pf docs.  (I'm actually using a tag clause
on the rdr and a tagged clause on the pass, rather than depending on
addresses.)

This is most excellent.  Thank you very much.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B