Exacty. Maybe the isp has shorter times
When you run into problems with a 24h established timeout, and you solve it by lowering it, it is an indication of bad connections in the network at some place.
Of course in an ISP setting it could be that clients use WiFi at home and walk into/outside range and this can cause TCP connections to get stuck because the client has dropped them and the server does not know about that. This is common for the port-5228 connections made by Android phones to the Google servers, these are always running and never closed by the phone, so when the phone goes out of network coverage it resets the connection and makes a new one when it sees the network again.
In that case there probably is little that you can do about it.
In the general case, the timeout on establised sessions should not be made too low, because there can be zero traffic for a long time. 5 minutes really is too short, 1 hour may be acceptable in some cases, I would not set it lower than 4 hours.
But of course, the higher the timeout the more stuck sessions in the table. It would be better when the server side would close idle connections after some time so the router would start the “tcp unacked” timer which is much shorter than the established timer. So the connection would disappear much quicker.
Well he stated in the first post that he was having problems after he lowered TCP Established to 5 minutes (!) from the MikroTik default of 1 day.
Tried to raise it to 30 minutes and then to 1 hour, and the last one seemed to work fine with no complaints from the customers.
The posts are pretty clear though, he stated all this in here.
The only problem was his meddling with the TCP Established timeout, lowering it too much.
Exactly!
But I ran across another topic where it was about TCP unack timeout and some ssh connection dropped.
However, at the moment, with 1h, I have VERY few complaints, pretty occasional…
the only game involved was call of duty, so I think it is a setting related to that game.
For example the AVM Fritzbox have a default of 15 minutes for tcp established timeout
Ok, in my network I usually don’t manage settings based only on the “how many customers are complaining” feedback, but of course to each his own.
Well.
if a lot of users are complaining for the same reason… is like receiving a hint!
What I mean is: of course it is a good idea to assume something is wrong when you get a lot of complaints, but it is never safe to assume that everything is OK when you receive no complaints or less complaints than before.