GP 4.1.0 released and....

[hshawn]

I have not seen any chatter or mention of this but I tried the 4.1.0 GP client in a lab environment yesterday.

The good:

* The app is redesigned and looks really nice

* You can now select from/add/remove multiple gateways!

The bad:

* It would not connect to the VPN even after a reboot and reinstall 😕

After going back to 4.0.7 everything worked again, then trying 4.1.0 again and same thing (no connection) then back to 4.0.7 and yay! working again. I see the traffic coming into the portal and being allowed, the client just never gets an established connection.

Anyone else brave enough to play with the new GP client? What did you find? Did it work? Same issue I am seeing?

Whats next:

I will try the new client on some other machines and OS versions to see if I can isolate the issue to a certain root cause. We won't be using this in production for a while or at least until I can validate this issue will not happen if we update all endpoints someday.

[hshawn]

I am not seeing anything helpful in the logs... but just to make it more confusing... it *works* on OSX!!

to summarize:

* OSX - working

* win7 - nope

* win10 - nope

* Linux - nope

I have created a support ticket, I can't help feel like we are always seeing crazy one-off nobody else has that issue type of things all the time.

[ChrisSmith]

How long is your password?  I'm having an issue where the 4.1 client won't accept the last 3 characters of my password.  I have a 25 character password.  Frustrating.

[ChrisSmith]

Just rolled back to 4.0.7-5 and password works fine.  Staying away until next release.

[hshawn]

@ChrisSmith

I think you just handed me the best clue! My password is 17 characters so I don't think its an issue of password length (for me anyway) I was looking at the logs (the PanGPS.log specifically) and noticed some odd broken XML in there then after reading your post I was looking at my password and noticed that part of my password was in the XML.

I think what is happening here is certain characters in the password are breaking it (notice line 3 below) The password character that appears before the broken XML tag is a < and after that is a > so I bet if i change my password to remove the < and/or the > it will be the magic fix for me. BUT Since prior versions don't break with that character and PA does not specify we cannot use that character, I think maybe they should fix the app and change their code to properly escape special characters.

(T5104) 03/08/18 18:47:04:975 Info ( 438): msgtype = hello
(T5104) 03/08/18 18:47:04:976 Debug(1120): Send response to client for request hello
(T5104) 03/08/18 18:47:05:479 Error(1455): end tag </7BsoX> not found
(T5104) 03/08/18 18:47:05:479 Error(1488): end tag </saved-passwd> not found
(T5104) 03/08/18 18:47:05:479 Error(1488): end tag </request> not found
(T5104) 03/08/18 18:47:05:479 Info ( 410): Message is not valid XML. Message is <request><ty
(T5104) 03/08/18 18:47:05:479 Info ( 194): Error processing receive data from client
(T5104) 03/08/18 18:47:05:479 Info ( 200): close client socket

This is just my theory and it really lines up with everything, I may test with a new password when I have time tomorrow and I will upadate my case with this new information. Thanks all for the dialog I feel pretty confident this is it.

[BPry]

@hshawn,

That's actually really interesting, and likely why you don't have many people running into it. I know that I have some users however that do actually utilize these characters in there password, so I'll have them give it a try. 

[hshawn · Accepted solution]

Confirmed!

I changed the test user password and removed/swapped out the < and > characters and I was able to sign in right away without any issues using the 4.1 client.

This means PA has to resolve this before rolling the app out to the masses in order to prevent any such instance of this problem occuring with anyone using those characters in their passwords.

If you do roll this version out and some users are unable to connect, it may be related to special chars in their passwords.

Thanks again for everyone's input that lead me to this finding. I have a case open and I will update it and inform our SE of these findings.

[ChrisSmith]

I'm glad you narrowed it down to special characters in your case, I have a special character in my password but there also appears to be an issue with the password length.  When typing in my password at the 20th or 21st character the input box doesn't allow any more input and the computer gives the angry chime that it's not accepting it.  The last 10 or so characters of my password are not special or numeric.  I think we have multiple issues going on.

[hshawn]

@ChrisSmith

Yeah sounds like it. Out of curiosity are you able to test the linux or OSX clients? the linux client is command line so there is no limit applied at that level it is worth a shot.

I would reccomend reaching out to your SE and let them know of the character limit on that field. I'm sure you arent the only one with a password of that length or longer just like I cannot be the only one with < or > in my password.

[jambulo]

I have discovered an issue that only applies if you have Always-On enabled and enforcing a GlobalProtect connection for network access.

What happens is...

1. User logs into Windows.

2. GlobalProtect connects to Portal/Gateway.

3. GlobalProtect prompts for authentication.

4. If the user does not authenticate within 10-15 seconds of receiving the auth prompt, GlobalProtect will minimize(in the system tray) the auth prompt, and display the "Traffic Blocking Notification" message.

I have noticed that this only happens when you do a fresh logon into Windows.  When switching between an "internal" and "external" network, the auth prompt is not effected.  A fresh logon into Windows gives you a balloon type auth prompt next to the system tray.  Switch between internal/external networks gives you a pop-up window for the auth prompt.

[hshawn]

@jambulo

we are using pre-logon onlways on and our testers here have not seen that so far but we are using the windows SSO and cert for auth so the users dont get prompted for a GP logon. There are some timeout settings in the portal app config section that may be at play there?

[fjwcash]

---

@hshawnwrote:

@ChrisSmith

I think what is happening here is certain characters in the password are breaking it (notice line 3 below) The password character that appears before the broken XML tag is a < and after that is a > so I bet if i change my password to remove the < and/or the > it will be the magic fix for me. BUT Since prior versions don't break with that character and PA does not specify we cannot use that character, I think maybe they should fix the app and change their code to properly escape special characters.

(T5104) 03/08/18 18:47:04:975 Info ( 438): msgtype = hello
(T5104) 03/08/18 18:47:04:976 Debug(1120): Send response to client for request hello
(T5104) 03/08/18 18:47:05:479 Error(1455): end tag </7BsoX> not found
(T5104) 03/08/18 18:47:05:479 Error(1488): end tag </saved-passwd> not found
(T5104) 03/08/18 18:47:05:479 Error(1488): end tag </request> not found
(T5104) 03/08/18 18:47:05:479 Info ( 410): Message is not valid XML. Message is <request><ty
(T5104) 03/08/18 18:47:05:479 Info ( 194): Error processing receive data from client
(T5104) 03/08/18 18:47:05:479 Info ( 200): close client socket

---

Okay, now that is just scary!

Why is the client sending the password to the server?  In plaintext, to boot!  Shouldn't the client be hashing the password and just sending the hash to the server?  You know, how every other authentication system out there does things.

I was intrigued by the promise of a Linux client, but there's no way I'll be putting this anywhere near even a test system until that glaring flaw is fixed!

[hshawn]

@fjwcash

To be fair I do not think it is actually sending the password cleartext. On a successful login you can see the password is ************ in the logs however it is concerning that it is somehow getting into the logs before it is hashed and breaking the entire process. PA is aware of the issue and will hopefully have a fix soon.

[CaviumKeith]

Not really "Solved" but a work around for special characters.  (Don't use < or > in your password).  Also, don't have a password over 20 characters in length, or is it 22... ?

[hshawn]

@CaviumKeith Well... of course that will work but try telling that to a handful of angry users that cannot get connected. If you have thousands of employees and enforce strong passwords you could end up with 10's or 100's of users impacted by this. I have not heard anything recently but I beleive they are working on a fix for this (I hope)

[CaviumKeith]

Agreed, which was my point.  There are also issues regarding the Linux Agent, but that's for another post.