On Fri, Mar 07, 2003 at 11:45:16AM -0500, Pete Toscano wrote:
> Anybody have any ideas? Am I using scrub incorrectly? Should I be
> using scrub? Is there something else I'm doing wrong? Is there any
> other potentially useful information I forgot to give?
Your ruleset looks fine, that's exactly how it should work (rdr on
external, nat on internal, scrub on both).
> ===== ...and replies to it. This is where the frag begins.
> 14:33:26.784417 DD.DD.DD.DD > II.II.II.II: (frag 55914:[EMAIL PROTECTED])
> 14:33:26.784437 DD.DD.DD.DD.5353 > II.II.II.II.56175: udp 1643 (frag 55914:[EMAIL
> PROTECTED])
> ===== Nat receives the two reply fragments
> 14:33:26.951181 DD.DD.DD.DD.5353 > II.II.II.II.56175: udp 1643 (frag 55914:[EMAIL
> PROTECTED])
> 14:33:26.951195 DD.DD.DD.DD > II.II.II.II: (frag 55914:[EMAIL PROTECTED])
> ===== Nothing goes out Nat's external interface
It must be somehow related to the fragmentation. For some reason, the pf
box is not reassembling the fragments. To determine the reason, can you
a) enable debug logging with pfctl -x m, and check /var/log/messages
for entries related to pf fragment reassembly? Ideally, quote all
lines related to one packet's fragments being reassembled.
b) get a tcpdump -nvvvXSpi $IntIF output from the pf box for all
fragments of a single packet.
One possible explanation would be if the fragments have the DF (don't
fragment) flag set. pf, prior to -current as of a few weeks ago, drops
them unconditionally. If that's the problem, you could try a snapshot
(which is stable, now that we approach 3.3-release). If not, hopefully
the additional output from above shows something.
Daniel
