Jan Engelhardt a écrit : > On Thursday 2010-07-29 14:34, Pascal Hambourg wrote: >>>> Trying 127.0.0.1... >>>> [NEW] tcp 6 120 SYN_SENT src=127.0.0.1 dst=127.0.0.1 >>>> sport=59734 dport=23 [UNREPLIED] src=127.0.0.1 dst=127.0.0.1 sport=23 >>>> dport=59734 >>>> >>>> ...seconds later... >>>> # conntrack -L | grep =23 >>>> conntrack v0.9.14 (conntrack-tools): 12 flow entries have been shown. >>>> tcp 6 97 SYN_SENT src=127.0.0.1 dst=127.0.0.1 sport=59734 >>>> dport=23 packets=1 bytes=60 [UNREPLIED] src=127.0.0.1 dst=127.0.0.1 >>>> sport=23 dport=59734 packets=0 bytes=0 mark=0 secmark=0 use=2 >>>> >>>> 2 minutes it is. >> >> That's because it is a locally generated connection, so the conntrack >> confirm takes place after POSTROUTING. Even though the packet is dropped >> in INPUT after it is looped back, the conntrack entry is already >> confirmed. Now try again with the DROP rule in OUTPUT, or from a remote >> host. > > But the ct entry must undoubtly exist to be able to match -m conntrack > --ctstate NEW. Perhaps it's just that conntrack(8) won't show it? I don't know how things work internally [1], but from the outside it seems to me that the conntrack entry exists only until the packet is dropped, i.e. very briefly. [1] I can read C, but that does not mean I can understand the thousands of lines of the kernel source code. -- 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
