- Products
- Learn
- Local User Groups
- Partners
- More
The Great Exposure Reset
24 February 2026 @ 5pm CET / 11am EST
CheckMates Fest 2026
Watch Now!AI Security Masters
Hacking with AI: The Dark Side of Innovation
CheckMates Go:
CheckMates Fest
Hello,
does anyone experience the following scenario:
TEST SCENARIO:
Logging on VPN server (Mobile Access Blade, 80.30) with Endpoint Security VPN.
t(0) time - Log In with timestamp in Logs
t(1) time - after VPN session timeout (10hours 30min) Re-Authenticated in less than 60 seconds
t(2) time - Log Out with timestamp in Logs
TEST SCENARIO RESULTS:
Checking logs on log server there is missing t(0) timestamp with Log In information
t(1) time - shows Log In with t(1) timestamp in Logs
t(2) time - shows Log Out with t(2) timestamp in Logs
EXPECTED:
t(0) time - Log In with t(0) timestamp
t(1) time - Log In Re-Authenticated with t(1) timestamp
t(2) time - Log Out with t(2) timestamp
In basic scenario, using VPN session for less than VPN Re-authenticate sesson timeout, both LogIn and LogOut are in log results.
GlobalProperties, Remote Access:
Re-authenticate user every: 630min (10h 30min)
thank you.
Remote Access VPN can actually be served by either Mobile Access Blade or the VPN blade.
Are you looking for both types of logs when you check for this?
If you have Identity Awareness enabled with Remote Access as one of the identity sources, there should be a log for that association as well.
Hello PhoneBoy,
yes, both are checked. Normally LogIn and LogOut are logged as part of Mobile Access Blade.
Interesting part is that LogIn in t(0) timestamp was visible in first hours (during 10hours30min period).
Although the LogIn t(0) timestamp is missing there are visible 'Key Install' logs on VPN Blade after t(0) timestamp.
If you can consistently reproduce this, it might be worth a TAC case.
I think what's actually happening here is that we are updating the original log entry with the new Log In time.
Believe you can confirm this by opening the log card and reviewing it.
Possible. But as stated, expected is to keep original LogIn at t(0) as valuable information.
Solved, using external log server infrastructure.
Can you open the log card and confirm what I'm saying?
Whether it should do that or not is a separate question, but I believe this is the intended behavior.
I can confirm both log cards (missing one from t(0) and Re-Authenticated at t(1)) have the same Mobile Access Session UID.
I think what you wrote makes sense, but I also do agree with phoneboy's response as well.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 4 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
Thu 12 Feb 2026 @ 05:00 PM (CET)
AI Security Masters Session 3: AI-Generated Malware - From Experimentation to Operational RealityFri 13 Feb 2026 @ 10:00 AM (CET)
CheckMates Live Netherlands - Sessie 43: Terugblik op de Check Point Sales Kick Off 2026Thu 19 Feb 2026 @ 03:00 PM (EST)
Americas Deep Dive: Check Point Management API Best PracticesThu 12 Feb 2026 @ 05:00 PM (CET)
AI Security Masters Session 3: AI-Generated Malware - From Experimentation to Operational RealityFri 13 Feb 2026 @ 10:00 AM (CET)
CheckMates Live Netherlands - Sessie 43: Terugblik op de Check Point Sales Kick Off 2026Thu 19 Feb 2026 @ 03:00 PM (EST)
Americas Deep Dive: Check Point Management API Best PracticesAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY