- Products
- Learn
- Local User Groups
- Partners
- More
MVP 2026: Submissions
Are Now Open!
What's New in R82.10?
10 December @ 5pm CET / 11am ET
Announcing Quantum R82.10!
Learn MoreOverlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
Last Monday during the evening several users had issues connecting VPN Remote Access.
They would enter their VPN login information and 1 minute later the pop-up for the login prompt would appear again.
This went on for several hours. Everything was working fine for those users during the day and it was working fine again the day after.
How can I find what caused this and ensure it doesn’t happen again?
For two of them I have a Failed Login in the logs with reason ‘Could not obtain user object. Timeout reached.’ But for the others, I’m not seeing anything that stands out.
The clients are E86.20. The gateway is R80.40. The management server is R81.10 (updated from R80.40 approximately two weeks before the incident)
Anyone has seen this issue before or has anything to suggest in where to investigate to identify the cause?
Thanks
If this issue went away by itself have you considered / eliminated an ISP issue or was VPN the only noted impact?
Also for awareness enhancements in the E86.30 client include:
| ESVPN-3237 | Enhancement: In the roaming feature, when a VPN client works in Hub Mode with "Exclude local network" enabled, the user now does not have to re-enter credentials in case of a short network outage. |
Yes I've considered the ISP. I'm aware of one user in the past with a similar issue for which the problem was fixed after he switched ISP. In this case I've got several users over at least three different regions. Of course our own ISP reports no issue...
Nobody has reported any other issue during that period but since it was in the evening there wasn't a lot of people working.
I tried using cpview -t to see if I could see anything out of the ordinary for that timeframe but all I'm getting is 'History is initializing'. I tried the troubleshooting steps of sk101878 but it doesn't work.
Anything else I can look at to see if the gateway was having issue during that period.
That E86.30 enhancements is great. Time to schedule an upgrade 🙂
Something else I noticed during the same timeframe is a lot of Alert logs with reason "Firewall - Domain resolving error. Check DNS configuration on the gateway (0)"
Not sure if this is an issue since it doesn't drop or block, it just gives an alert. But it seems like an odd message and it happened around the same time
Are the configured DNS servers internal or external/public ones?
internal. Primary is from our internal domain. Secondary is our DMZ domain (non-public) and tertiary internal domain again.
We had case with TAC for similar issue and once customer installed newer VPN client version (cant recall which one now, I believe e86.40), issue went away.
Also the DNS servers are Windows servers 2019. Looking a some DNS logs on those servers I see entries constantly repeating.
"The DNS server received a bad TCP-based DNS message from 10.100.0.3. The packet was rejected or ignored. The event data contains the DNS packet."
That's the IP of the gateway.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 4 | |
| 3 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
Fri 12 Dec 2025 @ 10:00 AM (CET)
Check Mates Live Netherlands: #41 AI & Multi Context ProtocolFri 12 Dec 2025 @ 10:00 AM (CET)
Check Mates Live Netherlands: #41 AI & Multi Context ProtocolTue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY