Re: miscellaneous netfilter questions

[Pascal Hambourg <pascal.mail@plouf.fr.eu.org>]

Christoph Anton Mitterer a écrit :
> 
>> For IPv4, indeed when conntrack is enabled incoming fragmented datagrams
>> are reassembled before the PREROUTING chains. Note that packets which
>> are to be delivered locally are reassembled by the stack (not by
>> conntrack) before the INPUT chains anyway, so you never see fragments in
>> INPUT chains.
> ok... well...
> a) What about packages not delivered locally? I assume they're simply
> passed on in the fragmented state as they are? Is this always the case?

Yes, unless conntrack is enabled.

> E.g. if the next hop network as an MTU that is smaller than the fragment
> size?

Some time ago I had observed on 2.4 kernels that packets which are too
big with DF=0 are fragmented to fit the MTU after the FORWARD chain.
However if nat is enabled, datagrams are reassembled again in
nat/POSTROUTING and fragmented again afterwards. I did not check whether
it is the same on 2.6 kernels or it was optimized in order to reassemble
and fragment only once at most.

> b) All these things which you say that are happening on the stack (e.g.
> the defragmentation here, dropping of packets with bogus addresses or
> source addresses that match the address of a local interface)... these
> things generally happen _before_ netfilter, right? Or at which place are
> they happening?

They happen at different stages of the packet path, betweek netfilter
hooks. Netfilter and the rest of the stack are interleaved. E.g, the
input routing decision is between PREROUTING and INPUT/FORWARD. Diagrams
are available throughout the web.

>> AFAIK things work a bit differently for IPv6 : fragmented datagrams are
>> "virtually" reassembled for conntrack (the reason being that an IPv6
>> router does not handle fragmentation/reassembly), but continue to exist
>> as fragments through the ip6tables chains and the IPv6 stack.
> Ah... I see... uhm... in this case, how would the following work?
> Image one wants to allow incomming packets for ssh so we have about:
> :INPUT DROP
> -A INPUT --protocol tcp -m tcp --destination-port ssh -j ACCEPT
> 
> Now packets come in fragmented,... this would not work for later
> fragments right, as the port is not known... so as soon as fragmentation
> happens, the above would not work (as expected).

I guess so. However IPv6 deprecates fragmentation by routers and makes
path MTU discovery mandatory, so fragmentation with TCP should be very
uncommon.

> But it should work with those rules:
> :INPUT DROP
> -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> -A INPUT --protocol tcp -m tcp --destination-port ssh --syn -j ACCEPT
> 
> ..because contrack still works, and the fragmented packets are accepted
> by the first rule.
> 
> Do I understand this correctly?

I guess so. However I haven't played much with IPv6 conntrack yet,
although I use IPv6.