- Products
- Learn
- Local User Groups
- Partners
- More
Quantum Spark Management Unleashed!
Introducing Check Point Quantum Spark 2500:
Smarter Security, Faster Connectivity, and Simpler MSP Management!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
We've been doing some work on our VPN configs and noticed recently that the re-auth times can randomly be 8 hours while the Global Settings are set to 20 hours. We have been playing with upgrading to the latest versions and also changing the trac file on the gateways to use DNS for connections instead of IP every time. Is there a known bug that would cause this?
We do have the SecureClient Mobile set to 480 minutes (8 hours) but these are all Endpoint Security VPN clients.
See screenshot... this is the same user and login but starting on 8/30 you'll start seeing random 8 hour re-auth settings. Appreciate any help!
Hi @VikingsFan
What is came into my mint is the trac_client_1.ttm file
:neo_user_re_auth_timeout (
:gateway (endpoint_vpn_user_re_auth_timeout
:default (client_decide)
I will check it, if the support.checkpoint.com will work again.
Akos
Actually poking around in that file right now. It's currently set to client_decide on both old and new cluster. The only changes we made were following this SK: https://support.checkpoint.com/results/sk/sk75221 and also testing different Endpoint Connect versions... E88.50 and E88.60.
That got me thinking though where the 'client_decide' information is stored and found that it's locally on the client under the trac.defaults file. Going to see if our pre-packaged file from earlier has different settings in there. Thanks!
Hi @VikingsFan
Good to hear that, if you find the exact sulotion, please share with us.
And compare the trac file on both GW-s, maybe there are different (and cluster members too)
Akos
The trac.defaults file was a dead-end... I loaded previous versions of our installer and did not see any difference in them that would explain a re-auth change. The trac file on the GWs between clusters are also similar and the only change on the old gateway was the DNS update linked above. So back to the beginning.
Only real change is we're using different client versions... will keep digging.
I could be mistaken when I say this, but IM fairly sure global properties re-auth setting would override any other setting you configure for this.
Can you send screenshot of how you have this in global properties?
Andy
K, sounds good, let us know. I have couple of labs going, R81.20 and R82, never had this issue. When connected, it always asks me to re-authenticate at 23h55 mins, which is expected, as mine is set to 24 hours re-auth in global properties.
Let us know what TAC says. Maybe, just as a quick test, if you can have one of those users with the issue delete/re-create the site and try, see if that makes any difference. Not sure it will, but worth a shot.
Andy
I was poking around the client logs and was looking into the trac.log file and found these lines. Could the local settings be overriding the gateway? In our GWs trac_client_1.ttm file we have neo_user_re_auth_timeout set to default (client_decide). It's been this way forever but only when we started messing with upgrade clients and add/remove sites the 8 hour limit started popping up.
I'll update next week after talking to TAC unless you're familiar with this setting.
Line 43922: [ 7396 8900][6 Sep 11:28:14][CONFIG_MANAGER] neo_user_re_auth_timeout return value 1200, because it is Gateway config variable. Scope: site COMP-Primary (2FA) ,gw NULL ,user USER
Line 44079: [ 7396 8900][6 Sep 11:28:14][CONFIG_MANAGER] neo_user_re_auth_timeout return value 480, because it is Default variable. Scope: site COMP-Primary (Certificate), gw NULL ,user USER
Line 44236: [ 7396 8900][6 Sep 11:28:14][CONFIG_MANAGER] neo_user_re_auth_timeout return value 1200, because it is Gateway config variable. Scope: site COMP-Secondary (2FA) ,gw NULL ,user USER
Line 44392: [ 7396 8900][6 Sep 11:28:14][CONFIG_MANAGER] neo_user_re_auth_timeout return value 480, because it is Default variable. Scope: site COMP-VPN (Certificate), gw NULL ,user USER
Line 44550: [ 7396 8900][6 Sep 11:28:14][CONFIG_MANAGER] neo_user_re_auth_timeout return value 480, because it is Default variable. Scope: site COMP-Secondary (Certificate), gw NULL ,user USER
Line 44707: [ 7396 8900][6 Sep 11:28:14][CONFIG_MANAGER] neo_user_re_auth_timeout return value 480, because it is Default variable. Scope: site COMP-VPN (2FA), gw NULL ,user USER
Line 44872: [ 7396 8900][6 Sep 11:28:15][CONFIG_MANAGER] neo_user_re_auth_timeout return value 1200, because it is Gateway config variable. Scope: site COMP-Primary (2FA) ,gw NULL ,user USER
Line 45029: [ 7396 8900][6 Sep 11:28:15][CONFIG_MANAGER] neo_user_re_auth_timeout return value 480, because it is Default variable. Scope: site COMP-Primary (Certificate), gw NULL ,user USER
Line 45186: [ 7396 8900][6 Sep 11:28:15][CONFIG_MANAGER] neo_user_re_auth_timeout return value 1200, because it is Gateway config variable. Scope: site COMP-Secondary (2FA) ,gw NULL ,user USER
Line 45342: [ 7396 8900][6 Sep 11:28:15][CONFIG_MANAGER] neo_user_re_auth_timeout return value 480, because it is Default variable. Scope: site COMP-VPN (Certificate), gw NULL ,user USER
Line 45499: [ 7396 8900][6 Sep 11:28:15][CONFIG_MANAGER] neo_user_re_auth_timeout return value 480, because it is Default variable. Scope: site COMP-Secondary (Certificate), gw NULL ,user USER
Line 45656: [ 7396 8900][6 Sep 11:28:15][CONFIG_MANAGER] neo_user_re_auth_timeout return value 480, because it is Default variable. Scope: site COMP-VPN (2FA), gw NULL ,user USER
Line 45814: [ 7396 8900][6 Sep 11:28:15][CONFIG_MANAGER] neo_user_re_auth_timeout return value 1200, because it is Gateway config variable. Scope: site COMP-Primary (2FA) ,gw NULL ,user USER
Line 45971: [ 7396 8900][6 Sep 11:28:15][CONFIG_MANAGER] neo_user_re_auth_timeout return value 480, because it is Default variable. Scope: site COMP-Primary (Certificate), gw NULL ,user USER
Line 46128: [ 7396 8900][6 Sep 11:28:15][CONFIG_MANAGER] neo_user_re_auth_timeout return value 1200, because it is Gateway config variable. Scope: site COMP-Secondary (2FA) ,gw NULL ,user USER
Line 46284: [ 7396 8900][6 Sep 11:28:15][CONFIG_MANAGER] neo_user_re_auth_timeout return value 480, because it is Default variable. Scope: site COMP-VPN (Certificate), gw NULL ,user USER
Line 46441: [ 7396 8900][6 Sep 11:28:15][CONFIG_MANAGER] neo_user_re_auth_timeout return value 480, because it is Default variable. Scope: site COMP-Secondary (Certificate), gw NULL ,user USER
Here is what I would try, BUT, please back up the fw and that file. Maybe replace ttm file on gw with default one and push policy, test. Or send me the file and I can compare it to one from my working gw Sunday. R81.20 version?
Andy
Here is something you could try, just backup current ttm file and them modify as below, install policy.
Andy
:neo_user_re_auth_timeout (
:gateway (endpoint_vpn_user_re_auth_timeout
:default (1200)
I was thinking the same thing... will give it a try. The "neo_user" is what was throwing me off as not being applicable... is that the old name of the VPN software? NEO? Will report back Monday if the change helped and also if TAC says anything.
Man, I have no idea LOL. The only abbreviation I know for NEO is named executive officer, haha.
Anywho, I guess in this instance it could be new? No clue : - )
Let us know if that fixes it, fingers crossed.
Andy
Thanks again. What I don't like is how random it is. I just connected four times with my regular MFA type and four times with my certificate and seven times I got the 1200 minutes and one time I got the 480. Strange. Anyways, it's the weekend! Will make the change and report back Monday. 🙂
Thats gotta be annoying, I hear ya. One thing you can do is make that change on ttm mgmt file, BUT, then it would apply to ALL gateways, just "throwing" that out there.
Andy
Forgot to say, dont forget to install policy after making the change in ttm file.
Hey mate,
Happy to do remote if need be, Im sure we can figure it out together, let me know.
Cheers,
Andy
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
Wed 03 Sep 2025 @ 11:00 AM (SGT)
Deep Dive APAC: Troubleshooting 101 for Quantum Security GatewaysThu 04 Sep 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: External Risk Management for DummiesWed 10 Sep 2025 @ 11:00 AM (CEST)
Effortless Web Application & API Security with AI-Powered WAF, an intro to CloudGuard WAFWed 10 Sep 2025 @ 11:00 AM (EDT)
Quantum Spark Management Unleashed: Hands-On TechTalk for MSPs Managing SMB NetworksWed 03 Sep 2025 @ 11:00 AM (SGT)
Deep Dive APAC: Troubleshooting 101 for Quantum Security GatewaysThu 04 Sep 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: External Risk Management for DummiesWed 10 Sep 2025 @ 11:00 AM (EDT)
Quantum Spark Management Unleashed: Hands-On TechTalk for MSPs Managing SMB NetworksAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY