Linux GP client

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Linux GP client

L4 Transporter

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

 

 

1 accepted solution

Accepted Solutions

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.

View solution in original post

12 REPLIES 12

Cyber Elite
Cyber Elite

@hshawn,

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

@BPry

 

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

@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

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

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

 

 

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

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

That link is now 404.

@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 😕

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.

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.

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

  • 1 accepted solution
  • 6597 Views
  • 12 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!