Xiong Wu wrote:
> Hi,
>
> I have to reject some connection which are confirmed, therefor I apply
> the following patch to solve this problem. Please help me to review
> this patch.
As I said, this doesn't work properly since conntrack can't associate
packets generated in response to half-way NATed packets with the
original connection.
The manual conntrack association is necessary, you need to find a way
to make the packet visible to TCP conntrack. I think what might work
is to change the condition ignoring already-tracked packets in
nf_conntrack to only ignore packets using either nf_conntrack_untracked
or received in NF_INET_PRE_ROUTING.
> --- linux-2.6.32.3/net/ipv4/netfilter/ipt_REJECT.c 2010-01-07
> 07:07:45.000000000 +0800
> +++ linux-2.6.32.3-new/net/ipv4/netfilter/ipt_REJECT.c 2010-01-10
> 21:18:11.000000000 +0800
> @@ -23,6 +23,7 @@
> #include <linux/netfilter/x_tables.h>
> #include <linux/netfilter_ipv4/ip_tables.h>
> #include <linux/netfilter_ipv4/ipt_REJECT.h>
> +#include <include/net/netfilter/nf_conntrack.h>
> #ifdef CONFIG_BRIDGE_NETFILTER
> #include <linux/netfilter_bridge.h>
> #endif
> @@ -40,6 +41,9 @@
> const struct tcphdr *oth;
> struct tcphdr _otcph, *tcph;
> unsigned int addr_type;
> + enum ip_conntrack_info ctinfo;
> + const struct nf_conn *ct;
> +
>
> /* IP header checks: fragment. */
> if (ip_hdr(oldskb)->frag_off & htons(IP_OFFSET))
> @@ -120,7 +124,12 @@
> if (nskb->len > dst_mtu(skb_dst(nskb)))
> goto free_nskb;
>
> - nf_ct_attach(nskb, oldskb);
> + /*only when the ct isn't confirmed, attach it to reset packet*/
> + ct = nf_ct_get(skb, &ctinfo);
> + if((ct != NULL) && (!nf_ct_is_confirmed(ct)))
> + {
> + nf_ct_attach(nskb, oldskb);
> + }
>
> ip_local_out(nskb);
> return;
>
> Thanks,
> Xiong
>
> 2010/1/4 Patrick McHardy <kaber@xxxxxxxxx>:
>> 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
