Now that there is a Linux GP client... How do we get it?
The page Titled "Download and Install the GlobalProtect App for Linux"
"Obtain the app package from your IT administrator and then copy the TGZ file to the Linux endpoint." - Well I thats me
Solved! Go to Solution.
Looks like this was impacted by the same issue as the windows client where it would not accept passwords with < and/or > in them. After swapping those characters out the connection is established without any issues.
What did we learn:
* there is a password length limit in the 4.1 client
* The 4.1 client will not connect if you have a < or > in your password
* The OSX 4.1 client *does* work with
* The Linux client suffers from the same character issue as the Windows client
* I do not know if the Linux client suffers from the password length issue reported by someone else in the Windows client post.
Linux version is production 4.1.0-91
Some things I have encountered:
* After entering my username and pass it just sits there and never finishes the connection (not seeing a log of useful into while tailing the logs)
* Even after importing the certs it still complains that the certs are not valid
* It is logging your password when you import the certs as plain text in the PanGP log file wow c'mon!
P13369-T176146176 Mar 07 12:00:30:688706 Info ( 221): InitConnection ...
P13369-T176146176 Mar 07 12:00:30:688759 Debug( 54): fd still open before connect
P13369-T176146176 Mar 07 12:00:30:688823 Error( 72): Failed to set nosigpipe
P13369-T176146176 Mar 07 12:00:30:692115 Debug( 345): CPanSocket::OnConnect - portal message sent.
P13369-T176146176 Mar 07 12:00:30:692134 Info ( 233): Connecting to Pan MS Service end
P13369-T201324288 Mar 07 12:00:31:130433 Debug( 777): Send command to Pan Service
P13369-T201324288 Mar 07 12:00:31:130447 Debug( 791): Command = <request><type>portal</type><portal>XXXXXXXXXX</portal><pid>13369</pid><user>XXXXXXXXXX</user><passwd>******************</passwd><path>/user/.GlobalProtect</path><checkupdate>no</checkupdate><allow-cached-portal>yes</allow-cached-portal><remember-me>yes</remember-me><retrieve-cache-only>no</retrieve-cache-only><manual-select-gateway-ip></manual-select-gateway-ip><portal-certificate-verification>yes</portal-certificate-verification><win-user>XXXXXXXXXX</win-user><saved-user>XXXXXXXXXX</saved-user><saved-passwd>*****************</saved-passwd><portal-2fa>no</portal-2fa><gid>0</gid><domain></domain></request>
P13369-T201324288 Mar 07 12:00:31:130499 Debug( 848): PanClient sent successful with 640 bytes
P13369-T192931584 Mar 07 12:00:33:2845 Info ( 256): agent ui socket closed!
P13369-T184538880 Mar 07 12:00:35:955884 Info ( 221): InitConnection ...
P13369-T184538880 Mar 07 12:00:35:955913 Debug( 54): fd still open before connect
P13369-T184538880 Mar 07 12:00:35:955948 Error( 72): Failed to set nosigpipe
P13369-T184538880 Mar 07 12:00:35:955997 Error( 75): Failed to connect to server at port:4767
P13369-T184538880 Mar 07 12:00:35:956003 Error( 225): Cannot connect to service, error: 111
P13369-T192931584 Mar 07 12:00:36:47824 Info ( 256): agent ui socket closed!
P13369-T176146176 Mar 07 12:00:36:693866 Info ( 221): InitConnection ...
So few things about that, and keep in mind that I'm not by any means actually affiliated with PAN. The passwd value that you are seeing in the logs would also be present on the Windows version of the logs.
The command that the log is recording is actually the command that gets sent from the PanClient to the PanGPS service. This is then securly passed to the gateway. So while they are storing the password in clear text (still bad), it doesn't actually pass it in the clear.
If you want to get rid of this, and I think it's actually following the published best-practice guide, you would actually disable the option to save the password on the client options by modifying the 'Save User Credentials' to 'Save Username Only' instead of 'Yes'.
Again, not saying that PAN should be storing the password in the log file; completely agree that this should be masked or otherwise not actually recorded.
The user's VPN PW is masked in the logs. It is the local account password used to import a cert for global protect that is in the clear. While this is not sent over the wire it would make it outside if logs are sent to support etc...
I'm starting to think this issue is the same I'm seeing with the 4.1 windows client since it seems to just hang when connecting. This is going to end up being a painful support call lol... "Linux? Uh.... Have you tried turning it off and on again?"
Looks like it is back now.
p.s. anyone know where the certs are stored for the GP linux client? I can validate my CA cert exists on the system I see it in the proper directories and I have imported it using the globalprotect import-certificate command but it does not see the cert when connecting. I am unable to find the details as to where it expects to find it in a Linux environment :/
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The LIVEcommunity thanks you for your participation!