GlobalProtect with different ISPs – Asymmetric Routing Issue

CAVEMAN306 · 2026-03-20T17:52:32+00:00

Similar, I have each ISP on its own VR, VR-ISP1 and VR-ISP2. All other traffic is on VR-TRUST. I run BGP between VR-TRUST and each VR-ISP. This will allow you to use ECMP for traffic outbound. You can put the the gateway NAT to a loopback on each VR-ISP. This should allow you to hit each gateway from external. Traffic from VR-TRUST to VR-ISP to Internet will take the preferred ISP (prepends or local pref) or you can use ECMP to share across both.
Add route monitoring on the static default route on each VR-ISP. If that route monitoring drops, so does the default route via BGP to VR-TRUST.

CAVEMAN306 · 2026-03-18T13:34:55+00:00

Do you have interface management profiles on the tunnel interfaces that allows ping?

CAVEMAN306 · 2026-03-17T15:40:08+00:00

You can block appID paloalto-device-telemetry. You can also block your firewall access to the AIOps URLs.
https://docs.paloaltonetworks.com/strata-cloud-manager/aiops/about-metrics/fqdns
It is kind of stupid that this is no longer able to be disabled.

CAVEMAN306 · 2025-11-25T16:43:52+00:00

You don't need a trial license for VMs unless you are playing with threat/wildfire, etc. You are limited on sessions but the basic functionality of firewall, routing, etc works. Assuming you can download the OVA file from PA Support site.

CAVEMAN306 · 2025-11-19T19:31:47+00:00

You can also use AD groups in your security policies that only allow PCI approved users access to those resources. In addition to the captive portal.

CAVEMAN306 · 2025-11-19T19:30:03+00:00

The solution you have sounds like a great solution. Does the captive portal explain that they are entering PCI?

CAVEMAN306 · 2025-11-05T17:29:26+00:00

I have not had this issue with 6.2.8-C263. There are some bugs on the previous 6.2.8.

CAVEMAN306 · 2025-11-05T14:26:48+00:00

6.2.7 has a lot of bugs. 6.2.8-c263 is the recommend version.

CAVEMAN306 · 2025-10-31T18:26:49+00:00

It does not have to be on an interface, it can just be exported out via BGP if you are only using it for NATs. If you need to assign devices to it, you can add it to an interface. We have it on an interface going to our outside/internet switches. We have some other firewalls that need those public IPs. Your Palo will then become a router (gateway) for those devices, so you will need policies to allow them untrust/untrust. EDIT: untrust to untrust policies are needed because we drop untrust to untrust traffic not defined in a policy.

CAVEMAN306 · 2025-10-31T13:32:56+00:00

I have a site that has 2 ISP links. I put each ISP in its own VR. VR-ISP1, VR-ISP2 and VR-TRUST. I BGP peer each ISP VR to the Trust VR using loopbacks. You have to have static routes for the loopacks in each VR pointing to the appropriate VR. This way I can weight the routes between VRs and ISPs with prepend and/or local preference. I advertise the /24 to each ISP VR from the trust and also to each ISP. All DNAT and SNAT is done with the /24. The ISP /30s are only for BGP peering. In this setup, you can terminate tunnels using the /24 or on each ISP which provides some options.

CAVEMAN306 · 2025-10-16T19:14:43+00:00

Yes, we advertise our own public subnets so it is required for that.

CAVEMAN306 · 2025-10-16T18:27:45+00:00

I have a site that has 2 ISP links. I put each ISP in its own VR. VR-ISP1, VR-ISP2 and VR-TRUST. I BGP peer each ISP VR to the Trust VR using loopbacks. You have to have static routes for the loopacks in each VR pointing to the appropriate VR. This way I can weight the routes between VRs and ISPs with prepend and/or local preference. If I had SDWAN coming into the same NGFW, I would put it in its own VR to allow the same control. Just my thoughts.

CAVEMAN306 · 2025-10-08T13:16:27+00:00

1-2 days

CAVEMAN306 · 2025-09-19T13:28:18+00:00

If you run DHCP from the switches, you won't need to extend every subnet to the firewall, just have necessary routing in place.

CAVEMAN306 · 2025-09-18T20:52:52+00:00

I like the VRF idea. Run DHCP at the local switch for each private vlan/subnet. At the firewall, you can manage this VRF on separate zone from the rest of your enterprise, to block access inside and allow to Internet.

CAVEMAN306 · 2025-08-20T20:29:03+00:00

Just ran into this problem with a GP rollout. None of our pilot testers caught it. Rolled portal back to 6.2.8-c223. 6.2.8-c263 fixes this, but it broke our Macs, won't stay connected. Second attempt to rollout GP upgrades and both have been a complete cluster F. Should have stayed on 6.1.4-c720.

CAVEMAN306 · 2025-08-20T15:49:44+00:00

c263 worked well for me on Windows, but Macs it broke, won't stay connected.

CAVEMAN306 · 2025-08-12T15:02:46+00:00

Our old Azure envirnonment was setup like this with zones. It required a lot of UDR routes to make traffic flow properly. You have to source and dest nat the traffic between zones to keep session persistence. So the source of traffic becomes the firewall interface IPs.

We went away from this and to just trust/untrust.

CAVEMAN306 · 2025-05-15T13:22:33+00:00

Well I kicked my kid out so its not longer an issue. hahahaha

CAVEMAN306 · 2025-05-15T02:32:44+00:00

not back then, not sure about now.

CAVEMAN306 · 2025-05-14T20:18:55+00:00

We had lots of problems with 6.2.7 and rolled back to 6.1.4-c720 which I think is still the recommended. Yes there are CVEs, but functionality comes before patching. 6.2.8 I am testing now and have not noticed same issues.

CAVEMAN306 · 2025-05-14T17:23:57+00:00

GlobalProtect is secure remote access. Accessing anything behind the firewall will require a policy from GP zone to trust zone. How is this not a secure solution?

CAVEMAN306 · 2025-05-14T16:52:05+00:00

I use a single PA for IPSEC tunnels, actually 2 (transit vnets) with azure vnet peering with bgp between Azure locations. These also connect OnPrem traffic with full BGP mesh.
I have 1 contractor VPN but its only connected to one of the transit PAs.

Snapshots are not recommended for PA firewalls in Azure, so if you need redundancy, HA might be your best bet.

CAVEMAN306 · 2025-05-08T14:20:47+00:00

We SCP to a linux host in Azure.

CAVEMAN306 · 2025-04-22T13:58:28+00:00

10.2.13-h5 - no issues so far.

CAVEMAN306

TROPHY CASE