Re: [SLUG] iptables netfilter TCP timeouts

2010-05-04 Thread Martin Visser
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


[SLUG] iptables netfilter TCP timeouts

2010-05-03 Thread Kyle
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_retrans300
ip_conntrack_tcp_timeout_syn_sent 2 min's
ip_conntrack_tcp_timeout_time_wait2 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_retrans300  (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_wait1 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