On Wed, Nov 30, 2005 at 10:20:07PM -0500, Miles Nordin wrote:
> Here are the rules I use for eDonkey.  UDP is different than TCP and I
> found to need two rules because you never know whether your end or the
> remote end is going to be the one to create the state entry.  I don't
> know exactly why what you see is happening, but I think it might help
> to make an extra 'nat' statement to nail down the NAT state tuple so
> the outgoing packet originates from the same specific port on the PF
> gateway as you are later using in the rdr rule, rather than from a
> dynamic port as it will if it matches the overall NAT rule.  In this

Well, I still don't understand what's going on, but your suggestion to
add an extra "nat" statement seems to have done the trick. I tried a
few variations (which all seemed to have worked), and settled on this:

table <phones> { 69.15.146.27, 69.15.146.28, 69.15.146.29 }

rdr pass on $ext_if proto udp from <phones> to any port 2093:2096 -> 10.1.1.11
nat on $ext_if proto udp from 10.1.1.11 port 2093:2096 to <phones> -> ($ext_if:0) static-port

It does seem to have something to do with the state entries, which
seems rather counter-intuitive to me. My understanding of keeping
state was that it was for passing packets that are associated with an
active "connection" even though they would normally be blocked by the
filter. In this case, my rule is explictly asking for certain packets
to be let through, but they're being blocked due to having (or not
having?) associated state?

Thanks for the hint :)
-- 
Name: Dave Huang         |  Mammal, mammal / their names are called /
INet: khym@azeotrope.org |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan         |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 30 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++