>>>> pass out quick on le0 to le1:ne.xt.h.op from 10.0.0.0/8 to any
>>> I had thought that only worked for "dup-to" [...]
>> The doc says "optionally with the destination IP address changed to
>> that specified".  This sounds to me as though it rewrites ip_dst in
>> the packet (which seems to me to be the Wrong Thing, even for
>> dup-to).
> Well you could, heaven forbid, try it and see if it does.

Yes, I could.  If I cared enough to use the implementation to make up
for the lacunae in the documentation I'd probably read the code,
though, rather than trying it.

Y'see, I don't directly care about it myself.  I got mail from a friend
at an ISP asking questions about IP tunneling, which I had done more
with than the friend.  In the exchange that followed, I mentioned my
srt interface, which is designed specifically to permit making routing
decisions based on ip_src addresses.  The friend acted interested,
saying that they (the ISP) had a customer that wanted functionality
like that.

Then, probably less than a day later, I was reading through the ipf doc
to find out how to do "block in quick on le1 from any to 10.0.0.0/8",
and happened to see the fastroute option.  I realized this provided
functionality similar to srt - but then I noticed that part of setting
up an srt pseudo-route involves setting the next-hop address, and there
was no indication of how one did this with ipf's fastroute.

My first message on tech-net was asking whether there was any way; I
was imagining that maybe it used the same next-hop gateway address that
the packet was originally headed for, or something.  Then, after seeing
that a way existed, when whoever it was (Greg Woods I think?) mentioned
dup-to, I read up on that; my next message was really more akin to a
doc-bug report than anything else.

/~\ 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