Mailing List Archive: iptables: Devel

/proc/net/ip_conntrack trange behavior

Index | Next | Previous | View Threaded

Dong_Wei at nj

Aug 24, 2007, 12:43 AM

Post #1 of 12 (2872 views)
Permalink

/proc/net/ip_conntrack trange behavior

Hi, all
When I checked /proc/net/ip_conntrack in my Linux server, I found some
strange tracks like the following:

[normal case]
tcp 6 387113 ESTABLISHED src=219.135.189.40 dst=58.60.9.41
sport=2391 dport=443 src=58.60.9.41 dst=219.135.189.40 sport=443
dport=2391 [ASSURED] use=1

[strange track]
tcp 6 377231 ESTABLISHED src=222.173.17.207 dst=219.135.189.11
sport=19691 dport=3815 [UNREPLIED] src=219.135.189.11 dst=222.173.17.207
sport=3815 dport=19691 use=1

As we kown after SYN->SYN,ACK->ACK. TCP connection is in ESTABLISHED
state. and the ip_conntrack "see" the REPLY direction packet, I think
the conntrak should be ASSURED. not UNREPLIED.

So, pls help me. My kernel version is 2.4.22

Thanks in advance :-)

yasuyuki.kozakai at toshiba

Aug 29, 2007, 2:14 AM

Post #2 of 12 (2800 views)
Permalink

Re: /proc/net/ip_conntrack trange behavior [In reply to]

From: Dong_Wei <Dong_Wei [at] nj>
Date: Fri, 24 Aug 2007 15:43:01 +0800

> Hi, all
> When I checked /proc/net/ip_conntrack in my Linux server, I found some
> strange tracks like the following:
>
> [normal case]
> tcp 6 387113 ESTABLISHED src=219.135.189.40 dst=58.60.9.41
> sport=2391 dport=443 src=58.60.9.41 dst=219.135.189.40 sport=443
> dport=2391 [ASSURED] use=1
>
> [strange track]
> tcp 6 377231 ESTABLISHED src=222.173.17.207 dst=219.135.189.11
> sport=19691 dport=3815 [UNREPLIED] src=219.135.189.11 dst=222.173.17.207
> sport=3815 dport=19691 use=1
>
> As we kown after SYN->SYN,ACK->ACK. TCP connection is in ESTABLISHED
> state. and the ip_conntrack "see" the REPLY direction packet, I think
> the conntrak should be ASSURED. not UNREPLIED.
>
> So, pls help me. My kernel version is 2.4.22
>
> Thanks in advance :-)
>

When only SYN and SYN/ACK are detected by ip_conntrack, the state of the
connection is ESTABLISHED. Please note that 'ESTABLISHED' is not TCP state,
but generic connection state.

-- Yasuyuki Kozakai

kaber at trash

Aug 29, 2007, 11:49 AM

Post #3 of 12 (2800 views)
Permalink

Re: /proc/net/ip_conntrack trange behavior [In reply to]

Yasuyuki KOZAKAI wrote:
> From: Dong_Wei <Dong_Wei [at] nj>
> Date: Fri, 24 Aug 2007 15:43:01 +0800
>
>> Hi, all
>> When I checked /proc/net/ip_conntrack in my Linux server, I found some
>> strange tracks like the following:
>>
>> [normal case]
>> tcp 6 387113 ESTABLISHED src=219.135.189.40 dst=58.60.9.41
>> sport=2391 dport=443 src=58.60.9.41 dst=219.135.189.40 sport=443
>> dport=2391 [ASSURED] use=1
>>
>> [strange track]
>> tcp 6 377231 ESTABLISHED src=222.173.17.207 dst=219.135.189.11
>> sport=19691 dport=3815 [UNREPLIED] src=219.135.189.11 dst=222.173.17.207
>> sport=3815 dport=19691 use=1
>>
>> As we kown after SYN->SYN,ACK->ACK. TCP connection is in ESTABLISHED
>> state. and the ip_conntrack "see" the REPLY direction packet, I think
>> the conntrak should be ASSURED. not UNREPLIED.
>>
>> So, pls help me. My kernel version is 2.4.22
>>
>> Thanks in advance :-)
>>
>
> When only SYN and SYN/ACK are detected by ip_conntrack, the state of the
> connection is ESTABLISHED. Please note that 'ESTABLISHED' is not TCP state,
> but generic connection state.

Well, its TCP connection state. Whats probably happening is that you
have connection pickup enabled, in which case a single ACK can lead
to TCP ESTABLISHED state. It won't match "-m state --state ESTABLISHED"
though.

Dong_Wei at nj

Aug 29, 2007, 6:14 PM

Post #4 of 12 (2793 views)
Permalink

Re: /proc/net/ip_conntrack trange behavior [In reply to]

Thanks a lot. Yasuyuki and kaber

I have looked the 2.6.20 kernel and found that the reason.

When ip_conntrack try to pick up an ESTABLISHED TCP connection, this
issue will happen.

2.6 set an 'sysctl' value to deal with this situation

static int tcp_new()
{
...snip...
if (new_state == TCP_CONNTRACK_SYN_SENT) {
do_something();
} else if (ip_ct_tcp_loose == 0) {
/* Don't try to pick up connections. */
return 0;
} else {
do_something();
}
}

And we can't avoid this issue on 2.4, because no code deal with the
special case.

Thanks!

> Yasuyuki KOZAKAI wrote:
>> From: Dong_Wei <Dong_Wei [at] nj>
>> Date: Fri, 24 Aug 2007 15:43:01 +0800
>>
>>> Hi, all
>>> When I checked /proc/net/ip_conntrack in my Linux server, I found
>>> some strange tracks like the following:
>>>
>>> [normal case]
>>> tcp 6 387113 ESTABLISHED src=219.135.189.40 dst=58.60.9.41
>>> sport=2391 dport=443 src=58.60.9.41 dst=219.135.189.40 sport=443
>>> dport=2391 [ASSURED] use=1
>>>
>>> [strange track]
>>> tcp 6 377231 ESTABLISHED src=222.173.17.207 dst=219.135.189.11
>>> sport=19691 dport=3815 [UNREPLIED] src=219.135.189.11 dst=222.173.17.207
>>> sport=3815 dport=19691 use=1
>>>
>>> As we kown after SYN->SYN,ACK->ACK. TCP connection is in ESTABLISHED
>>> state. and the ip_conntrack "see" the REPLY direction packet, I think
>>> the conntrak should be ASSURED. not UNREPLIED.
>>>
>>> So, pls help me. My kernel version is 2.4.22
>>>
>>> Thanks in advance :-)
>>>
>>
>> When only SYN and SYN/ACK are detected by ip_conntrack, the state of the
>> connection is ESTABLISHED. Please note that 'ESTABLISHED' is not TCP
>> state,
>> but generic connection state.
>
>
> Well, its TCP connection state. Whats probably happening is that you
> have connection pickup enabled, in which case a single ACK can lead
> to TCP ESTABLISHED state. It won't match "-m state --state ESTABLISHED"
> though.
>

kaber at trash

Aug 29, 2007, 11:49 PM

Post #5 of 12 (2788 views)
Permalink

Re: /proc/net/ip_conntrack trange behavior [In reply to]

Dong_Wei wrote:
> Thanks a lot. Yasuyuki and kaber
>
> I have looked the 2.6.20 kernel and found that the reason.
>
> When ip_conntrack try to pick up an ESTABLISHED TCP connection, this
> issue will happen.

Exactly.

> 2.6 set an 'sysctl' value to deal with this situation
>
> [..]
>
> And we can't avoid this issue on 2.4, because no code deal with the
> special case.

Thats correct. Is there a problem with this behaviour?

Dong_Wei at nj

Aug 30, 2007, 2:48 AM

Post #6 of 12 (2790 views)
Permalink

Re: /proc/net/ip_conntrack trange behavior [In reply to]

Hi Yasuyuki san

> Dong_Wei wrote:
>> Thanks a lot. Yasuyuki and kaber
>>
>> I have looked the 2.6.20 kernel and found that the reason.
>>
>> When ip_conntrack try to pick up an ESTABLISHED TCP connection, this
>> issue will happen.
>
>
> Exactly.
>
>> 2.6 set an 'sysctl' value to deal with this situation
>>
>> [..]
>>
>> And we can't avoid this issue on 2.4, because no code deal with the
>> special case.
>
>
> Thats correct. Is there a problem with this behaviour?

As we know, ip_conntrack has a hash_size to control the ip_conntrack
record size. and if tcp in ESTABLISH, and ip_conntrack will keep it for
5 DAYs.

For exsample, a NAT server can handle 8000 connections, and if sometime,
NAT server need reboot(6000 conntrack in ESTBLISHED state now). Also we
set ip_conntrack allowing pickup ESTABLISHED tcp connection, when NAT
server available again, ip_conntrack will take 6000 conntracks for the
original connections. but actully these connections are INVALID for the
web server, because the source ip is the private IPs,such as
192.168.0.1. and web server will not answer the client's request. But
still the NAT server will keep the 6000 conntrack for 5 DAYs. And just
2000 conntracks can be used for the clients. If more than 2000 client
want connect to some websites, some ip_conntrack will be droped.

BR. DongWei

kaber at trash

Aug 31, 2007, 1:45 AM

Post #7 of 12 (2789 views)
Permalink

Re: /proc/net/ip_conntrack trange behavior [In reply to]

On Thu, 30 Aug 2007, Dong_Wei wrote:

>>> And we can't avoid this issue on 2.4, because no code deal with the
>>> special case.
>>
>>
>> Thats correct. Is there a problem with this behaviour?
>
> As we know, ip_conntrack has a hash_size to control the ip_conntrack record
> size. and if tcp in ESTABLISH, and ip_conntrack will keep it for 5 DAYs.
>
> For exsample, a NAT server can handle 8000 connections, and if sometime, NAT
> server need reboot(6000 conntrack in ESTBLISHED state now). Also we set
> ip_conntrack allowing pickup ESTABLISHED tcp connection, when NAT server
> available again, ip_conntrack will take 6000 conntracks for the original
> connections. but actully these connections are INVALID for the web server,
> because the source ip is the private IPs,such as 192.168.0.1. and web server
> will not answer the client's request. But still the NAT server will keep the
> 6000 conntrack for 5 DAYs. And just 2000 conntracks can be used for the
> clients. If more than 2000 client want connect to some websites, some
> ip_conntrack will be droped.

You can drop ACK packets in state NEW to avoid connection pickup.

Dong_Wei at nj

Aug 31, 2007, 2:59 AM

Post #8 of 12 (2788 views)
Permalink

Re: /proc/net/ip_conntrack trange behavior [In reply to]

Hi Patrick

> On Thu, 30 Aug 2007, Dong_Wei wrote:
>
>>>> And we can't avoid this issue on 2.4, because no code deal with the
>>>> special case.
>>>
>>>
>>> Thats correct. Is there a problem with this behaviour?
>>
>> As we know, ip_conntrack has a hash_size to control the ip_conntrack
>> record size. and if tcp in ESTABLISH, and ip_conntrack will keep it
>> for 5 DAYs.
>>
>> For exsample, a NAT server can handle 8000 connections, and if
>> sometime, NAT server need reboot(6000 conntrack in ESTBLISHED state
>> now). Also we set ip_conntrack allowing pickup ESTABLISHED tcp
>> connection, when NAT server available again, ip_conntrack will take
>> 6000 conntracks for the original connections. but actully these
>> connections are INVALID for the web server, because the source ip is
>> the private IPs,such as 192.168.0.1. and web server will not answer
>> the client's request. But still the NAT server will keep the 6000
>> conntrack for 5 DAYs. And just 2000 conntracks can be used for the
>> clients. If more than 2000 client want connect to some websites, some
>> ip_conntrack will be droped.
>
>
> You can drop ACK packets in state NEW to avoid connection pickup.
That's a good idea, I will make a patch for my own 2.4 Linux NAT server,
thanks a lot :-)

ole at ans

Aug 31, 2007, 8:09 AM

Post #9 of 12 (2787 views)
Permalink

Re: /proc/net/ip_conntrack trange behavior [In reply to]

On Fri, 31 Aug 2007, Dong_Wei wrote:

> Hi Patrick
>
>> On Thu, 30 Aug 2007, Dong_Wei wrote:
>>
>>>>> And we can't avoid this issue on 2.4, because no code deal with the
>>>>> special case.
>>>>
>>>>
>>>> Thats correct. Is there a problem with this behaviour?
>>>
>>> As we know, ip_conntrack has a hash_size to control the ip_conntrack
>>> record size. and if tcp in ESTABLISH, and ip_conntrack will keep it for 5
>>> DAYs.
>>>
>>> For exsample, a NAT server can handle 8000 connections, and if sometime,
>>> NAT server need reboot(6000 conntrack in ESTBLISHED state now). Also we
>>> set ip_conntrack allowing pickup ESTABLISHED tcp connection, when NAT
>>> server available again, ip_conntrack will take 6000 conntracks for the
>>> original connections. but actully these connections are INVALID for the
>>> web server, because the source ip is the private IPs,such as 192.168.0.1.
>>> and web server will not answer the client's request. But still the NAT
>>> server will keep the 6000 conntrack for 5 DAYs. And just 2000 conntracks
>>> can be used for the clients. If more than 2000 client want connect to some
>>> websites, some ip_conntrack will be droped.
>>
>>
>> You can drop ACK packets in state NEW to avoid connection pickup.
> That's a good idea, I will make a patch for my own 2.4 Linux NAT server,
> thanks a lot :-)

No need to, as all you should do is a proper iptables rule.

Best regards,

Krzysztof Ol�dzki

Dong_Wei at nj

Sep 2, 2007, 8:34 PM

Post #10 of 12 (2777 views)
Permalink

Re: /proc/net/ip_conntrack trange behavior [In reply to]

Hi

> On Fri, 31 Aug 2007, Dong_Wei wrote:
>
>> Hi Patrick
>>
>>> On Thu, 30 Aug 2007, Dong_Wei wrote:
>>>
>>>>>> And we can't avoid this issue on 2.4, because no code deal with
>>>>>> the special case.
>>>>>
>>>>>
>>>>> Thats correct. Is there a problem with this behaviour?
>>>>
>>>> As we know, ip_conntrack has a hash_size to control the ip_conntrack
>>>> record size. and if tcp in ESTABLISH, and ip_conntrack will keep it
>>>> for 5 DAYs.
>>>>
>>>> For exsample, a NAT server can handle 8000 connections, and if
>>>> sometime, NAT server need reboot(6000 conntrack in ESTBLISHED state
>>>> now). Also we set ip_conntrack allowing pickup ESTABLISHED tcp
>>>> connection, when NAT server available again, ip_conntrack will take
>>>> 6000 conntracks for the original connections. but actully these
>>>> connections are INVALID for the web server, because the source ip is
>>>> the private IPs,such as 192.168.0.1. and web server will not answer
>>>> the client's request. But still the NAT server will keep the 6000
>>>> conntrack for 5 DAYs. And just 2000 conntracks can be used for the
>>>> clients. If more than 2000 client want connect to some websites,
>>>> some ip_conntrack will be droped.
>>>
>>>
>>> You can drop ACK packets in state NEW to avoid connection pickup.
>> That's a good idea, I will make a patch for my own 2.4 Linux NAT
>> server, thanks a lot :-)
>
> No need to, as all you should do is a proper iptables rule.
what kind of rules should I take? It's seemed that there is no rule to
deal with this special case on 2.4 :(

> Best regards,
>
> Krzysztof Ol�dzki

philipc at snapgear

Sep 2, 2007, 9:03 PM

Post #11 of 12 (2778 views)
Permalink

Re: /proc/net/ip_conntrack trange behavior [In reply to]

Dong_Wei wrote:
> what kind of rules should I take? It's seemed that there is no rule to
> deal with this special case on 2.4 :(

$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

(From http://iptables-tutorial.frozentux.net/iptables-tutorial.html#NEWNOTSYN)

Dong_Wei at nj

Sep 2, 2007, 10:11 PM

Post #12 of 12 (2772 views)
Permalink

Re: /proc/net/ip_conntrack trange behavior [In reply to]

> Dong_Wei wrote:
>> what kind of rules should I take? It's seemed that there is no rule to
>> deal with this special case on 2.4 :(
>
> $IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
Thanks a lot Philip :)

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads