Hi Pascal. Thanks in advance for your detailed answers :) On Wed, 2010-03-03 at 17:57 +0100, Pascal Hambourg wrote: > Packets processed with the NOTRACK target have the UNTRACKED state. Ah, nice,... this is not described in the manpage (at least not in Debian's 1.4.6 package of iptables). Perhaps one should add this? > > Or is it all the addresses which the kernel thinks the host has itself, e.g. > The latter, I guess. I looked through some source files of the kernel and iptables,.. but was not able to really find a definite answer on this... seems to be "hidden" (well at least to me) ^^ > > a) It's quite clear what happens if one uses "-f" or "! -f" but what > > happens if neither of the tow is give? Does it mean "! -f" or is it > > like "match not fragmented packets AND fragmented packets (both the > > first AND further fragments). > The latter, obviously. All packets are matched regardless of fragmentation. Not sure whether this is really so obvious,... anyway, perhaps this could also be added to the manpage... e.g. for -o and -i it says what happens if the options are omitted. :) > 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? E.g. if the next hop network as an MTU that is smaller than the fragment size? 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? > 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). 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? Thanks again, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
