GlobalProtect VPN - Multiple ISPs - Single Client IP Space Desired

[Jason_Sloan]

Currently I have GlobalProtect Gateways on each of my ISP links which requires dedicated IP space for the clients according to PA documentation that client space IP pools shouldn't overlap.

I've recently been asked to grow the remote access pool to a fairly significant number. This would require a second large chunk of addressing that would largely lay dormant, this is undesirable - especially if scaling out across multiple deployments.

I've seen some discussion about multiple VRs with and PBR that seemed to revolve around site to site VPN as well as some discussion around leveraging a private loopback address and some NAT policy across the two different ISPs to NAT. I think the latter discussion would be easier to implement from a change perspective on a functioning production environment and would like to explore this more. Not having a test environment makes this a bit trickier though.

My GP clients are configured for IPSEC.

They use IP addressing for the different gateways which are selectable in the configuration.

GW1 - 1.1.1.1/29   - Tun.1 Client IPs 10.0.0.0/16

GW2 - 2.2.2.2/29 - Tun.2 Client IPs 10.1.0.0/16

Under normal operation FW egresses ISP1 using default route unless it is down.

Converting to a Lo100 - 169.254.0.1/32 and binding a GW there w/ Tun.1 - 10.0.0.0/16

Adding NAT policy:

e1/1 - 1.1.1.1 (isp1) -> Lo100 - 169.254.0.1 (vpn)

e1/2 - 2.2.2.2 (isp2) -> Lo100 - 169.254.0.1 (vpn)

Lets assume appropriate policy to allow connectivity, etc is completed... operationally today my clients can select GW1 vs. GW2 if converting to a loopback / NAT configuration would that still be possible? If clients selected GW2 but ISP1 is up traffic would egress ISP1 and, I'm assuming, NAT to the GW1 IP address. While I'm sure the response traffic would arrive at the client, would it complete negotiation as GW2 or would users be unable to select that gateway with this configuration due to the response having GW1 IP? Would subsequent client traffic then target GW2 IP or the responding GW1 NAT? (Do i need to account for asynchronous traffic?)

Thank you!

[reaper]

You'll want to account for asymmetrical routing as the client would receive a reply from your 'other' ISP which breaks negotiation

I'd go with a pbf rule from the outside pointed inward, with symmetric return enabled on your ISP2. That way all inbound on isp1 will egress isp1, and ingress on isp2 will be caught by pbf and egressed out of isp2 (symmetric return next hop would be isp2 default route)

[Jason_Sloan]

Seems simple enough. I'll give it a go (maybe tonight?), thanks so much for the reply - I'll post back with results.

[Jason_Sloan]

Ok, I did all of this and it didn't work. But I may have stumbled upon a working config (unfortunately this took about 6 hours of trial and error in an afterhours change window), although I'm not sure I understand why it is working. On the loopback, in the non-working config only the IP I was doing the NAT to was present (169.254.0.1).  However, when I added the IP addresses the clients use for connectivity (let's say 1.1.1.3 & 2.2.2.3), even though those addresses are translated via rule to 169.254.0.1 it started working. To verify I removed the addresses again from the loopback interface and verified it will not work without them. It appears to be working with them, but unfortunately the second ISP is down so i can't test.

Update: Second ISP connectivity restored - Secondary IP works fine as well. I'll take it.