R80.20 strange behaviour - random TCP session timeout values - fw ctl conntab

[REconfigure]

Hi Community!

after upgrading to R80.20 i verified the session tables of our fw gateways, with the "fw ctl conntab" command.

I found out that all upgraded gateways have random TCP session timeouts for a session displayed, and not the actually configured value for the service.

I checked it on more than 20 different gw´s it´s always the same. for a global value of 7200 sec, there is sometimes 4642 or even as low as 1058 sec, or higher 7205 etc. in the output next to the TTL - same rule/same service.

In older versions like 77.20 it´s always exactly the configured value for example 7200sec in the output.

Can anyone verify this, is this only cosmetic or could this lead to sessions falling out of the table to soon?

Attached you can find screenshots with example output of a R77.20 and R80.20 gateway.

[PhoneBoy]

It would be interesting to compare this with fw tab -t connections -u output to make sure this output is accurate.

[REconfigure]

Hi Dameon,

thanks for your reply!

Yes the behaviour is the same. Can you verify it on one of your R80.20 machines?

I see it on all our updated gateways, we have currently world wide in production. We experience some very bad "drop TCP out of state" situations for some applications, and I try to find out if it could be related to this.

BR

Paul

[Christopher_Rag]

I can verify this happens in our R80.30 environment. It appears as the idle timeout ticks down, the max time seems to dynamically update and continues to get smaller. It will continue to do this until the session times out or is removed by other means, i.e. replaced with an end session timeout.

[REconfigure]

Do you think this is by design, is there any reference to how this works and how it should be interpreted?

[Timothy_Hall]

Do you see anything like FW-1: Capacity Problem detected: Connections Table/Memory Consumption has exceeded XX% in the firewall's traffic log or syslog?  This indicates that the Inspection Setting "Aggressive Aging" is active and dynamically shortening the max timeouts for connections.

[REconfigure]

Hi Timothy, thanks for your comment -> good point, I was searching in that direction already, but no error of that kind is visible.

[HeikoAnkenbrand]

SecureXL has been significantly revised in R80.20.

I could already see this behavior with R80.20 and R80.30 gateway.
The TCP session timeout should be by default 3600 seconds with "Aggressive Aging" default 600 seconds.

With R80.20 and R80.30 gateways, these values are slightly increased dynamically for 5-6 seconds. I think Check Point does that now as well as Fortinet or other firewall manufacturers.
They probably set these values higher than the default TCP timeout value to avoid seeing "first packet isnˋt SYN" packets until the FIN/ACK connection is cleanly terminated.

Can someone from R&D please say something about the new behaviour in R80.20 and above.

[REconfigure]

Hi Heiko, thanks for you reply and for verification on your machines. Yes there must be some sort of new algorithm or some major bug is place. No offence but I don´t know why your post is now marked as a solution? Also the TCP session timeout values are "decreasing" in some sessions. A documentation about that would be good. I already opened a case, hope R&D is already working on this.

[Timothy_Hall · Accepted solution]

SecureXL underwent major changes in R80.20+, and has slightly different rules for handling idle timers vs. the Firewall workers:

sk110620: Idle connection that was accelerated by SecureXL is dropped with "First packet isn't SYN" ...

sk44711: Kernel debug shows that TCP traffic is "dropped by fwhold_expires Reason: held chain expire...

I'm also wondering if the observed timer behavior is possibly related to Smart Connection Reuse:

sk24960: "Smart Connection Reuse" feature modifies some SYN packets

sk41248: How does the Security Gateway handle Established TCP Connections?

To help isolate this issue try disabling SecureXL for a certain set of connections and see if the timers stop fluctuating for them:

sk104468: How to disable SecureXL for specific IP addresses

[Efrat_Meir · Accepted solution]

Hi,

This is only cosmetic. The timeout shown in "fw ctl conntab" is taken from an incorrect location (Firewall instead of SecureXL).

We will fix it in the next Jumbo.

Please let me know if you have any further questions.

[DZ_KB]

Hello,

i have the same issue on r80.20 HF T161.

how can we have the good timers ?