hello
In our network we use NAT for our end users.
Some gamers have public IPs.
The ip firewall settings, are all defaults, except for TCP Established that is set to 5 minutes.
I have no issues at all in the network.
Seldom appears Call of Duty disconnects, the client suddenly disconnects from server and the user is angry.
One of our users have a competitor network, and it works flawlessy.
I have tried to raise the TCP established timeout to 30min.
Maybe this the issue?
Why do you have this tcp timing rule? I dont have any such rule that I am aware of??
?!
They are timers that are set by default. We just modified the TCP Established connection from 1 day (default) to 5 min. We now tried to set them to 1 hour.
The reason of the change is that in a border router with conntrack, is formed a huge number of connections!
Ahh, I found it, not a setting I would have thought of in a million years.
Interesting, hopefully someone who knows how to use this setting will chime in.
Since I usually provide ‘different’ advice, there are some that follow me to ensure MT victims get good advice LOL.
GLuck, tis out of my knowledge sphere, (ever shrinking)
@Maggiore81, it’s not clear from your description whether raising the tcp established timeout from 5m to 30m has resolved the issue.
If it did, the relationship could be that the CoD client sends TCP keepalives less frequently than 12 times per hour, and in the meantime between the keepalives the ephemeral port on the public address gets assigned to a connection created by another player. But if this is the reason, I assume there must be also some other communication stream than this affected session, unless CoD is similar to fishing, hours elapse between short intervals of activity?
How many users playing CoD and how many public IP addresses on the WAN side we are talking about?
Disable conntrack completely? Do you need the functionality on an edge router?
There is no NAT without conntrack. So that’s not an option.
I think that if you are unable to handle large amount of connections, then you need a more powerful router?
I mean you are applying workarounds, this is impacting users and here you are trying to figure out what’s the problem.
Hello
@Darknate , If I disable conntrack, the packet will go into slowpath. I have enabled fasttrack and the CPU is about 20% with ~5Gbit traffic.
@erkexzcx - Currenty the 1036 works flawslessy, The CCR-2004 is not an option (I tried but cpu at 99%), the 1072… I fear the watchdog bug at the moment. I will expand only when the traffic increases.
@sindy: I dont have the information currently. I set at 30min, then the gamer (we agreed to do some tests) told me that exactly after 30min the client disconnected abruptly. The customer have individual single static IP address. I will add information later because we will call the customer in a couple of hours.
If you know the IP of the gamer, you should record the traffic between that IP and the router. The way you describe it, it sounds as if expiration of the timer in connection tracking was making the router send a TCP reset to the client and server.
I know the IP of the gamer. I really suspect this issue but I have few time to analyze it.
I tried to put to 1h and later we will call the customer.
What? Check the official documentation by MikroTik. Fast Path will continue to work with conntrack disabled and only works if conntrack is disabled. Give it a shot.
My local ISP uses MikroTik as well and they do not use conntrack on their edge routers.
https://wiki.mikrotik.com/wiki/Manual:Fast_Path
https://wiki.mikrotik.com/wiki/Manual:IP/Fasttrack
“IPv4 fast path is automatically used if following conditions are met:
connection tracking is not active;”
@Darknate: I cannot apply firewall rules on my border router if I use fastpath!!!
It’s not that simple. I’ve just tested that the expiration of the “tcp-established” timer is silent, it doesn’t make the router send TCP RST in any direction. So the next possibility to come to my mind is that the “tcp-established” timer would not be re-initialized to the tcp-established-timeout value by TCP keepalive packets due to a bug, so keepalive responses from the server would not be delivered to the client. But I’ve got no idea how to verify this assumption right now.
sindy, I will try for the moment to raise the timer, maintaining untouched the other feature or settings in the network.
Yesterday in the evening he played flawlessy at peak time (timers where set to 1h) with 0 issues. We will keep testing today
Set timeout to 1h, PROBLEM SOLVED.
It is three days and 0 disconnections 
So what is the conclusion here.?? That all of us should set TCP timers to 1 hour vice the default??
or are you saying that this issue is only happening due to a bug in the code and the above is a workaround until fixed??
No. The default are 1 day, so they are fine.
1day may be too much if the router have a LOT of connections.
1 hour keeps the cuncurrent connections low.
It is not a bug. Maybe the 5min is a too aggressive setting.
The conclusion is that if you handle a lot of low-traffic&long-lived, or silently dying, TCP connections, you end up with a lot of tracked connections occupying RAM but not handling any traffic. And if you need connection tracking because you need to use NAT, the ugly workaround is to shorten the timeout for keeping the connection recognized by the firewall since the last packet has passed through the router. And to make CoD happy, you cannot set this timeout to be shorter than something between 30 and 60 minutes.
Outside the context of CoD, this approach may be risky where many clients on the private side connect to the same server on the public side, as whilst the firewall prefers to keep the source port unchanged when doing the NAT, if the source port used by the client to connect to a remote server is already used by a connection of another client to the same remote server, the firewall assigns another one to the new connection. This is normally fine, but if the connection in the router’s connection tracking is forgotten due to timer expiration, the next packet of that connection coming from client side establishes a new tracked connection, and the source port choice is done again, and it may yield a different port, so the server will not recognize that packet as a part of the existing session and will drop it. This will happen quite rarely, so it is hard to identify the issue if some client complains about mysteriously broken connections.
For home use, keeping the default tcp-established-timeout at the default value of 1d is fine.
Oohh, very interesting. I also suspected this kind of issue from a natted ISP provider too, no wonder some of the group members on Facebook (CoD Group) were complaining with the random disconnection. One of my friend, who has a Mikrotik, but natted from the provider, experience this kind of disconnection. The connection tracking have set already to 1h and It was still happening. I think this confirms the suspicion now, every players that are natted in ISP if the established timeout is set to below 1h, some connection gets broken.