Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
REconfigure
Participant
Jump to solution

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

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.

 

2 Solutions

Accepted Solutions
Timothy_Hall
Legend Legend
Legend

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

 

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com

View solution in original post

0 Kudos
Efrat_Meir
Employee
Employee

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.

View solution in original post

11 Replies
PhoneBoy
Admin
Admin

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

0 Kudos
REconfigure
Participant

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

0 Kudos
Christopher_Rag
Participant

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
Participant
Do you think this is by design, is there any reference to how this works and how it should be interpreted?
0 Kudos
Timothy_Hall
Legend Legend
Legend

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.

 

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
REconfigure
Participant
Hi Timothy, thanks for your comment -> good point, I was searching in that direction already, but no error of that kind is visible.
0 Kudos
HeikoAnkenbrand
Champion Champion
Champion

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.

➜ CCSM Elite, CCME, CCTE ➜ www.checkpoint.tips
REconfigure
Participant
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
Legend Legend
Legend

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

 

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
Efrat_Meir
Employee
Employee

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
Collaborator

Hello,

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

how can we have the good timers ?

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events