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?

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.

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.

Hello.
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?

Thanks

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.

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 (100.64.0.0/10). Such connections hangs on connection tracker with status "confirmed,srcnat".

set 3 minutes for TCP established and UDP stream.. and set maximum of 15 seconds for all other timeouts and be done with that.

if anyone complains tell them to enable connection keep-alives...

then you got rid of garbage. same applies for ARP garbage..;
we use proxy-arp for bridging wireless networks.. dunno why necessary but didnt work without them.

TBH I would also set 15 seconds for TCP-established-timeout and UDP-stream-timeout types; but keepalives are not that frequent. So it would cause more problems than it solved..