- Products
- Learn
- Local User Groups
- Partners
- More
MVP 2026
Inception is On!
What's New in R82.10?
10 December @ 5pm CET / 11am ET
Improve Your Security Posture with
Threat Prevention and Policy Insights
Overlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
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 |
|---|---|
| 3 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
Wed 03 Dec 2025 @ 10:00 AM (COT)
Última Sesión del Año – CheckMates LATAM: ERM & TEM con ExpertosThu 04 Dec 2025 @ 12:30 PM (SGT)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - APACThu 04 Dec 2025 @ 03:00 PM (CET)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - EMEAThu 04 Dec 2025 @ 02:00 PM (EST)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - AmericasWed 03 Dec 2025 @ 10:00 AM (COT)
Última Sesión del Año – CheckMates LATAM: ERM & TEM con ExpertosThu 04 Dec 2025 @ 12:30 PM (SGT)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - APACThu 04 Dec 2025 @ 03:00 PM (CET)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - EMEAThu 04 Dec 2025 @ 02:00 PM (EST)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - AmericasAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY