About TonyDeHart

TonyDeHart · ‎04-11-2024

Does using "transparent" as the upgrade mechanism cut off the VPN and then do the upgrade and force it to login again? I'm trying to figure out how that does it transparently unless it queues up the install until the next time it logs in or runs GP.

TonyDeHart · ‎04-11-2024

Why I could not find that I do not know but thank you that is a big help!

TonyDeHart · ‎04-10-2024

I've looked and cannot find a screenshot of what is presented when the Global Protect portal presents a new updated GP to be downloaded. Would anyone have a screenshot? I can find none in the documentation. In other words, if GP Portal is set to update with prompt what shows up? I'd like to provide some documentation to our users and I can't test this because once I enable a new GP version the users will get prompted.

TonyDeHart · ‎04-09-2024

When GlobalProtect connects to the firewall for the first time with proper credentials, it removes the registry keys in the original post. Anyone have any idea why it adds them and if there is a way to stop it?

TonyDeHart · ‎04-03-2024

I've determined that removing this key and rebooting fixes this issue but WHY does GP add this in the first place and then subsequently remove it once you've logged in to the VPN at least once? [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers\{25CA8579-1BD8-469c-B9FC-6AC45A161C18}] @="PanV2CredProv"

TonyDeHart · ‎04-03-2024

We use RSA's MFA Agent for Windows authentication. When we install or update GlobalProtect, it disables the MFA Agent at Windows login until we connect at least once via the VPN. It appears it is adding itself as an authentication provider into the Windows Login UI and I suspect it is related to these registry entries below. Has anyone found a way to prevent this during the installation via a command line switch or some other method? It is of course of concern for us as it is a security risk not having RSA enabled. (FYI - this has happened with multiple versions of 6.1.x - latest being 6.1.4 - and we do have connect-before-login enabled for GP) [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{25CA8579-1BD8-469c-B9FC-6AC45A161C18}] @="PanV2CredProv" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{25CA8579-1BD8-469c-B9FC-6AC45A161C18}\InprocServer32] @="PanV2CredProv.dll" "ThreadingModel"="Apartment" [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers\{25CA8579-1BD8-469c-B9FC-6AC45A161C18}] @="PanV2CredProv" Once we connect the VPN these registry entries are removed.

TonyDeHart · ‎12-29-2023

Thanks. I'll give that a try.

TonyDeHart · ‎12-01-2023

Interesting. I'll have to explore that idea. Thank you for the suggestion!

TonyDeHart · ‎11-06-2023

To the best of my recollection, all I was missing was the enablement of the SNMP using the management profile on our inside trusted interface. I don't remember having to change anything after that to get it to work. Do you see it in the logs now that it is on the inside? (it plainly shows in my traffic logs once using the inside interface vs the mgmt interface)

TonyDeHart · ‎11-02-2023

So I ran an "experiment" of sorts this morning to see if this FQDN policy really sticks and works and found an interesting anomaly which I can only chalk up to bug or some sort of CLI issue. When I spun up the VGN in Azure which of course assigned a new IP address to my FQDN, the endpoint immediately showed up properly using the "show dns-proxy fqdn all". However, using the "show running security-policy" command continues to show the OLD IP address in the policy information. Despite this, the IPSEC tunnel comes up and the GUI shows a match on the FQDN rule. The IPSEC Tunnel activation however took a short bit of time so it wasn't immediate but it doesn't appear the "show running security-policy" is a reliable indicator of what IP address is actually being used. Either way, I'm happy! It works and I can avoid changing the rules/objects every time we tear this down and turn it back up again.

TonyDeHart · ‎11-01-2023

The FQDN showed up correctly after executing the show dns-proxy fqdn all command. I added an FQDN object for it again to the same rule and it showed up as 0.0.0.0 still. But, when I added another rule with that FQDN object it showed up with the IP and then thereafter even modifying the original rule it showed up with an IP when running "show running security-policy" so now I'm not sure what happened or why it works now. Previously, all I ever got was 0.0.0.0 in the policy. I'll leave it and see if this persists as usable for the time being. It would be great if it does. Thanks for everyone's help. P.S I'm still on 10.0.6 on this FW - is it possible this is a bug? I'll be updating to 10.2.5 soon.

TonyDeHart · ‎11-01-2023

Admittedly it is very short at 1 minute but I don't control it as its assigned by Azure. (default TTL = 60 (1 min)) The fqdn resolves properly in the CLI and more importantly, the IPSEC tunnel uses it when defined there. It is just the object itself fails in the security policy.

TonyDeHart · ‎11-01-2023

I can't this afternoon but can probably give it a shot sometime tomorrow when I can put the rules back. Even if I can't use it I'd like to understand why it does or does not work and how it works. Interestingly at the CLI when I show the security policy where the FQDN goes I see 0.0.0.0 in its place in the source/destination. Is that normal?

TonyDeHart · ‎10-31-2023

I've never had the opportunity to use or need to use an FQDN in a security policy before but my first attempt to do so does not seem to be working. I'm trying to use an FQDN to restrict IPSEC/IKE traffic from a Virtual Network Gateway (VNG) in Azure. The public IP has to be dynamically assigned and we tear down the VNG and put it back in place periodically and each time it is created it gets a NEW public IP address. I can point to the FQDN for this public IP address and it appears to resolve properly both in the GUI and from the CLI. In fact, showing the VPN gateways shows it pointing to the proper public IP in azure using the FQDN. However, the security policy keeps missing the traffic for some reason and it falls through to the clean up deny rule. I don't understand why and I'm not certain how to troubleshoot this as the DNS lookups and other items seem to be using the proper IP for the FQDN defined. FYI - the security policy is simply two objects - destination FQDN and outside IP of the firewall allowing IKE/IPSEC. Statically defining the IP for the object in the rule works fine. Switching to an FQDN object is where it fails. Any ideas?

TonyDeHart · ‎10-31-2023

(sorry for the repost but the other forums/topic areas just don't ever seem to get a response when I post there and are much less active) In the deployment guides and conversations I've had it seems that the PA-VM firewall in Azure is typically designed around only four interfaces: trust, untrust, mgmt, HA. Two zones only: Trust/Untrust. Subnets used to isolate traffic. In my on-prem setups I've always had zones associated with either the interfaces or VLANs on those interfaces to help differentiate application of policies. I feel like it makes in plainly obvious in the policy where that traffic is coming from and going but prevents inadvertently allowing something you don't want allowed. I'd prefer to keep the ability to use the zones vs subnets and subnet groups. Is there a way to create another Zone for a subnet within Azure? I don't believe VLAN's are available in Azure so that options seems out. I'd like to setup a DMZ zone since that just seems more elegant to use and easier to read when looking at Policies. Palo support had suggested adding another interface but that doesn't seem like an option nor does it seem advisable based on what is considered a standard setup in Azure. The VM that the PA-VM runs on right now too is limited to four interfaces.

Member Since	‎02-09-2023 07:25 AM
Date Last Visited	‎02-25-2026 05:38 AM
Posts	122
Total Likes Received	25

Online Status	Offline
Date Last Visited	‎02-25-2026 05:38 AM

About TonyDeHart

GlobalProtect - reject logon attempts for GP versions less than X

Re: GlobalProtect SSL Cert change take effect immediately or require new GP session login?

GlobalProtect SSL Cert change take effect immediately or require new GP session login?

Re: Meraki behind PA - Unfriedly NAT

Re: Webpages are loading very slow

Re: URL Filter Inline Categorization SLOW/DELAY - troubleshooting?

Re: URL Filter Inline Categorization SLOW/DELAY - troubleshooting?

Re: URL Filter Inline Categorization SLOW/DELAY - troubleshooting?

URL Filter Inline Categorization SLOW/DELAY - troubleshooting?

Re: How can I see if my FW has already been exploited by the CVE-2024-3400?

Re: GlobalProtect SSL Cert change take effect immediately or require new GP session login?

Re: PAN-SA-2023-0004 - GlobalProtect fix being worked on for this vulnerability?

Re: Webpages are loading very slow

URL Filter Inline Categorization SLOW/DELAY - troubleshooting?

Re: How can I see if my FW has already been exploited by the CVE-2024-3400?

Re: Clarification on App Rule - I thought I understood this

Re: GlobalProtect SSL Cert change take effect immediately or require new GP session login?

Re: GlobalProtect Automatic Update screenshot?

Re: PA-VM in Azure - multiple Zones? (e.g. DMZ,Trust,Unstrust,etc)

Re: FQDN Object in Policy - not working but FQDN seems to resolve properly

Re: GlobalProtect Automatic Update screenshot?

Re: GlobalProtect Automatic Update screenshot?

GlobalProtect Automatic Update screenshot?

Re: GlobalProtect windows negating/disabling RSA Authentication

Re: GlobalProtect windows negating/disabling RSA Authentication

GlobalProtect windows negating/disabling RSA Authentication

Re: Device Block List for GlobalProtect - where is it in v10.x?

Re: PA-VM in Azure - multiple Zones? (e.g. DMZ,Trust,Unstrust,etc)

Re: SNMP response on two interfaces? Possible?

Re: FQDN Object in Policy - not working but FQDN seems to resolve properly

Re: FQDN Object in Policy - not working but FQDN seems to resolve properly

Re: FQDN Object in Policy - not working but FQDN seems to resolve properly

Re: FQDN Object in Policy - not working but FQDN seems to resolve properly

FQDN Object in Policy - not working but FQDN seems to resolve properly

PA-VM in Azure - multiple Zones? (e.g. DMZ,Trust,Unstrust,etc)

Unlock your full community experience!

About TonyDeHart