- CheckMates
- :
- Products
- :
- General Topics
- :
- Re: R80.20 strange behaviour - random TCP session ...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
SecureXL underwent major changes in R80.20+, and has slightly different rules for handling idle timers vs. the Firewall workers:
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
now available at maxpowerfirewalls.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It would be interesting to compare this with fw tab -t connections -u output to make sure this output is accurate.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
now available at maxpowerfirewalls.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
SecureXL underwent major changes in R80.20+, and has slightly different rules for handling idle timers vs. the Firewall workers:
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
now available at maxpowerfirewalls.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
i have the same issue on r80.20 HF T161.
how can we have the good timers ?