Ignite'18 Wrap - Answer the orphaned questions and bag some swag

Community Team Member

You may have seen Editeur's post about all of the wonderful questions that we were getting from the Live Community booth at Ignite18. If you missed them, check them out here:


The latest from the great wall of knowledge at Ignite

Final round of Q&As from Ignite '18 


Also see our new director's blog of questions, answers, and some great photos in:

Views from the Ignite Floor


But what about any of the "unanswered" questions that were left on the wall? 

questions-left.jpgSome of the unanswered questions from Ignite18.

Well, I am glad you asked about the unanswered questions -- the yellow tickets (questions) without a blue ticket (answers). We call them the 'orphaned' questions, still in need of forever homes and answers.


A handful of questions were left over, but rather than post all that were left, I decided to post up just a couple to start out.  I am posting 4 questions that were not answered. I know the photo above shows more questions, but the other questions were either combined or out of scope.


If you're able to provide the first correct answer, we will reward you with some Palo Alto Networks swag. Perhaps something from the booth, or a surprise. We are going to keep it a secret until the winners are announced.


Here are the 4 vetted questions:

  1. How to enable GlobalProtect? Answered, thanks @bspilde
  2. How do we see/find where the Linix GlobalProtect client stores or looks for the Certificates (which cert store)?
  3. Why are the size limits for PDF WildFire scanning so small? Answered, thanks @hshawn
  4. Why do policy rules not show duplicates or shadowing in the ruleset? (I only see them when committing) Answered, thanks @bspilde

Again, rules are simple...the first correct answer wins, and when you answer, put the question # that you are answering.


Please don't be shy...answer away and maybe you can win something.


Stay secure!

Joe Delio

End of line.

Community Team Member

love the visaul here, @jdelio! okay, folks, let's bag some swag!

L4 Transporter

For #3 above "Why are the size limits for PDF WildFire scanning so small?"


The short simple answer is:

Because the size limit is a threshold for the average malware sizes per file type (pe, pdf, apk, etc) as observed by the threat research team at Palo Alto.


The long answer is:

(Taken from  https://www.paloaltonetworks.com/documentation/80/wildfire/wf_admin/submit-files-for-wildfire-analys... )


The default file size limits on the firewall are designed to include the large majority of malware in the wild (which is smaller than the default size limits) and exclude large files that are very unlikely to be malicious and can impact WildFire forwarding capacity. Because the firewall has a specific capacity reserved to forward files for WildFire analysis, forwarding high numbers of large files might cause the firewall to skip forwarding some files. This condition might occur when the maximum file size limits are configured for a file type that is traversing the firewall at a high rate. In this case, a potentially malicious file might not be forwarded for WildFire analysis. Consider this possible condition if you would like to increase the size limit for files other than PEs beyond the default size limit.


The site goes on to list recommended size limitations you can set if you would like to adjust it for the more rare larger malicious files. I recommend taking a look at the info in the link provided. It is a quick and good read on this subject matter/question.



L4 Transporter

I have to come forward and say the Linux GP client cert store was my question... I have been hammering at this for a while now and still no luck. Info for anyone who might try to help with this one:


* The Linux client works very well on Ubuntu (After importing the server cert into the default cert store, you can use a few ways to do this. If you want an easy way of importing it with a nice GUI you can use a free app called kse)

* The Linux client does not find the server cert no matter where I place it on my Kali research box (this is odd since it is a debian based distro just like Ubuntu)

* I have not tried the Linux client on Fedora, CentOS, Debian, etc

* Looking at the GlobalProtect binary using "strings GlobalProtect | less" and searching for /etc/ssl I see the following paths in the binary: /etc/ssl/certs and /etc/ssl/certs/ca-bundle.crt and /etc/pki/tls/certs/ca-bundle-crt so naturally I tried placing my server cert and even crfeating a ca-bundle with openssl and popping it in place but still get the error message when attempting to connect


Error: Gateway GP_VPN_Gateway: The server certificate is invalid. Please contact your IT administrator.


* I do not get this error with Mac, Windows or Linux (using Ubuntu)  clients


I was hoping I just needed to find the right location to drop the cert and the GP client would find it but I am starting to wonder if there is something else at play here coded into the GP client that is causing the problem on certain Linux distros and the server cert error is not entirelly accurate? 

Community Team Member

@hshawn, Thanks for answering Question # 3.  That is correct, and we can see what we can award you as a prize for answering that correctly, as well as being the first to provide an answer.


Also, thanks for coming forward on the GlobalProtect certificate question, I hope that some answer can be found for you soon on that one.

L4 Transporter

#2 @hshawn I was on the beta for Linux GlobalProtect. I'll reach out to engineering to see if they might be able to answer your question. -Brad

L4 Transporter

Answering #4:

Why do policy rules not show duplicates or shadowing in the ruleset? (I only see them when committing)


I would say the answer to this question is simple, yet a feature request can and maybe should be submitted through your Sales Engineer. The answer to this question is that the verification checks in PAN-OS on configuration requirements in most if not all cases only runs on a commit or a validation check. To check for these Palo Alto had added the Validate option vs having to commit the configuration and then see the failures, shadowing, etc.


I recommend always doing a validate commit:


  • Configuration is valid
  • Certificate xyz.cert in shared expired on Jun 28 18:39:11 2017 GMT
  • vsys1
  • Security Policy:
  • - Rule 'P_GlobalProtect-1' shadows rule 'P_GlobalProtect'
  • (Module: device)
  • Warning: tunnel tunnel ipv6 is not enabled. IPv6 address will be ignored!
  • (Module: rasmgr)
L4 Transporter

Answering #1: How do I enable GlobalProtect


Almost everything you need to know on configuring GlobalProtect can be found here:



Otherwise the admin guide does a great job for each specific OS on enabling GlobalProtect. https://live.paloaltonetworks.com/t5/custom/page/page-id/GlobalSearch#q=global%20protect%20user%20gu...


If you are using certificates and doing pre-logon, this is a good resource: https://live.paloaltonetworks.com/t5/Configuration-Articles/Basic-GlobalProtect-Configuration-with-P...


Hope that helps!

L0 Member

Any chance the top 3 could be posted from the CyberSecurity Quiz at the Fuel Booth? I can't find anything about it anywhere.

Community Team Member

@PPGMShelton, I will reach out to the Fuel group and see if they can provide me that CyberSecurity Quiz, and if they can, I would be more than happy to post them somewhere for you and everyone else.


@bspilde Looks like you have been doing your homework.. 

As far as I am concerned, those answers for #4 and #1 are correct. So I will mark those as complete, and now we have to see what else we have for swag to send your way.


So, we only have Question #2 left..   Who can step up and answer this?

L1 Bithead

I've found that GlobalProtect client drops the trusted root CA that has been configured to clients into /opt/paloaltonetowkrs/globalprotect/tca.cer


Hope this helps.

L4 Transporter

@andrew571 thanks!


I tried exporting my cert as a .cer and popping it in as opt/paloaltonetowkrs/globalprotect/tca.cer but still get the same message that the GP portal is not using a trusted cert. This may turn into a support ticket but I already predict they will say "We don't support that Linux distro" so figured I would poke at it myself for a while to see what I could find out.



L1 Bithead

It sounds as if you need to configure your portal to push the CA's certificate to the client, after that it will automatically trust any certificates issued by the your CA, namely the one issued to the portal.

If you're still having issues with trust despite having the CA's certificate installed, then maybe there is a mismatch between the CN (subject) in your cert and the FQDN of your portal; they have to match.


I tested on Kali Linux with GP installed and I am using an internal CA signed Portal cert, and it works fine.  The very first time it connects, it complains that the cert is untrusted, which is expected, but after that, it happily connects every time.


Kali version: 4.13.0-kali1-amd64 #1 SMP Debian

Global protect version: 4.1.2




Ask Questions Get Answers Join the Live Community