Fwd: Fragmented Packet Reassembly and IPFW2

[Julian Elischer]

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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe at freebsd.org"