- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
09-02-2014 12:20 PM
Hey All,
Heres the Hardware and Software details:
Model | PA-500 |
Serial | ############## |
Software Version | 6.0.2 |
GlobalProtect Agent | 1.2.3 |
Application version | 452-2343 (08/26/14) |
Threat Version | 452-2343 (08/26/14) |
Antivirus Version | 1361-1833 (09/01/14) |
URL Filtering version | 4360 |
Time | Tue Sep 2 13:26:07 2014 |
Uptime | 52 days, 20:49:06 |
User Systems:
Windows 7 Enterprise 64-bit
Windows 8.1 64-Bit
All running GP version 1.2.3-6
One of my colleagues logged in on Friday night without fail. AFAIK no one attempted to log in either Saturday or Sunday (August 30, 31)
I went to log on on Monday Night and my client on my Windows 8.1 machine complained about the Client Cert Error, but the scary part was it still connected my service?!?!?! I was able to remote work!
Now IT users are set to connect manually while all other user connected automatically, whenever inside the company it will appear as services connected "Internal Network", and normal "Services Connected" when remoting from outside.
Normally when I had this issue it was due to the USER_VPN_Cert not being installed into a users Personal store, either that or the PA Root CA isn't in Trusted CA's store. But nothing changed from when it did work... literally nothing!
I attempted to do a bit of digging myself in the logs to maybe see if there was something obvious that might have changed... from the PAN-GPA log I could only see the following differences from a working session to the now not working sessions...
(T7040) 07/25/14 08:51:25:779 Info (2448): IPADDR=DirectWANPORTALIP,PORT=443,URL=/ssl-vpn/prelogin.esp,POST=1,POSTDATA="tmp=tmp&clientVer=4100",PROXY_AUTO=1,PROXY_CFGURL=NULL,PROXY=NULL,PROXY_BYPASS=NULL,PROXY_USER=NULL,PROXY_PASS=****,VERIFY_CERT=0,ADDITIONAL_CHECK=0
That was from a working sessions and the non working session has ADDITIONAL_CHECK=1, I'm not sure if this might be the cause?
Followed by (both working and none working sessions) List below is directly form non working session, as can be seen by date stamp:
(T4272) 09/02/14 08:28:35:294 Info (1785): PanWinhttpCallback(dwInternetStatus=WINHTTP_CALLBACK_STATUS_HANDLE_CREATED, this=000000000269AD10)
(T4272) 09/02/14 08:28:35:294 Info (1785): PanWinhttpCallback(dwInternetStatus=WINHTTP_CALLBACK_STATUS_HANDLE_CREATED, this=000000000269AD10)
(T4272) 09/02/14 08:28:35:294 Info (2568): winhttpObj->SendRequest, first try
(T4272) 09/02/14 08:28:35:294 Info (1041): winhttpObj, SendRequest, bIngoreClientCert=0
(T4272) 09/02/14 08:28:35:294 Info (1785): PanWinhttpCallback(dwInternetStatus=WINHTTP_CALLBACK_STATUS_RESOLVING_NAME, this=000000000269AD10)
(T4272) 09/02/14 08:28:35:294 Info (1785): PanWinhttpCallback(dwInternetStatus=WINHTTP_CALLBACK_STATUS_NAME_RESOLVED, this=000000000269AD10)
(T4272) 09/02/14 08:28:35:294 Info (1785): PanWinhttpCallback(dwInternetStatus=WINHTTP_CALLBACK_STATUS_CONNECTING_TO_SERVER, this=000000000269AD10)
(T2864) 09/02/14 08:28:35:294 Info (1785): PanWinhttpCallback(dwInternetStatus=WINHTTP_CALLBACK_STATUS_CONNECTED_TO_SERVER, this=000000000269AD10)
(T2864) 09/02/14 08:28:35:294 Info (1785): PanWinhttpCallback(dwInternetStatus=WINHTTP_CALLBACK_STATUS_RESOLVING_NAME, this=000000000269AD10)
(T2864) 09/02/14 08:28:35:294 Info (1785): PanWinhttpCallback(dwInternetStatus=WINHTTP_CALLBACK_STATUS_NAME_RESOLVED, this=000000000269AD10)
(T2864) 09/02/14 08:28:35:294 Info (1785): PanWinhttpCallback(dwInternetStatus=WINHTTP_CALLBACK_STATUS_CONNECTING_TO_SERVER, this=000000000269AD10)
(T2864) 09/02/14 08:28:35:294 Info (1785): PanWinhttpCallback(dwInternetStatus=WINHTTP_CALLBACK_STATUS_CONNECTED_TO_SERVER, this=000000000269AD10)
(T2864) 09/02/14 08:28:35:294 Info (1785): PanWinhttpCallback(dwInternetStatus=WINHTTP_CALLBACK_STATUS_REQUEST_ERROR, this=000000000269AD10)
(T4272) 09/02/14 08:28:35:309 Info (1081): winhttpObj, get WINHTTP_CALLBACK_STATUS_REQUEST_ERROR
(T4272) 09/02/14 08:28:35:309 Error(1103): error = ERROR_WINHTTP_CLIENT_AUTH_CERT_NEEDED
(T4272) 09/02/14 08:28:35:309 Info (1129): winhttpObj, set client cert name VPN_USER_Cert issued by Root Ca
(T4272) 09/02/14 08:28:35:309 Info (1133): winhttpObj, reuse cert 0000000000B2B630
(T4272) 09/02/14 08:28:35:309 Info (1785): PanWinhttpCallback(dwInternetStatus=WINHTTP_CALLBACK_STATUS_RESOLVING_NAME, this=000000000269AD10)
(T4272) 09/02/14 08:28:35:309 Info (1785): PanWinhttpCallback(dwInternetStatus=WINHTTP_CALLBACK_STATUS_NAME_RESOLVED, this=000000000269AD10)
(T4272) 09/02/14 08:28:35:309 Info (1785): PanWinhttpCallback(dwInternetStatus=WINHTTP_CALLBACK_STATUS_CONNECTING_TO_SERVER, this=000000000269AD10)
(T2864) 09/02/14 08:28:35:309 Info (1785): PanWinhttpCallback(dwInternetStatus=WINHTTP_CALLBACK_STATUS_CONNECTED_TO_SERVER, this=000000000269AD10)
(T2864) 09/02/14 08:28:35:341 Info (1785): PanWinhttpCallback(dwInternetStatus=WINHTTP_CALLBACK_STATUS_SENDING_REQUEST, this=000000000269AD10)
(T2864) 09/02/14 08:28:35:341 Info (1785): PanWinhttpCallback(dwInternetStatus=WINHTTP_CALLBACK_STATUS_REQUEST_SENT, this=000000000269AD10)
(T2116) 09/02/14 08:28:35:356 Info (1785): PanWinhttpCallback(dwInternetStatus=WINHTTP_CALLBACK_STATUS_SENDING_REQUEST, this=000000000269AD10)
(T2116) 09/02/14 08:28:35:356 Info (1785): PanWinhttpCallback(dwInternetStatus=WINHTTP_CALLBACK_STATUS_REQUEST_SENT, this=000000000269AD10)
(T2116) 09/02/14 08:28:35:356 Info (1785): PanWinhttpCallback(dwInternetStatus=WINHTTP_CALLBACK_STATUS_SENDREQUEST_COMPLETE, this=000000000269AD10)
(T4272) 09/02/14 08:28:35:372 Info (1092): winhttpObj, get WINHTTP_CALLBACK_STATUS_SENDREQUEST_COMPLETE
(T4272) 09/02/14 08:28:35:372 Info (1171): winhttpObj, since a cert used and https success, we cache this cert(VPN_USER_Cert issued by Root Ca) for now!
This however is new and I did not see this event in previous logs
(T4272) 09/02/14 08:28:35:372 Info ( 710): Server 64.4.72.90 cert verification result is 0x1010040
on another machine I was testing it replied with result of 0x40 instead of 0x1010040.
Any thoughts on what cause this to happen? There were literally no changes made from Friday night, to Monday night as everyone (including IT) was enjoying the long weekend!
05-08-2015 08:37 AM
Opps!
Sooo Sorry, haven't logged on in a really log time since I love these firewalls, and they work amazingly well...
I believe I corrected this by checking the Global Protect settings on the Firewall themselves and I believe somehow the portal had lost which cert it was using for it...
It's long been fixed... I really should have came here and provided the answer as soon as I resolved it.
Thanks for the suggestion.
03-17-2015 09:14 AM
do you open a support case? if not I advice you to do it.
05-08-2015 08:37 AM
Opps!
Sooo Sorry, haven't logged on in a really log time since I love these firewalls, and they work amazingly well...
I believe I corrected this by checking the Global Protect settings on the Firewall themselves and I believe somehow the portal had lost which cert it was using for it...
It's long been fixed... I really should have came here and provided the answer as soon as I resolved it.
Thanks for the suggestion.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!