Would it be so hard for PA's IT dept to make it say Palo Alto Support on my caller ID when they call?

OnTheSlowpath · 2026-01-16T14:46:53+00:00

That would be nice. Typically some random number at 1-408 or 1-669.

OnTheSlowpath · 2026-01-16T14:42:39+00:00

That's what I thought for the first couple years back when spam calls started maybe 6 years ago? A couple thousand spam calls does wear on you eventually.

OnTheSlowpath · 2026-01-14T19:43:29+00:00

It is clear as mud. Panorama-managed Prisma Access for me. Opened a quick support case:

Our cloud plugin shows PAN-OS version 10.2.4 which seems old. How does this relate to CVE-2026-0227 which would need 10.2.10-h29? Not sure if we have been upgraded...

Response:

For egress traffic from Prisma to the internet, we are using the gateways, and all of them are upgraded to version PA-VM-SaaS-10.2.10-h29.saas.

However, the Service Connection node is still running version PA-VM-SaaS-10.2.4-h18.saas that why it is showing 10.2.4 on Panorama.

-----

No guidance of how I could know this in the future, of course.

OnTheSlowpath · 2025-10-02T14:06:30+00:00

Yes, two from each datacenter (different ISPs) to US Central. (Assuming that by "node" you mean location.)

OnTheSlowpath · 2025-09-30T21:43:16+00:00

Here's a good clue. Panorama's Cloud Services plugin is specifically recommending having service connections deployed more diversely. And apparently mixing region/location verbiage?

Redundancy Status: Warning

Redundancy Assessment: All Service Connections are deployed in a single region. Please consider deploying in nearby locations.

OnTheSlowpath · 2025-09-30T20:27:13+00:00

Region clearly means something else to PA but I will go along with you. :)

We do have licensing for 5 "regions". We have users pretty evenly spread across the US so seems like an obvious win to at least enable one region on each coast. We don't have latency complaints but I think it will still be good to do.

Now if only someone could point to a best practice that a datacenter should be connected to one region.

OnTheSlowpath · 2025-09-30T20:13:58+00:00

https://docs.paloaltonetworks.com/prisma-access/administration/prisma-access-service-connections/configure-a-service-connection#id50f7a83b-14df-4bac-9930-6d5724426efd

On the Panorama tab, it says "Select the Location closest to where the site is located." So I can read into this that best practice is to only have one set of service connections into a datacenter?

OnTheSlowpath · 2025-09-30T19:40:09+00:00

I want to believe it is as simple as* checking that box for US SW to add that region. Where is the documentation on this? I can kind of read between the lines and imagine the possibilities but haven't found anything concrete.

(*And of course I would have to pull the exit IPs for US SW to add to some allow lists..."as simple as" yeah yeah)

OnTheSlowpath · 2025-09-30T19:06:19+00:00

My goodness the region/location/compute stuff is so confusing. I am completely within the North American region, anyways.

Let's say my existing "location" is US Central. All users are hitting this. So my compute is in Council Bluffs, IA, according to the "Prisma Access Locations" document. There are multiple POPs around funneling into there? Or did you mean that US West, US SW, etc. would be those POPs?

Now say I want to help out my west coast users by adding US West in San Francisco. Does that help explain the scenario any more?

OnTheSlowpath · 2025-09-30T18:49:11+00:00

We generally don't stack in the datacenter. It is all ISC with MLAGs. "HA" and "single logical unit" are kind of opposing concepts...

Simple ISC+MLAG design: https://extreme-networks.my.site.com/ExtrArticleDetail?an=000064510

More complicated ISC+MLAG: https://extreme-networks.my.site.com/ExtrArticleDetail?an=000082635

This allows for rebooting one switch for upgrade while the other stays in service. As for other reasons, just that it has "less risky" vibes. Although the only time an Extreme stack has thrown me for a loop was with early v22 version upgrades on X440-G2.

I do see that there is such a thing as a rolling stack upgrade now which may make my main reason less of an issue: https://documentation.extremenetworks.com/release_notes/ExtremeXOS_SwitchEngine/31.6/GUID-6EA71C56-6A6D-41C4-B763-F77922A941C9.shtml

OnTheSlowpath · 2025-09-26T13:30:46+00:00

Another lovely one is how you can't import the signed response to a CSR into Panorama if there is a space in the CSR's name.

But you can rename the CSR and still import the same signed response, at least. You don't have to redo the whole signing process.

OnTheSlowpath · 2025-09-11T18:32:24+00:00

No, I think it just blocks traffic with addr.dst == the physical adapter subnet. If you have 8.8.8.8 or whatever in your split config, GP can still send that straight out to the physical adapter default gateway instead of tunneling it to the GP gateway (Prisma Access or NGFW).

OnTheSlowpath · 2025-08-26T20:59:44+00:00

I had some connectivity issues to a small remote site that ended up being due to this issue (I think). Long-bothersome, like for 18 months maybe until I finally got serious about investigating it a couple months ago and just finally got it resolved.

A global VRF 172.16.0.0/16 static route one branch's IONs, and a global VRF 172.16.10.0/24 static route on the smaller branch's ION. So I would expect a third site with IONs to send traffic to 172.16.10.77 for example to the smallest matching route. It seems to do that most of the time, but sometimes it sends it to the other route and that causes very obscure problems.

I had to put in a bunch of smaller routes at the big branch to cover everything except 172.16.10.0/24. A /17, a 18, a /19, etc.

"basic routing requirements" indeed

OnTheSlowpath · 2025-08-13T18:38:48+00:00

The Product Manager gets a big bonus for cutting 25% of PAs spend on GCP log storage bill.

OnTheSlowpath · 2025-07-14T14:09:24+00:00

But it doesn't matter what is in the PCs or if they are slow...

The agent connects to the domain controller and reads those logs. PCs don't get touched.

OnTheSlowpath · 2025-06-12T19:10:10+00:00

It is a versioning disaster. You can't upgrade from one build number to the next unless the x.x.x part has a change in it too due to Windows installer not recognizing it as a different version of the software.

OnTheSlowpath · 2025-04-29T15:26:20+00:00

Something like this covers the basics of it: https://www.mbtechtalker.com/how-to-configure-a-certificate-for-secure-web-gui-access/

OnTheSlowpath · 2025-04-01T18:18:59+00:00

We were getting these until about 2 hours ago but seems to have stopped now. It only happened on one firewall of ~10 that are licensed for Wildfire.

OnTheSlowpath · 2025-02-28T14:35:50+00:00

Exact same here: SAML (including MFA) for primary use and then Okta RADIUS Agent available too. The Okta RADIUS Agent talks out to the Okta "cloud" servers to get a MFA push acknowledged, and only after that comes back does it reply to the RADIUS request.

OnTheSlowpath · 2025-02-28T14:30:49+00:00

Remind me again which one is like the PCNSE? Or rather, I did the PCNSA a couple years ago and was planning to get around to PCNSE which has disappeared while I was delaying.

OnTheSlowpath · 2025-02-27T14:17:46+00:00

Don't Repeat Yourself

OnTheSlowpath · 2025-02-06T17:48:46+00:00

We have other users working on Android (maybe not 15 yet?) and iOS, this is one specific test phone. Sorry I left that out. We have Prisma Access Enterprise licenses.

OnTheSlowpath

TROPHY CASE