ip_conntrack growing indefinitely

ip_conntrack growing indefinitely

[Alexander Fortin]

Hi everybody. We're running a couple of Debian Sarge machines with 
2.4.31 kernel doing NAT for our network.
Recently we had troubles with lost packets because of full ip_conntrack 
buffers, and it's strange because usually the average number of 
connections is not more then 8000-10000.
For now it has been patched setting ip_conntrack_max to 65536 but 
connections still grow indefinitely (seems NAT never drops old connections).
Any idea of the reasons? Could be related with the kernel version (2 
years old) we're running?

Thanks

-- 
Alexander Fortin
IT Consultant
Informed Technology
E-mail: alieno@it.net.au
Ph: 08 9460 4888  Fax: 08 9460 4877

Re: ip_conntrack growing indefinitely

[G.W. Haywood]

Hi there,

On Sat, 11 Aug 2007 fd4 wrote:

> > For now it has been patched setting ip_conntrack_max to 65536 but
> > connections still grow indefinitely (seems NAT never drops old
> > connections). Any idea of the reasons? Could be related with the
> > kernel version (2 years old) we're running?
>
> I've a similar phenomen using kernel 2.6.18-4-vserver-686 :
> conntrack -L|wc -l
> 3340
> nearly all started at a similar time from two ports to random
>
> example iptstate:
> Source Destination   Proto  State       TTL
> 1.2.3.4:42573 1.2.3.4:842 tcp ESTABLISHED 10:44:43
> 1.2.3.4:42574 1.2.3.4:1501 tcp ESTABLISHED 10:43:51
> 1.2.3.4:42573 1.2.3.4:1392 tcp ESTABLISHED 10:43:20
>
> well :- on my wish list now something like that:
> conntrack -D -s 1.2.3.4 -d 1.2.3.4 -p tcp --orig-port-src 42573 --orig-port-dst *

I don't think it grows indefinitely.  The timeout is five days.

http://lists.netfilter.org/pipermail/netfilter-devel/2005-June/020081.html

--

73,
Ged.

Re: ip_conntrack growing indefinitely

[fd4]

Am Sat, 11 Aug 2007 11:19:08 +0100 (BST)
schrieb "G.W. Haywood" <ged@jubileegroup.co.uk>:

> I don't think it grows indefinitely.  The timeout is five days.

about 11 hrs in that case :-)
(of course I've reduced the standard value)

and I've said a similar case - just wondering, cleaned it with conntrack -F

the growing to more than 3300 entries has started by an unknown local event triggering conntrack on local connections; I could not find any reason in the logs or somehow else. happened within a minute or 2 from 2 local ports

libnetfilter_conntrack 0.0.81 release

[Pablo Neira Ayuso]

[-- Attachment #1: Type: text/plain, Size: 632 bytes --]

Hi!

The netfilter project proudly presents libnetfilter_conntrack-0.0.81

libnetfilter_conntrack is a userspace library providing a programming
interface (API) to the in-kernel connection tracking state table.

This release includes minor changes and bugfixes. See ChangeLog for more
details. Upgrade is recommended.

You can download it from:

http://www.netfilter.org/projects/libnetfilter_conntrack/
ftp://ftp.netfilter.org/pub/libnetfilter_conntrack/

Pablo (on behalf of the Netfilter Project)

-- 
"Será preciso viajar a través de los ojos de los idiotas" -- Poeta en
Nueva York -- Federico García Lorca.

[-- Attachment #2: ChangeLog --]
[-- Type: text/plain, Size: 345 bytes --]

libnetfilter_conntrack 0.0.81
======================================================================

Changes from 0.0.80:

- add layer 4 protocol comparison to nfct_compare()
	[Pablo Neira Ayuso]

- introduce nfct_nfnlh() to use functions like nfnl_rcvbufsiz()
	[Pablo Neira Ayuso]

- remove unused build_id() from build.c
	[Pablo Neira Ayuso]

delete conntrack entry - how

[fd4]

hi,

I want to delete this stale conntrack entry:
conntrack -L
tcp      6 259996 ESTABLISHED src=85.214.110.62
dst=217.199.190.234 sport=44895 dport=80 packets=1 bytes=40 [UNREPLIED]
src=217.199.190.234 dst=85.214.110.62 sport=80 dport=44895 packets=0
bytes=0 mark=0 use=1

iptstate shows:
Source Destination  Proto State       TTL
85.214.110.62:44895 217.199.190.234:80 tcp ESTABLISHED  72:10:59

so I dont want to wait 72 hours more;
I've already reduced some values,
e.g.
echo 216000
> /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established

but the connection was already EST

an example for deleteing such an entry within the man page would be fine

Regards

Re: ip_conntrack growing indefinitely

[fd4]

> For now it has been patched setting ip_conntrack_max to 65536 but 
> connections still grow indefinitely (seems NAT never drops old
> connections). Any idea of the reasons? Could be related with the kernel
> version (2 years old) we're running?

I've a similar phenomen using kernel 2.6.18-4-vserver-686 :
conntrack -L|wc -l
3340
nearly all started at a similar time from two ports to random

example iptstate:
Source Destination   Proto  State       TTL
1.2.3.4:42573 1.2.3.4:842 tcp ESTABLISHED 10:44:43
1.2.3.4:42574 1.2.3.4:1501 tcp ESTABLISHED 10:43:51
1.2.3.4:42573 1.2.3.4:1392 tcp ESTABLISHED 10:43:20

well :- on my wish list now something like that:
conntrack -D -s 1.2.3.4 -d 1.2.3.4 -p tcp --orig-port-src 42573 --orig-port-dst *

Re: ip_conntrack growing indefinitely

[Eric Leblond]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Le Sat, 11 Aug 2007 09:38:08 +0200,
fd4 <fd4@itsec4u.de> a écrit :

> > For now it has been patched setting ip_conntrack_max to 65536 but 
> 
> well :- on my wish list now something like that:
> conntrack -D -s 1.2.3.4 -d 1.2.3.4 -p tcp --orig-port-src 42573
> --orig-port-dst *

You should try this:
http://software.inl.fr/trac/trac.cgi/wiki/pynetfilter_conntrack

It does exactly what you want.

BR,
- -- 
Eric Leblond <eric@regit.org>
NuFW, Now User Filtering Works : http://www.nufw.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGvW2PnxA7CdMWjzIRAn4xAJsFD/7db/FCNw6iwTByznnY5PDpdACfdegE
pslZiNpAY6TtqT0F0Iw4HTw=
=6G59
-----END PGP SIGNATURE-----