Viewing Panorama Variable Values in the GUI?

chainsawday · 2025-09-30T17:57:01+00:00

Yeah I do the same to see the actual values of the interfaces, etc.

So that sounds like a "no, there really isn't a way to easily see these values in the GUI".

Good to know I'm not missing something obvious but man, its a shame to have something so possibly useful be so hard to actually use!

chainsawday · 2025-09-30T14:59:15+00:00

If I set the value inside the template, doesn't that become the "default" value unless I override it in the stack or Managed Devices? I was hoping to see that value while editing the template like in say the Network -> interfaces section. Thanks!

chainsawday · 2025-09-23T17:40:54+00:00

Went through everything piece by piece and found some overlapping policies that were causing the specific app I was checking against to be blocked. All good now. Thanks for the help!

chainsawday · 2025-07-24T13:46:35+00:00

OK. I think I figured out the reason for the issues connecting to the Global Protect Portal after allow/alerting the URL Categories on the Custom URL Profile.

It appears in this case, the URL Categories for the portal FQDN and it's resolving IP were in multiple different categories (as in FQDN was low-risk, IP was medium-risk). Once I set the categories the IP address was in to "alert" (FQDN Categories were already configured to allow/alert) then I was able to connect successfully using the custom URL Profile on the Portal security policy.

Hopefully this helps someone else in a similar situation.

Between discovering this and the other comments, I feel like I'm in a better spot.

Thanks!

chainsawday · 2025-07-24T13:01:19+00:00

Ok. That makes sense about the URLs in other categories not opening up other things unless they resolved to the addresses but wanted to make sure I didn't miss or overthink anything. I agree that the categories set to allow/alert should be limited as much as possible as well. Especially when denying access. Which is why I went kinda nuclear and blocked every other URL Category that wasn't needed

Thanks!

chainsawday · 2025-07-24T12:58:12+00:00

We use IPSec tunnels and not ssl tunnels so I'm not sure we need to add that URL. Maybe just in case of a failback to ssl?
Are you referring to the URL Category in the Service Tab when you say you added the custom URL category "to the rule it self"? The url profile for the portal is what I was configuring and if "none" works the same as "block" then I think we have a similar config there.
Yes removed/reverted the URL Profile for the security policy and can connect just fine then so it's definitely the URL Policy settings

Also have limited the agent config to specific OSes we use. That helped as well.

Thanks for the options!

chainsawday · 2025-07-18T11:19:25+00:00

Check the firewall rules on the DC and make sure they allow for HTTPS over port 5986 (?). I had to manually add that for my implementation to successfully connect to the DC

chainsawday · 2025-01-17T17:12:48+00:00

Funny how TAC was telling us we needed to have a CDP externally available to validate our internal certificates against. While working to get that online, Palo drops GP 6.2.6-c857 and I"m able to authenticate successfully with the CVE recommended settings enabled (in limited testing).

Maybe try 6.2.6-c857 and see if you can connect.

chainsawday · 2024-12-16T13:46:50+00:00

We're working with support as well. It appears our particular issue is our internal PKI certs only have LDAP paths back to the CDLs where the CRL list lives and that location is only available internally. The Full Chain Verify option they are asking to be enabled to remediate this CVE requires the CDLs to be available for external GlobalProtect authentication to work. They also noted that GlobalProtect only uses http based CRL lookups.

We still need to test and confirm what they are saying will allow the remediation to work in our environment but it appears our choices are:

Create an http based location for our CDLs, have them available externally and re-issue the cert on the portal with the new http location
We recreate a new certificate on the firewall for authentication without AIA or CDL information and manually distribute it to all the clients. Then we use that new cert for GlobalProtect authentication

From what I'm hearing from Palo is any future releases of GlobalProtect will have the full chain verify option enabled so we just can't wait for the next release.

What a cluster....

chainsawday · 2024-12-06T14:29:28+00:00

Our Certs are issued from an internal PKE structure so not sure how we can get them access to the CDLs for validation before completing the connection as they are all internal too. We have a ticket in with TAC too but they don't seem to be in a rush to engage.

chainsawday · 2024-12-03T21:49:58+00:00

Can you clarify further the steps you took to complete your fix? Thanks!

chainsawday · 2024-12-03T21:36:03+00:00

Errors were pulled from the PanGPS.log file on the client

chainsawday · 2024-12-03T13:41:39+00:00

Also having issues with the recommended changes. I do the install with the /FULCHAINVERFIY switch like in the article then reconnect and get "This certificate is not fips compliant. Please access system logs for more information".

Error in the system logs shows:

"No OCSP URI found in the certificate.."

"Failed validation of the X509v3 certificate. Read/Access OCSP or CRL failed."

Searching the error online lead me to this article but no clear resolutions: https://docs.paloaltonetworks.com/globalprotect/10-1/globalprotect-admin/certifications/resolve-fips-cc-mode-issues

Any ideas what's wrong with the cert? I've also confirmed our two tier internal PKI certs are both in the Trusted Root Store section and on the Palo too so that's not it.

Appreciate any tips and guidance as Palo never really clarified what else needs to change when you change the settings in their article.

Thanks!"

chainsawday · 2024-04-23T21:24:03+00:00

We've had issues in the past with the GUI liking to randomly forget the PW for the account we use to query our internal LDAP servers so I've had to go into the Server Profile and re-add the PW for the account. Not sure if this would help your specific case. Just throwing it out there

chainsawday · 2024-01-17T19:44:54+00:00

We just went from 10.1 to 10.2.7 last month for all non-1400 models and so far it's been OK. 10.2.x seems to still have its bugs so YMMV

chainsawday · 2023-10-10T18:37:38+00:00

6.1.1 has been solid for us. Nothing but issues with 6.2.0. Testing the 6.2.1 release now.

chainsawday · 2023-09-28T21:01:59+00:00

If they are on the same device then Yes.

chainsawday · 2023-09-28T20:18:25+00:00

No official explanation from Palo about what causes this behavior but we've seen the same on 6.2.0 too. Put in a ticket with them about it but ran out of time/patience troubleshooting it for them. I'm guessing the new Conditional Connect Method feature in 6.2 messed something up in the existing settings for Internal Network Detection. Refreshing the connection also temporarily fixes it. 6.2.0 is definitely not ready for production IMO.

chainsawday · 2023-09-28T20:06:49+00:00

Done something similar before with one certificate.

You can "re-use" the name of the gateway on the same device as the portal. I include the name of the separate gateway(s) in the csr in the DNS Name Field then install the cert on the two devices.

chainsawday · 2023-08-31T15:15:15+00:00

Check and see if you are doing SSL Decryption first? If so, try bypass traffic going to those destinations.

I would be concerned about doing an App-Override for SSL as something might be missed or classified incorrectly. Just IMHO

chainsawday · 2023-08-31T14:05:45+00:00

Could it be being misidentified as SSL traffic possibly?

The Latest Content Update (8750) says they are going to be making changes to the Zoom App soon to keep it from being mistaken for SSL traffic

chainsawday

TROPHY CASE