* ip_conntrack cleanup
@ 2002-05-21 7:33 Wojciech Sobola
2002-06-13 17:09 ` Antony Stone
2002-06-14 11:37 ` Jozsef Kadlecsik
0 siblings, 2 replies; 3+ messages in thread
From: Wojciech Sobola @ 2002-05-21 7:33 UTC (permalink / raw)
To: netfilter
Hello,
I've been using ipt 1.2.6a for 2 month's. There's seem to be a problem in /proc/net/ip_conntrack.
I have chains here, that can't be cleared out. Example:
tcp 6 321156 ESTABLISHED src=63.218.135.142 dst=62.xx.x.44 sport=63920 dport=80 [UNREPLIED] src=192.168.101.2
dst=63.218.135.142 sport=80 dport=63920 use=1
tcp 6 322238 ESTABLISHED src=63.218.135.142 dst=62.xx.x.45 sport=63920 dport=80 [UNREPLIED] src=62.xx.xx.45
dst=63.218.135.142 sport=80 dport=63920 use=1
tcp 6 322374 ESTABLISHED src=63.218.135.142 dst=62.xx.x.46 sport=63920 dport=80 [UNREPLIED] src=62.xx.xx.46
dst=63.218.135.142 sport=80 dport=63920 use=1
tcp 6 322240 ESTABLISHED src=63.218.135.142 dst=62.xx.x.45 sport=63921 dport=80 [UNREPLIED] src=62.xx.xx.45
dst=63.218.135.142 sport=80 dport=63921 use=1
tcp 6 322376 ESTABLISHED src=63.218.135.142 dst=62.xx.x.46 sport=63921 dport=80 [UNREPLIED] src=62.xx.xx.46
dst=63.218.135.142 sport=80 dport=63921 use=1
tcp 6 321842 ESTABLISHED src=63.218.135.142 dst=62.xx.x.47 sport=63920 dport=80 [UNREPLIED] src=62.xx.xx.47
dst=63.218.135.142 sport=80 dport=63920 use=1
tcp 6 322390 ESTABLISHED src=63.218.135.142 dst=62.xx.x.48 sport=63920 dport=80 [UNREPLIED] src=62.xx.xx.48
dst=63.218.135.142 sport=80 dport=63920 use=1
tcp 6 321843 ESTABLISHED src=63.218.135.142 dst=62.xx.x.47 sport=63921 dport=80 [UNREPLIED] src=62.xx.xx.47
dst=63.218.135.142 sport=80 dport=63921 use=1
tcp 6 321930 ESTABLISHED src=63.218.135.142 dst=62.xx.x.49 sport=63920 dport=80 [UNREPLIED] src=62.xx.xx.49
dst=63.218.135.142 sport=80 dport=63920 use=1
tcp 6 321930 ESTABLISHED src=63.218.135.142 dst=62.xx.x.49 sport=63921 dport=80 [UNREPLIED] src=62.xx.xx.49
dst=63.218.135.142 sport=80 dport=63921 use=1
tcp 6 321960 ESTABLISHED src=63.218.135.142 dst=62.xx.x.51 sport=63920 dport=80 [UNREPLIED] src=62.xx.xx.51
dst=63.218.135.142 sport=80 dport=63920 use=1
tcp 6 322328 ESTABLISHED src=63.218.135.142 dst=62.xx.x.52 sport=63920 dport=80 [UNREPLIED] src=62.xx.xx.52
dst=63.218.135.142 sport=80 dport=63920 use=1
tcp 6 322036 ESTABLISHED src=63.218.135.142 dst=62.xx.x.53 sport=63920 dport=80 [UNREPLIED] src=62.xx.xx.53
dst=63.218.135.142 sport=80 dport=63920 use=1
tcp 6 322096 ESTABLISHED src=63.218.135.142 dst=62.xx.x.54 sport=63920 dport=80 [UNREPLIED] src=62.xx.xx.54
dst=63.218.135.142 sport=80 dport=63920 use=1
tcp 6 322036 ESTABLISHED src=63.218.135.142 dst=62.xx.x.53 sport=63921 dport=80 [UNREPLIED] src=62.xx.xx.53
dst=63.218.135.142 sport=80 dport=63921 use=1
tcp 6 321518 ESTABLISHED src=63.218.135.142 dst=62.xx.x.55 sport=63920 dport=80 [UNREPLIED] src=62.xx.xx.55
dst=63.218.135.142 sport=80 dport=63920 use=1
tcp 6 322290 ESTABLISHED src=63.218.135.142 dst=62.xx.x.56 sport=63920 dport=80 [UNREPLIED] src=62.xx.xx.56
dst=63.218.135.142 sport=80 dport=63920 use=1
tcp 6 322022 ESTABLISHED src=63.218.135.142 dst=62.xx.x.57 sport=63920 dport=80 [UNREPLIED] src=62.xx.xx.57
dst=63.218.135.142 sport=80 dport=63920 use=1
tcp 6 322024 ESTABLISHED src=63.218.135.142 dst=62.xx.x.57 sport=63921 dport=80 [UNREPLIED] src=62.xx.xx.57
dst=63.218.135.142 sport=80 dport=63921 use=1
tcp 6 321565 ESTABLISHED src=63.218.135.142 dst=62.xx.x.58 sport=63920 dport=80 [UNREPLIED] src=62.xx.xx.58
dst=63.218.135.142 sport=80 dport=63920 use=1
tcp 6 321238 ESTABLISHED src=63.218.135.142 dst=62.xx.x.59 sport=63920 dport=80 [UNREPLIED] src=62.xx.xx.59
dst=63.218.135.142 sport=80 dport=63920 use=1
tcp 6 321342 ESTABLISHED src=63.218.135.142 dst=62.xx.x.60 sport=63920 dport=80 [UNREPLIED] src=62.xx.xx.60
dst=63.218.135.142 sport=80 dport=63920 use=1
tcp 6 321515 ESTABLISHED src=63.218.135.142 dst=62.xx.x.61 sport=63920 dport=80 [UNREPLIED] src=62.xx.xx.61
dst=63.218.135.142 sport=80 dport=63920 use=1
tcp 6 322192 ESTABLISHED src=63.218.135.142 dst=62.xx.x.62 sport=63920 dport=80 [UNREPLIED] src=62.xx.xx.62
dst=63.218.135.142 sport=80 dport=63920 use=1
tcp 6 321516 ESTABLISHED src=63.218.135.142 dst=62.xx.x.61 sport=63921 dport=80 [UNREPLIED] src=62.xx.xx.61
dst=63.218.135.142 sport=80 dport=63921 use=1
Such table can stay even 2 or 3 days. If I put DROP into INPUT or PREROUTING it doesn't change. Is this something suspicious?
Maybe there's setting which can be adjusted to stop such behavior? I can say that kernel is patched with freeswan-1.97.
Seems that connection was initiated by 192.168.101.2.
Regards,
--
Wojciech Sobola
Unix System Engineer
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: ip_conntrack cleanup
2002-05-21 7:33 ip_conntrack cleanup Wojciech Sobola
@ 2002-06-13 17:09 ` Antony Stone
2002-06-14 11:37 ` Jozsef Kadlecsik
1 sibling, 0 replies; 3+ messages in thread
From: Antony Stone @ 2002-06-13 17:09 UTC (permalink / raw)
To: netfilter
On Tuesday 21 May 2002 8:33 am, Wojciech Sobola wrote:
> Hello,
>
> I've been using ipt 1.2.6a for 2 month's. There's seem to be a problem in
> /proc/net/ip_conntrack. I have chains here, that can't be cleared out.
> Example:
> tcp 6 321156 ESTABLISHED src=63.218.135.142 dst=62.xx.x.44 sport=63920
> dport=80 [UNREPLIED] src=192.168.101.2 dst=63.218.135.142 sport=80
> dport=63920 use=1
>
> Such table can stay even 2 or 3 days.
The standard TCP timeout on an ESTABLISHED connection is 5 days. I have no
idea why this was once thought to be a good idea, but it is now in the
standards.
You could change it and recompile your kernel if you want, but this is the
reason you are seeing these connections for 2 or 3 days - they're not even
halfway to timing out yet :-)
Also, once a connection is in the conntrack table, you cannot get rid of it
by doing anything at all to your netfilter rules.
If you compiled modules you can remove and reinstall the ip_conntrack module,
but if you use a monolithic kernelonly a reboot willget these out of the
table.
Antony.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: ip_conntrack cleanup
2002-05-21 7:33 ip_conntrack cleanup Wojciech Sobola
2002-06-13 17:09 ` Antony Stone
@ 2002-06-14 11:37 ` Jozsef Kadlecsik
1 sibling, 0 replies; 3+ messages in thread
From: Jozsef Kadlecsik @ 2002-06-14 11:37 UTC (permalink / raw)
To: Wojciech Sobola; +Cc: netfilter
On Tue, 21 May 2002, Wojciech Sobola wrote:
> I have chains here, that can't be cleared out. Example:
> tcp 6 321156 ESTABLISHED src=63.218.135.142 dst=62.xx.x.44 sport=63920 dport=80 [UNREPLIED] src=192.168.101.2
> dst=63.218.135.142 sport=80 dport=63920 use=1
...
Looks like ACK-scanning of the network.
> Such table can stay even 2 or 3 days. If I put DROP into INPUT or
> PREROUTING it doesn't change. Is this something suspicious?
Existing conntrack entries cannot be deleted by iptable rules.
But those are harmless and will be time out later.
Regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
WWW-Home: http://www.kfki.hu/~kadlec
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2002-06-14 11:37 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-05-21 7:33 ip_conntrack cleanup Wojciech Sobola
2002-06-13 17:09 ` Antony Stone
2002-06-14 11:37 ` Jozsef Kadlecsik
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox