Xiong Wu wrote:
> Hi All,
>
> I found the TCP RST packet sent from ipt_REJECT target isn't able to
> update related conntrack state.
>
> I install a 2.6.30.10 kernel as a router and add a iptables rule with
> REJECT target to reset specific connections. However I found when
> the packets is handled by the ipt_REJECT and the TCP RST packet is
> sent, the related conntrack state isn't updated to CLOSE state.
>
> Then I review the ipt_REJECT codes. I found the target attach the old
> conntrack to RST packet as:
> {
> nf_ct_attach(nskb, oldskb);
> ip_local_out(nskb);
> }
>
> Therefor the nf_conntrack_in() will ignore this RST packet due to the
> nfct is valid in skb.
> {
> if (skb->nfct) {
> NF_CT_STAT_INC_ATOMIC(net, ignore);
> return NF_ACCEPT;
> }
> }
>
>
> Is there any reason to attach the old conntrack to new RST skb? I
> think let the RST packet lookup and update related conntrack is
> better.
The packet that is rejected might be half-way mangled by NAT (DNAT
performed, SNAT not yet performed). In this state conntrack is
be unable to associate the generated RST packet with the conntrack
entry. The same applies when you reject the first packet of a
connection which hasn't entered the hash tables yet.
Usually this shouldn't be a problem exactly because you would
normally reject the first packet of a connection, so it wouldn't
be placed in the conntrack hash.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
