On Fri, 30 Jul 2010, Pascal Hambourg wrote: > Jozsef Kadlecsik a ?crit : > > > > I don't see why it looks soo complicated: of course, a ct entry is created > > by conntrack whenever a new connection is detected. And of course the > > entry is destroyed if the packet, which triggered to create the new entry, > > is dropped by a rule. Why should the conntrack entry be kept, if the > > connection is not allowed by the rules? > > > > The new ct entries are kept in the unconfirmed list and only added to the > > conntrack hash iff the entry will be confirmed, that is the entry-creating > > packet won't be dropped by a rule. > > Thanks for this explanation. Just one more clarification, please : is > the conntrack entry destroyed also if the packet which triggered its > creation is dropped by something else than an iptables rule, such as > routing decision, TTL exceeded, conflict with an existing NAT mapping ? Yes, if any other subsystem drop the packet, the conntrack entry is destroyed as well. The first packet must pass through (forwarded or delivered to a local process), otherwise the ct entry is just created and then destroyed. Unfortunately, without a massive redesign of the whole system, we cannot get rid of this unfortunate create/destroy ct entry cycle. Best regards, Jozsef - E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlec@xxxxxxxxxxxx PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
