VPN Global Protect Portal - two VR and one VR environments

[Metgatz]

VPN Global Protect Portal - two VR and one VR environments

Hello, good afternoon.

As always, thanks for the help, the support, your time and collaboration always.

I tell you I have the following case, which has me very restless, since I always try to understand what and why of what I implement and configure, I do not like to leave things that work by magic, since at the time of the tshoot It is important to know how they are armed.

Finally, let's get to the point:

I have already had to implement and/or support multiple platforms in Palo Alto, where in many cases it has been necessary to implement two ISPs and each one offers the obvious service of Internet access, but above all, access to each one of its Global Protect VPN Portal, which is the focus of this issue.

Well that is what I always do, I implement two Virtual Routers, one for each ISP, and one of them with their corresponding return routes to the other VR, from the networks that do not live in said VR, also for the issue of not dealing with implement ECMP for the issue of default routes. In other cases I also implement ECMP and at the request of the clients, I implement ECMP with a single virtual router and both links in the same virtual router.

Then normal and general environment:

Scenario/environments/Infra 1:

-Two VRs, each VR with its ISP, a Global Protect VPN Portal for each ISP, each VR with its corresponding default route (0.0.0.0/0) to its respective ISP, since each VR has its own independent and particular routing table . Its corresponding NAT and policies, all OK. Operating and running. 

Environments 2/Another environment:

-A single VR, with both ISPs connected to the same VR, ECMP enabled, each ISP connection with its corresponding VPN Portal. Their corresponding NAT and policies, all OK. Operating and running.

So far, all good, both scenarios all Ok, operating and working correctly.

Now I come across a firewall that has the following scenario:

- A single VR with both ISPs configured. No ECMP configuration enabled ( ECMP disabled ). Two ISPs with their corresponding Global Protect VPN Portal. Only one default route to the main Internet link and no other default route ( only one route 0.0.0.0/0 there is no other ). Here comes my big doubt and headache, I have tried to implement this scenario and without having the ECMP enabled, to use both links, it does not work. After enabling ECMP if possible due to the issue of routes and metrics. But in this firewall, which is the headache ( PA-3020 pan-os 9.1. ) without ECMP, without any other routing protocol operating, with only one default route (  0.0.0.0/0 only one to the main link ) to the main link... Both Global protect VPN Portals respond, work and operate perfectly... It's not that I don't want it to respond and work, it's more than good, super good... But I need to know the... what and why... I've gone round and round the config and nothing. Arming the same LAB with the same similar scenario does not work except with ECMP or using two virtual routers. 

Please, I would appreciate it if you could review and read the details of what was proposed and if you can help me and support me to clarify why the two portals are working, if logic and theory should indicate that they are not... but both portals work, with their respective Public IP and your portal-web-Gui access to download the vpn client and with the global protect client operating perfectly.Maybe there must be something I'm missing and/or not checking.

Thank you very much in advance for your great support, time and your kind collaboration.

I remain attentive, cordial greetings.

[Metgatz · Accepted solution]

Dear community:

Good afternoon, many thanks to the entire community for reading and/or commenting on this post.

After checking carefully, I found the problem, indeed, without the two VRs, without nat and without PBF it operates perfectly.

My problem was the following, I always apply Zone Protection by default in the firewalls, the issue is that in the secondary link zones, the zone protection in the "IP Drop" section was being blocked, by the option "Spoofed IP address", this is correct but ... for LAN zones, internal zones, here you can see in this link just mention it:

" For internal zones only, drop Spoofed IP address packets to ensure that on ingress, the source address matches the firewall routing table."

https://docs.paloaltonetworks.com/best-practices/9-1/dos-and-zone-protection-best-practices/dos-and-zone-protection-best-practices/deploy-dos-and-zone-protection-using-best-practices#:~:text=For%20internal%20internal%20zones%20only%2C%20drop%20Spoofed%20IP%20address%20packets%20to%20ensure%20that%20on%20inress%2C%20the%20source%20address%20matches%20the%20firewall%20routing%20table.  

So this I noticed because I removed the zone protection zone and the gateway responds without problems. So there I started to slowly remove and remove options (since not everything produces logs, some are silent drop and does not generate logs) until I found the one that was generating the problem that the web-gui portal of the secondary link did not respond and it was the only but only that option, after removing remove, test, etc. the responsible was "Spoofed IP address" and it makes all the sense in the world. Well I detail it in case it happens to someone else in this community.

Thank you very much, best regards.

[angonzalez]

I had a similar case with a client, they have two ISP, and one VR without ECMP, they have a GlobalProtect Portal on ISP1 and they wanted to access the portal by ISP2, what did works for us in this particular case was a no-nat rule.