--pgp-sign-Multipart_Wed_Nov_30_22:19:57_2005-1
Content-Type: text/plain; charset=US-ASCII

>>>>> "dh" == Dave Huang <khym@azeotrope.org> writes:

    dh> rdr pass on $ext_if proto udp from any to any port 2093:2096
    dh> -> 10.1.1.11 port 2093:*

try 'pfctl -s state' and see if it shows anything interesting.

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
case, if the first packet activates the nat rule first rather than
rdr, the rdr rule will never be matched by traffic coming back in, but
you will sort of experience the same effect as if it were.  dunno if
that makes sense, but consider my two rules if they make sense to you,
and try the 'pfctl -s state' or the pftop package.

rdr on $innurnet4 inet proto udp from any to $natsrc port 4672 \
        -> 192.168.1.101 port 4672
nat on $innurnet4 inet proto udp from 192.168.1.101 port 4672 to any -> \
        $natsrc port 4672

--pgp-sign-Multipart_Wed_Nov_30_22:19:57_2005-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)

iQCVAwUAQ45r54nCBbTaW/4dAQL4wQP7B9lpvALknklpDw5J5eicrP1iQcU+mN+e
hPyp54/eSAY1ddEGoeLaSuzvQPJZ2zIlrCCorXzqh/332YnHuCilwzejIPsgBo4X
Ir6I54p21mXiHD1IqZat7/sXb+zgkHszlhKeqckhGF3EBQXR5JrjU8A/mVmJXpq6
FysdYvlWlNw=
=UGf2
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Wed_Nov_30_22:19:57_2005-1--