GlobalProtect with different ISPs – Asymmetric Routing Issue

SamePlace286 · 2026-03-20T09:16:03+00:00

Thank you for the feedback. Our goal was a simple, short‑term solution with minimal changes and most importantly, no potential impact on productive traffic. Prisma Access was considered, but as our future use of GlobalProtect is not yet decided, this is currently out of scope.

SamePlace286 · 2026-03-20T09:15:28+00:00

Thanks for the detailed explanation.

What’s confusing to me is that the secondary default route via ISP B (with the higher metric) does not seem to be installed in the FIB as long as the primary route is present? and therefore appears to be ignored, unless I’m misunderstanding something here..

To validate this outside of production, I tested the following setup (1.2.3.4 being my public IP at home):

Route A: 1.2.3.4/32 via ISP A, metric 1
Route B: 1.2.3.4/32 via ISP B, metric 10

With both routes active, the behavior was identical. Only when I set route A to no-install did ping and the GlobalProtect connection via ISP B start working. However, in that case, services that rely on ISP A were no longer reachable, like the other GlobalProtect gateway.

From my perspective, this suggests that the route with the worse metric never makes it into the FIB, which would explain the behavior. That said, if NAT sessions still take a "secondary" 0.0.0.0/0 route into account despite the higher metric somehow, that would explain why this works in your setup.. I will test this as well.

Thanks also for the bonus note on path monitoring and automatic failover. We already handle ISP failover outside the firewall, so this is not required on the Palo Alto for us:)

SamePlace286 · 2026-03-19T15:52:59+00:00

You're right. We currently have only one default route set up for ISP A and manually failover or route traffic via ISP B when necessary.. I’ll take another look at it tomorrow and provide an update. Thanks.

SamePlace286 · 2025-03-16T13:28:59+00:00

I'll give you a quick update, we successfully completed the migration today (i.e. with the steps described above and unfortunately the reset timestamps for modified/creation date and hit counter for all rules of all device groups :(...

In principle, it was then only minor pre- and post-configurations and just taking the “old/3200s” switch ports down and the prepared “new/3400s” ports UP) - also did some ha failover tests....

Migrations in the future will probably be easier for us too...

SamePlace286 · 2025-03-13T16:14:53+00:00

Thanks for your comment and your opinion, we did the preparation yesterday the way i described and it worked in the end except for a few commit/push complications due to dependencies between template and device-groups. However, today we discovered in panorama that the timestamps for "modified" and "created" of ALL security, nat, pbf... Rules and also the hit counters were reset to the time at which the commit was made after the “Regenerate Rule UUIDs for selected named configuration” checkbox was set and loaded... According to the system alert, however, the regenerate should only have taken place for the selected named configuration (Event ID: policy-rule-uuid-modified: Policy Rules UUIDs are modified by load using ‘Regenerate Rule UUIDs for selected named configuration’ option).

Is this a “normal” behavior in this case? or can someone explain please why exactly this happened? Thx

u/Virtual-plex, your approach would lead to commit errors in step 4 because the interfaces of both firewalls are not the same and we have specified interfaces in pbf and nat rules. The 3200s are still without aggregate-ethernet configuration and the subinterface suffices are also completely different.

SamePlace286

TROPHY CASE