I haven't done a heck of a lot in anger with tuning iptables/netfilter
based firewalls
I know that on a Cisco ASA (formerly know as PIX) firewall the default
TCP established time-out is 1 hour and half-closed (which I think is
FIN wait) is 10 minutes.
These timers/counters are always a compromise between making sure
legitimate traffic is still allowed to work without needing
application keep-alive hacks, and make sure badly behaved or
malicious sources don't consume resources in the stateful connection
tables.
So that said, unless you are seeing something that looks like
resources are being consumed badly I would leave it. (And as you have
probably figured out these probably aren't likely to be connected to
delay issues)
Regards, Martin
martinvisse...@gmail.com
On Tue, May 4, 2010 at 12:35 PM, Kyle k...@attitia.com wrote:
I've been investigating some delays in my net connection recently and have
become aware of the std tcp timeouts set in sysctl by netfilter's conntrack
module.
Namely;
ip_conntrack_tcp_timeout_established 5 days
ip_conntrack_tcp_timeout_fin_wait 2 min's
ip_conntrack_tcp_timeout_max_retrans 300
ip_conntrack_tcp_timeout_syn_sent 2 min's
ip_conntrack_tcp_timeout_time_wait 2 min's
And it strikes me that these appear to be considerably long given the
present day state of connectivity and general speed of connections.
Especially, the 5 day timeout on an established connection. Isn't that just
a recipe for leaving a no longer wanted connection open well beyond it's
desirable lifespan?
Can anyone offer up some form of opinion as to why I shouldn't reduce these
values a bit (especially the established timeout) pls?
For example;
ip_conntrack_tcp_timeout_established 1 day
ip_conntrack_tcp_timeout_fin_wait 2 min's (might leave this or
possible to end up with unnecessary established conn's. waiting for
timeout)
ip_conntrack_tcp_timeout_max_retrans 300 (Can see why this might be
set high, but question it's genuine necessity)
ip_conntrack_tcp_timeout_syn_sent 1 min
ip_conntrack_tcp_timeout_time_wait 1 min
Am I about to completely screw things up by doing this?
--
Kind Regards
Kyle
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html