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

[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-----

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