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? -- 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
