I have the typical firewall setting for mostly-outgoing traffic: there is a forward rule that allows traffic with connection
state Established, Related and a rule that allows traffic outgoing from my LAN.
(the traffic is forwarded over a VPN)
When I observe the Connections page of the IP Firewall, I see the timer downcounting to zero even when there is
matching traffic. For longlasting connections, e.g. SSH connects, at some point the counter reaches zero and a
new entry is created when I cause outgoing traffic on the connection, and the timer is at the max again.
However, when at this point the other end sends the first traffic, there is no matching connection for the Established
rule and the traffic is being dropped. As I have a log flag in my final drop entry I see it being logged.
When I don’t have any outgoing traffic (e.g. a TCP keepalive, or just hitting a key), the other end will re-try and at
some time give up and close the session.
Is this normal behaviour? I would expect the timer to jump back to the configured value each time there is matching
traffic on the Established, Related rule, so it never counts down to zero when there is occasional traffic within the
max timeout value.
Can this be achieved on a MikroTik router and is it maybe some setting I need to do?
Is it a too difficult question for this subforum?
Maybe someone can help by watching the timers on their router when a permanent session is present, e.g. SSH or
telnet to an external system, to see if the counters go back up for every time data is passing through the connection,
or if they just count down to zero no matter if data is passing.
That could help me finding if I am doing something wrong.
Hi Rob,
I can confirm the connection timeout counter are NOT resetting on traffic. Checked TCP (24h timeout), ipencap and proto 93 (10 min timeout).
But strangely, counters start to count UP after reaching 00:00:00 without dropping the connection.
ICMP times out correctly (10 sec), but udp, 4, 93 and ospf don’t (irrespective of the unanswered flag, they count up past expire time).
I have no TCP in ‘established’ state approaching 0 now to check. States ‘syn sent’, ‘close’ and ‘time wait’ time out correctly.
In most cases the TCP entries, when going to zero, get re-created and initialized to max value when traffic is seen
in the direction that the firewall allows for “new” traffic. But, when that side is silent and the other side is sending
traffic, it does not match the “Established” rule and will get dropped normally. When this situation persists for some
time, the connection gets dropped by the other end. Often, the local side will send “keepalives” or other traffic that
will revive the connection. When it doesn’t, the link fails.
Maybe I see it more often because I decreased the 24h timeout on TCP connections to 1h. This is normally enough,
when keepalive is on for those SSH sessions. Other TCP sessions usually are short-lived or have traffic.
Maybe I get bitten here by a difference between standard Linux and MikroTik RouterOS. In standard Linux, it appears
the timers are bumped whenever traffic is matched.
After this, I have set the timeout back to one day as it is by default, but this really only hides the actual problem a bit more.
I still see occasional dropped ssh connections, only less frequently.
How can the root cause of this problem be fixed?
(I think the timers should reset when there is traffic so they only count the time there is no traffic, not the session time)
They are in TCP state established and conntrack stat is “assured - not unreplied”.
They are long-lived connections with occasional traffic. The problem is of course not visble for the typical user who
does web browsing etc.
The same connections go through another firewall further down the network, which is a plain Debian Linux machine.
When I do “conntrack -L” on that system I see the same info and also the timer there, but when I pass some traffic
through one of the sessions I see that timer bump up to the maximum, while the counter on the MikroTik is counting
down.
Well, according to the protocols and addresses I see there we are on the same type of network
However, what I see is a bit different. I don’t see those case of timers counting up.
What I see is temporary lockout in one direction until traffic from the other direction occurs, consistent
with having an ESTABLISHED, RELATED rule in both directions and a NEW rule in the outgoing direction.
Interestingly enough, I don’t see the problem anymore after I have split the single forwarding rule with both ESTABLISHED and RELATED into two rules, one with ESTABLISHED and one with RELATED.
I see that this is the default in the MikroTik settings and wanted to go back as much as possible to default settings.
I have combined those two flags into one rule, as I always do in Linux firewalls and also see others do all the time, without problem, but it appears in MikroTik RouterOS there is something special that causes it to have problems with the timers when this is done…
Oh. I am using established, related rules as one rule only instead two in latest versions, because I understood that the tcp state relation operator is “OR”. Does it mean it is not true?
I think as well that checking both ESTABLISHED and RELATED means “OR”, but in the default config from MikroTik
they are separate rules. Maybe for some reason… I don’t know.
Maybe because the default config is applicable to older versions where using more tcp states in one rule was not possible. Unfortunately the documentation doesn’t deal with this point. It should be updated.
