Moritz, thanks for pointing that out. Your suggested 10 minutes seems a bit short, though..
I would not set ip_conntrack_tcp_timeout_established to any thing lower than tcp_fin_timeout. I would be tempted to set ip_conntrack_tcp_timeout_established to approximately double what tcp_fin_timeout is set to. I don't know of any reason that conntrack would need to keep things for twice tcp_fin_timeout, but I'd rather be safe than sorry. Besides even double of tcp_fin_timeout is CONSIDERABLY less than 5 days.
Hmm, dunno if various distros set tcp_fin_timeout differently. With 2.6.10, it's 60 secs (not a distro kernel, and I didn't set this). Are you saying that Mouritz' 10mins will in some (distro?) cases violate ip_conntrack_tcp_timeout_established >= tcp_fin_timeout * 2 ?
Anyway, /usr/src/linux/Documentation/filesystems/proc.txt says
tcp_fin_timeout
---------------
The length of time in seconds it takes to receive a final FIN before the socket is always closed. This is strictly a violation of the TCP
specification, but required to prevent denial-of-service attacks.
I'm having trouble understanding the 'strictly a violation' part. Is it a (iana) crime to define tcp_fin_timeout?
-- Kind regards, Mogens Valentin
