Community discussions

MikroTik App
Forum Guru
Forum Guru
Topic Author
Posts: 3119
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Conn Tracking tcp timeout setting question.

Fri Jul 15, 2011 2:16 am

Default "TCP Established Timeout" in firewall Conection Tracking is set to 24hrs. Why?
Why should tcp connections stay alive so long?

An the other hand, If I open a webpage, I see many connections made and some established but most of them dissapear soon anyway. Even the "established" connections dissapear within some mins while the counter starts at 23:59:59?

So, which are the connections that stay aliver to use the full timer up.
And why is the dis/advantage of setting longer/shorter timeouts in conn. tracker?
Forum Guru
Forum Guru
Posts: 7717
Joined: Tue Aug 11, 2009 3:19 am

Re: Conn Tracking tcp timeout setting question.

Fri Jul 15, 2011 2:38 am

Connections that are closed (ACK for a FIN) are removed from the connection table. If the connection isn't observed to be closed it stays open - either because it's still active, or because the router didn't see it being closed (it's a stale connection that the endpoints intended to close but the router somehow didn't see it).

What is a good value? Depends on your network. It's hard to be generic here. Other platforms only apply this value to idle connections (the value resets whenever a packet is seen in the connection), but iptables applies this value from beginning to end. If you make this value too short then a valid connection that is passing data will be removed after that time period. I believe the Linux kernel default value (server oriented, not router oriented) is still 5 days. 1 day is probably fairly appropriate for most routers.

If you see a lot of connections where packet counters aren't increasing and they're not observed as closing you might want to investigate packet loss. Stale connections that idle for very long periods of time for a legitimate reason should be rather rare. Your network (or other networks between the two endpoints) may be dropping the last packet that should be closing the connection.
Posts: 411
Joined: Fri May 01, 2009 11:32 pm

Re: Conn Tracking tcp timeout setting question.

Thu Oct 04, 2012 3:56 am

I am finding that in most of my Point to multipoint wireless networks, 1day is way too long. I have mine set to 1 hour. It hasnt caused any problems with pre-mature tcp conenction termination as far as i can tell.

Even at 1 hour, on some of my marginal signal customers it is causing issues because i have a tcp connection limit in place per user. Some of the connections dont die in time and they hit the limit even tho no traffic is flowing on those stale tcp connections.

I havnt found a perfect balance yet. but generally 1 hour has served me well.
User avatar
Posts: 492
Joined: Sun Apr 15, 2012 12:10 pm
Location: Italy

Re: Conn Tracking tcp timeout setting question.

Wed Nov 07, 2012 9:22 am

But what happens if an user, for example, does an HTTP download that is very long and last for about 3 hours?
If we set the TCP established at 1h timeout, the connection will be dropped at 1h ? Or the counter will be reset if data passes in?

Posts: 313
Joined: Fri Dec 28, 2012 2:33 pm

Re: Conn Tracking tcp timeout setting question.

Tue Nov 11, 2014 10:21 am

Just bumping this as I assume an active connection wouldn't have an issue once it's established? So setting to 1hr would be fine.
just joined
Posts: 9
Joined: Thu Feb 09, 2017 4:13 pm

Re: Conn Tracking tcp timeout setting question.

Fri Feb 17, 2017 6:42 pm

Please, explain me, why i can see in connection tracker some connections, that dont belong to any known networks. Source Ip's in general are privat or CGN networks ( Such connections hangs on connection tracker with status "confirmed,srcnat".

Who is online

Users browsing this forum: Bing [Bot], holvoetn, nik247 and 51 guests