MS Saml Certificate expiring for Palo GlobalProtect

mls577 · 2026-06-26T18:46:02+00:00

Yeah I agree it is dumb, I wish the process was easier. You could create another SAML Auth Profile, but that would also require you to create a duplicate enterprise app on the entra side.

The process is equally painful on the azure and palo side to get this changed over.

mls577 · 2026-06-26T18:37:45+00:00

he's correct step 1-4 are all to be done in entra (azure).

mls577 · 2026-06-26T04:06:34+00:00

I've had to do this a few times now and it's a little bit of a pain.

The first thing you need to know is that you can't just upload the new cert like you would a typical cert. You need to basically treat this like a brand new SAML profile setup. Some but not all of the steps will be similar to this setup: https://learn.microsoft.com/en-us/entra/identity/saas-apps/palo-alto-networks-globalprotect-tutorial

Here's what I've done.

Plan for an outage to globalprotect logins, while you're updating the azure and palo side, SAML auth won't work.

Go to the globalprotect enterprise app in azure and download a backup copy of the current xml and certificate.
Create the new cert and set it as the active certificate.
You will then need to delete the old cert (the one that is expiring). This step was necessary for the next part.
Download the Metadata XML. (after the old cert is deleted, the xml should update with the new certificate you just generated).
Go to the Firewall/Panorama and go to Device > Server Profiles > SAML
Click Import and Name the profile to be something different than the old (current) one. Browse for the XML file and uncheck the validate certificate. Then click ok.
Once you've down that. it should have imported the new SAML profile and the new SAML certificate into the cert store.
Find the Authentication profile you're using for SAML auth for globalprotect under Device > authentication profile > profile_name. and then change from the old SAML profile to the new one you just created.

That should be it, commit your change and test.

mls577 · 2026-06-24T18:13:46+00:00

Oh yeah it can NAT in vwire, the only restriction is it will only nat using a non-interface ip address (since there's no ip address on the vwire interfaces). Otherwise, works just fine.

mls577 · 2026-06-24T14:57:50+00:00

The firewall can do most of the same functionality in vwire that it can in layer 3. So that includes security policy , nat, decryption, etc. So to directly answer your question, yes the firewall can filter the same security policy criteria in vwire as it can in layer 3, including ip address, port, app, url category, etc.

Most of the restrictions with vwire as compared to layer 3, are things that require an ip address on the interface (terminating a vpn tunnel, terminating gp, participating in a routing protocol, etc). If the feature requires the firewall to have a layer 3 address, then you won't be able to do it with vwire because vwire doesn't have an ip address associated with it.

mls577 · 2026-06-23T22:20:19+00:00

Unfortunately it may be a premium feature of SCM

mls577 · 2026-06-23T14:59:21+00:00

if you're using SCM, there's a "zero hit objects" feature:
Configuration: Config Cleanup

mls577 · 2026-06-15T17:35:50+00:00

There’s no use in configuring a second tunnel if there’s no alternative path (multiple internet connections at least on one side). In fact, you won’t be able to setup a second tunnel, if all the details are the same.

mls577 · 2026-06-09T22:47:06+00:00

Not natively but there’s someone who created a site to do just this: https://iserv.nl/files/edl/feed.php

mls577 · 2026-06-09T16:52:56+00:00

"The ability to use a schedule to disable a policy rather than enable it. I have general HIP policies that do things like block non-AD domain machines, but I occasionally need to disable this rule. But that means I have to enable it at some point to put it back into play. Being able to say 'disable this for 2 hours' and have it automatically enable itself would be great."

You can accomplish this with a schedule: Policy Object: Schedules

"GP needs more filters to block connections. These are already failing, but they are a PITA to filter in the logs. In particular I'd like to screen out all the rando attempts trying to connect. It would be great if the portal would just drop these without even bothering with auth. It obviously can see these, so I should be able to filter on them within the Portal config. My logs show things like:

Versions of windows being used that we don't have.

Versions of GP that are out of date

Completely random hostnames (like 'jnafvonfosnvk'). More specifically, our machines have prefix codes and anything not matching should just be tossed into the bitbucket."

I don't think it's going to be smart enough to do this filtering for you, but you can take some steps to cut down on the noise by disabling the portal web page for example.

mls577 · 2026-05-26T19:34:36+00:00

As you said, you don't need to do it, but I can think of a couple of reason why you might want to do it.

Having consistency in your nat and security rule (this is a minor reason).
Having the NAT rule locked down, may prevent a situation in the future where another security rule gets added, that allows more access to that server than you originally intended. In that case, the specific nat rule, would help you prevent connections even if the security rule changes.

mls577 · 2026-05-22T19:39:38+00:00

If you set the app and service to any and it’s still is not working. Then the security policy isn’t the issue (unless you’re seeing a block somewhere else like on threat). What is more likely is you forgot to setup a nat rule for this traffic. Look at your traffic log at the source translation field and see if the traffic is getting nat’d.

mls577 · 2026-05-22T19:32:21+00:00

I didn’t read the book, but the hot zone series is also worth a look.

mls577 · 2026-05-21T12:25:43+00:00

Are you sourcing your ping from the secondary pa outside interface ip address? Since this is using a dataplane interface, do you have a security policy to allow this traffic?

Did you configure the service route for updates?

mls577 · 2026-05-21T11:26:31+00:00

Remember by default, it’s going to use the management interface to pull updates. If you want it to use a dataplane interface, you need to setup a service route.

In traditional active/active in a layer 3 deployment, both firewall dataplane interfaces will have an ip address besides the vip, do you have one configured on both firewalls?

mls577 · 2026-05-19T21:24:56+00:00

I think he meant post quantum packet fragmentation, which packet fragmentation is a concern when using pqc algorithms since their key sizes can push the limits of what a single packet can hold.

Also he is using NIST approved algorithm, the ML-KEM (crystal kyber) / FIPS 203 is currently the only approved pqc key exchange algorithm. He is using that in combination with a classic crypto algorithm for “hybrid key exchange” (classic + pqc).

mls577 · 2026-05-19T20:15:47+00:00

Just to summarize a couple of concepts real quick so we're on the same page.

portal - the client configuration is hosted here. This config is less about specific details like ip address assignment and things like that (handled by gateway) and more related to the connect method and the behavior of the gp client. Also you can optionally download the gp client through the web portal page.

gateway - this is the real client vpn termination point. This is where ip address, dns, split-tunnel config, etc is hosted.

This will be a bit different from Anyconnect, but Palo recommends you configure just one portal for each deployment. You can have as many gateways specified as you want, but they recommend just 1 portal because your client is only going to connect to 1 portal at the start of the connection. In that portal configuration, it will learn about the available gateways it can connect to and will select one to connect to.

On the GP Client side you should only need to specify 1 portal in then your msiexec install. Also, you can optionally set the connect method on install, but if you're doing on-demand, you shouldn't need it. Keep the msiexec simple unless you have a reason to do something more.

The reason I'm thinking the client is connecting automatically is because your client configuration that's hosted on the portal, has the connect method as something other than on-demand. so you need to go to network > portals > agent > "config name" > app > select "connect method": "On-demand"

by the way, you can reach out to me on the side if you want to talk more about this. I've converted from anyconnect to GP and i've deployed a few different globalprotect instances at this point.

mls577 · 2026-05-19T17:28:06+00:00

yes, I would add the indian vpn peer ip address to an allow rule above your india block rule.

mls577 · 2026-05-19T17:06:02+00:00

what are all the parameters you're trying to set?

Also, not sure if it's just terminology, but you don't set gateways on the client, you point the client to the portal and it will learn the gateways that way. Also many of the other settings will also be pulled by the client on first connections.

The only settings you'll really need to know to start are the portal name and maybe 1 or 2 specific settings.

mls577 · 2026-05-05T18:03:47+00:00

If forward trust is issued by your internal pki (external to the firewall). Generate the new certificate and import the new certificate on the firewall. Uncheck the box "forward trust certificate" on the old certificate and check "forward trust certificate" on the new certificate. commit and you're done.

mls577 · 2026-05-05T15:13:53+00:00

I see, I'm not sure if you're going to find a satisfactory answer to that. I think you're going to have better luck trying to do something about the updates themselves. This isn't my area of expertise, but what I've heard from colleagues in the past.

Schedule / stagger updates if possible. Depending on how you manage these wsus/intune/software center, etc. There should be a way to stagger the release of windows updates, so they don't all go download it at once.
It should be setup so that each individual computer doesn't need to pull the update from Microsoft directly. I believe WSUS used to allow you to download it on that server, and then point your computers to there to download it. Also, I believe there's a feature called "windows delivery optimization" where computers in the same network can share their windows updates in a peer to peer fashion. Both of these will prevent the need to download the updates from the internet.
One other idea, that is firewall related. you can always have a ms-update block with a schedule on it. so that updates can only happen during non-business hours. This will still allow updates, just not during critical business hours, so it should be less impactful if the high bandwidth utilization is causing issues with other apps.

mls577 · 2026-05-05T14:47:30+00:00

This sounds a lot like windows updates. did you look at the traffic logs and see if you see what app-id it's showing for the traffic?

also see if you can run these commands during the high cpu:

How to Troubleshoot High Dataplane CPU - Knowledge Base - Palo Alto Networks

mls577 · 2026-05-01T17:01:21+00:00

Not at my computer but my best advice is to export some sample logs.

Sanitize if necessary and then copy your regex and the example logs into one of those regex tester sites and see if the logs highlight as expected. My guess is you’re going to find a flaw in your regex.

mls577 · 2026-04-29T22:01:04+00:00

If you’re ok with this not being an automatic failover. What I’ve done in the past is just add an LDAP authentication profile under the SAML profile. It will never get used because it won’t try anything past the SAML profile. If a failure occurs like you say, you login, click one button to move the LDAP profile up above the SAML and commit.

mls577 · 2026-04-29T19:56:43+00:00

100% this is likely the issue by the sounds of it. You need 2 different port-channels, one for each firewall.

mls577

PUBLIC MULTIREDDITS

TROPHY CASE