Linux GP client

[hshawn]

Now that there is a Linux GP client... How do we get it?

Details:

https://www.paloaltonetworks.com/documentation/41/globalprotect/globalprotect-app-new-features/new-f...

The page Titled "Download and Install the GlobalProtect App for Linux"

https://www.paloaltonetworks.com/documentation/41/globalprotect/globalprotect-app-user-guide/globalp...

"Obtain the app package from your IT administrator and then copy the TGZ file to the Linux endpoint." - Well I thats me

but...where...is...it...?

[BPry]

@hshawn,

You can download the Linux GP from the https://support.paloaltonetworks.com portal. 

[hshawn]

@BPry

Thanks once again! It was waaaaaaay at the bottom of the list instead of being grouped with the other GP clients, found it!

[jdprovine]

@BPry

Is that the beta version, I gave one of my users the beta version, I have no idea if they have tried it yet

[BPry]

@jdprovine,

I'm pretty positive that it's not the exact same build. If you have anyone running/trying 4.1 at this point I would make sure that they get the published build. 

[hshawn]

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 ...

[BPry]

@hshawn,

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. 

[hshawn]

@BPry

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?"

[BBenson-orocktech]

That link is now 404.

[hshawn]

@BBenson-orocktech

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 😕

[hshawn · Accepted 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.

[RbadigerCY]

I have another query with new Global Protect client for linux.

Currently we are using VPNC StrongSwan for VPN to our network and we have enabled X-auth, group name and password.

Once we move to Globla Protect client for linux, can we remove X-auth, group name and password? I assume these configuration will be ignored.

Thanks in advance.

[BPry]

@RbadigerCY ,

That would be correct; the GlobalProtect agent for Linux doesn't require X-Auth to be configured. If they were the only clients utilizing X-Auth you should be good to completely remove this configuration once you've moved everything to the actual GlobalProtect agent.