Curby wrote:
Julian and Vadim, thank you both for your replies.  Here's a really old quote:

"The ip_input() routine in the kernel then dequeues the packet,
performs sanity checks on the packet and determines the destination
for the packet. If the destination is the local computer, the kernel
will perform packet reassembly. "

The firewall is the first thing ip_input does. it happens BEFORE reassembly.


from http://usenix.net/events/bsdcon02/full_papers/lidl/lidl_html/index.html

Also, this poster is less sure but suggests that this might happen:
http://osdir.com/ml/freebsd.isp/2003-02/msg00091.html

he says "I think" and he's wrong.  check netinet/ip_input.c


I also think that Linux iptables only sees reassembled packets (at
least some of the time, e.g. when it is legitimate traffic destined
for the host itself), so this isn't altogether wild and crazy.

maybe, but you are asking about FreeBSD


If in fact reassembly does not happen, I should remove that rule as
frags will likely not match using a check-state rule because they lack
tcp/udp header information.  Is there a way in ipfw to allow frags
that claim to be related to a known-good first frag but drop others?
Something like check-state but for fragments 1 and above, in other
words.

not in ipfw. you might check pf and ipf


The odd thing is that I didn't see any dropped packets in my logs or
notice any disrupted traffic (e.g. in a web browser) before this
conference, where frags were suddenly flying all over.  Thanks again
for your help!

frags are usually the result of tunnelling.
People at a conference often have tunnels running.


--Mike
_______________________________________________
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

_______________________________________________
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to