If you are using a newish version of Netfilter, you can execute something like the following: echo "1000" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait This would set TCP CLOSE_WAIT timeouts to 1000 seconds. The default number is 3 days, so within that time, any traffic that does not close the connection properly will linger inside the conntrack systems. I don't have the option to fix the bad system. I do Nagios probes for Windows 2000 RDP uptimes using tcp socket probing (I know I could use RPC, blah blah), but the RDP connections are never fully closed by the windows machine, so within a couple days of probing various servers, I have quite a large conntrack table. -----Original Message----- From: Julien Didron [mailto:admin@xxxxxxxxxxxxxxxxxxxx] Sent: Wednesday, November 12, 2003 5:11 AM To: Netfilter Mailing List Subject: Re: Forwarding GnomeMeeting to internal network Hi again, Thanks for the answer Antony. I'll then grant this box a fixed IP using DHCP declaration with the MAC adress. Concerning the ip_conntrack table, I indeed have a sort of worm on my network called "MLdonkey" ;o) (it's on some other box on the network), process that I kill everytime the problem occurs, but with no success : i still get the very same error line in syslog. after increasing the value of ip_conntrack_max, I monitored the traffic on the outgoing interface, that was very little : say from 150B/s to 500B/s up and down. For information my local network (this is home) is composed of 4 machines ranging from mail server (smtp and pop) to DDNS, DHCP and web server ... But I really don't think it to be a "large" network :o)