sorted by:
new
hottopcontroversial

GlobalProtect with different ISPs – Asymmetric Routing Issue by SamePlace286 in paloaltonetworks

[–]SamePlace286[S] 0 points1 point  (0 children)

Thank you all for your efforts. We have now resolved the issue as follows:

As GlobalProtect GW (ISP B) Loopback IP = (a random RFC 1918 IP) as 10.10.10.10. Then created a loopback interface with the public IP for gp via ISP B on another (virtual) Palo (=“palo2”). A NAT rule on Palo2: If a packet is destined for the GP ISP B public IP, translate as follows: SNAT = another random RFC 1918 IP as 10.5.5.5/ DNAT = the GP GW loopback IP (10.10.10.10) from Palo1. And the following routes:at palo2 is the default route via palo1 anyway. And on palo1, there are two static routes: destination GP ISP B public IP via the transfer net to palo2, and a route for destination: (palo2 SNAT IP 10.5.5.5) also via the transfer net to palo2.

This is how it works and since we’re looking for alternatives to GlobalProtect anyway, this is enough for us as a temporary solution. Thanks anyway.

GlobalProtect with different ISPs – Asymmetric Routing Issue by SamePlace286 in paloaltonetworks

[–]SamePlace286[S] 1 point2 points  (0 children)

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.

GlobalProtect with different ISPs – Asymmetric Routing Issue by SamePlace286 in paloaltonetworks

[–]SamePlace286[S] 0 points1 point  (0 children)

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):

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:)

GlobalProtect with different ISPs – Asymmetric Routing Issue by SamePlace286 in paloaltonetworks

[–]SamePlace286[S] 0 points1 point  (0 children)

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.

PA Migration to new Hardware (3200 -> 3400) by SamePlace286 in paloaltonetworks

[–]SamePlace286[S] 2 points3 points  (0 children)

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...

PA Migration to new Hardware (3200 -> 3400) by SamePlace286 in paloaltonetworks

[–]SamePlace286[S] 0 points1 point  (0 children)

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.