Connection tracking - timeout values

TikUser · Thu May 15, 2014 2:03 pm

I've done some research about timeout values in Connection Tracking.

ROS:
tcp-syn-sent-timeout (time; Default: 5s)
tcp-syn-received-timeout (time; Default: 5s)
tcp-established-timeout (time; Default: 1d)
tcp-fin-wait-timeout (time; Default: 10s)
tcp-close-wait-timeout (time; Default: 10s)
tcp-last-ack-timeout (time; Default: 10s)
tcp-time-wait-timeout (time; Default: 10s)
tcp-close-timeout (time; Default: 10s)

Linux (iptables, Vyatta,...):
close timeout = 10s
close-wait timeout = 60s
established timeout = 5 days
fin-wait timeout = 120s
last-ack timeout = 30s
syn-received timeout = 60s
syn-sent timeout = 120s
time-wait timeout = 120s

As you can see, Mikrotik values are pretty aggressive. So, what’s the catch?

What does Mikrotik know and others don't?

rextended · Thu May 15, 2014 2:22 pm

Black = RouterOS
Blue = Linux (if your value are right)

tcp-close-timeout=10s | close timeout = 10s
tcp-close-wait-timeout=10s | close-wait timeout = 60s
tcp-established-timeout=1d | established timeout = 5 days
tcp-fin-wait-timeout=10s | fin-wait timeout = 120s
tcp-last-ack-timeout=10s | last-ack timeout = 30s
tcp-syn-received-timeout=5s | syn-received timeout = 60s
tcp-syn-sent-timeout=5s | syn-sent timeout = 120s
tcp-time-wait-timeout=10s | time-wait timeout = 120s

generic-timeout=10m | ?
icmp-timeout=10s | ?
udp-stream-timeout=3m | ?
udp-timeout=10s | ?

the catch?
for example 5 days one port still busy for one never closed connection?
if you have 2000 users on how many time you finish the available ports? (RouterOS use 32769-65534 interval for NAT)

TikUser · Thu May 15, 2014 3:33 pm

Ok! I've found the linux values here and here. There you can also find the timeouts for udp and icmp.

I've noticed that Mikrotik timeout values are too small for my network. My ROS firewall is configured to drop invalid traffic (add action=drop chain=forward connection-state=invalid). So, sometimes ROS would drop valid traffic, because it’s no more in the connecting tracking table. It timeouted too early.
That's why I asked for the opinion of other Mikrotik users.

rextended · Thu May 15, 2014 6:57 pm

Black = RouterOS
Blue = Linux (if your value are right)
Green = My opinion.

tcp-close-wait-timeout=10s | close-wait timeout = 60s
When is closed, is closed and is still closed, why wait more than 10 seconds?

tcp-established-timeout=1d | established timeout = 5 days
5 days??? One single connection? In my Gateway I lower this value to 6 hours.
If the PC or other devices forget to close the TCP connection, on gateway to 2000 users, you end the ports used for NAT...

tcp-syn-received-timeout=5s | syn-received timeout = 60s
tcp-syn-sent-timeout=5s | syn-sent timeout = 120s
60s ??? 120s ???? This is one way for help "DoS"...

tcp-last-ack-timeout=10s | last-ack timeout = 30s
similar....

tcp-fin-wait-timeout=10s | fin-wait timeout = 120s
tcp-time-wait-timeout=10s | time-wait timeout = 120s
How much the other end is slow??? 120s????

This are equal on both system
tcp-close-timeout=10s | close timeout = 10s
udp-stream-timeout=3m | 3m
udp-timeout=10s | 10s

icmp-timeout=10s | system conntrack timeout icmp 30s
30s for one icmp reply? What system wait for one ICMP packet with till 30 seconds delay???

generic-timeout=10m | ?
10m for a generic connection (non UDP, TCP or ICMP) are sufficents.

TikUser · Thu May 15, 2014 7:05 pm

Thank you! After researching this topic, I came to the conclusion that some of the Mikrotik values are too small, and that some of the Linux values are too big for my network. I'm testing values that are between those ranges.

davidnvega · Wed Feb 18, 2015 1:16 am

Black = RouterOS
Blue = Linux (if your value are right)
Green = My opinion.

tcp-close-wait-timeout=10s | close-wait timeout = 60s
When is closed, is closed and is still closed, why wait more than 10 seconds?

tcp-established-timeout=1d | established timeout = 5 days
5 days??? One single connection? In my Gateway I lower this value to 6 hours.
If the PC or other devices forget to close the TCP connection, on gateway to 2000 users, you end the ports used for NAT...

tcp-syn-received-timeout=5s | syn-received timeout = 60s
tcp-syn-sent-timeout=5s | syn-sent timeout = 120s
60s ??? 120s ???? This is one way for help "DoS"...

tcp-last-ack-timeout=10s | last-ack timeout = 30s
similar....

tcp-fin-wait-timeout=10s | fin-wait timeout = 120s
tcp-time-wait-timeout=10s | time-wait timeout = 120s
How much the other end is slow??? 120s????

This are equal on both system
tcp-close-timeout=10s | close timeout = 10s
udp-stream-timeout=3m | 3m
udp-timeout=10s | 10s

icmp-timeout=10s | system conntrack timeout icmp 30s
30s for one icmp reply? What system wait for one ICMP packet with till 30 seconds delay???

generic-timeout=10m | ?
10m for a generic connection (non UDP, TCP or ICMP) are sufficents.

Thanks for all this information, it's really useful.

I'm having issues with a failover setting. I have a PCC load balance with recursive routing.

When a ISP fails, connections are still established by the fallen ISP. I need to set lower timeouts but i don't know what values should i modify and what is the risk of this modification. Can you help me?

Thanks!

Feklar · Wed Feb 18, 2015 5:54 pm

Thanks for all this information, it's really useful.

I'm having issues with a failover setting. I have a PCC load balance with recursive routing.

When a ISP fails, connections are still established by the fallen ISP. I need to set lower timeouts but i don't know what values should i modify and what is the risk of this modification. Can you help me?

Thanks!

The problem that you are running into is that the router remembers where it sent a packet in the past and how id applied a NAT rule to it. The better solution is to clear out the connection tracking table for those specific packets so that it will apply the appropriate NAT rule to the session and communication can continue.

Something like this will do the trick in a script when the failover happens.

/ip firewall connection remove [find reply-dst-address~"^<PUBLIC IP OF WAN>"]

PeterFreeman · Wed Oct 24, 2018 9:38 pm

Hi all,

I've got an issue with connections, particularly SIP 5060, that are not timing out. sip service ports are turned off.
My PBX drops it's SIP trunk, but the connection appears to be still active in the connections table.
As soon as I remove the seamingly 'stale' connection, the SIP trunk re-establishes and all is well.
The connection doens't appear to ever timeout, but there's no bi-directional traffic flowing, it appears to be one direction only.

Any ideas how to kick the connection when it gets into this state?

Thanks
Pete.

msatter · Wed Oct 24, 2018 9:44 pm

Is that SIP connection on TCP or UDP?

TCP knows 'keep alive'

PeterFreeman · Wed Oct 24, 2018 10:17 pm

The connection I'm seeing is udp:5060
If I kill it the SIP trunks come back online.
They're currenlty running, and the connection appears to restart after about a minute or so, so the connection timer gets to around 02:00 and then starts again.
Pete.

PeterFreeman · Wed Oct 24, 2018 10:18 pm

When it's stale the "Orig./Repl. Bytes" is one sided.
Pete.

PeterFreeman · Wed Oct 24, 2018 10:56 pm

I've taken the udp stream tracking down to 30seconds and it appears to be working, i.e. the connections are leaving the tracker.
I'll monitor over the next week to see if the PBX has any more problems.

Does anyone know what the likely effect of having the streaming tracker set to 00:00:30 instead of 00:03:00 is likely to be?

Oh and just in case anyone asks, I'm running 6.42.9

Thanks

Pete.

msatter · Thu Oct 25, 2018 2:14 pm

When you have a Voip you can call and the onnection is build up. Now if you are being called the connection has to be active and your Voip server renews the connection each minute.
It is not stale it us waiting for a call.

Now you set the timeout to 30 secs what means that you are unreachable for also 30secs while the connection is not listening.

I have the same and my Voip reconnects every 5 mins and the default timeout is 3 mins. To avoid being not reachable for 2 mins. I put a backup connection NAT receiving calls on UDP 5060 and relaying it to the Voip server.

My advise it to return your default settingsand you need atleast 1 mins timeout to cover 1 mins renewal.

Connection tracking - timeout values

Connection tracking - timeout values

Re: Connection tracking - timeout values

Re: Connection tracking - timeout values

Re: Connection tracking - timeout values

Re: Connection tracking - timeout values

Re: Connection tracking - timeout values

Re: Connection tracking - timeout values

Re: Connection tracking - timeout values

Re: Connection tracking - timeout values

Re: Connection tracking - timeout values

Re: Connection tracking - timeout values

Re: Connection tracking - timeout values

Re: Connection tracking - timeout values