Globalprotect: Multiple gateway on the same firewall

cancel
Showing results for 
Search instead for 
Did you mean: 

Globalprotect: Multiple gateway on the same firewall

L1 Bithead

Hello good people. 

 

We are planning globalprotect redundancy on our PA-3050 with multiple ISP. Here is our scenario:

 

1 Portal

1 Gateway

 

What we wanna do:

 

1 Portal 

2 Gateway

 

our existing gateway is going through tunnel mode via tunnel.1

what I want to know is that, can I run my second gateway via the same tunnel tunnel.1? or Do i need to create a new tunnel? 

 

thanks in advance guys!

6 REPLIES 6

Cyber Elite
Cyber Elite

Hi  @rabbyx7xafc ,

 

You shouldn't be able to use two differnt gateways associated with same tunnel interface.

Put it this way - if you imagine that tunnel.1 is just a simple IPsec tunnel (site to site), using two gateways is like building site to site with two different peers using same interface and routes. What I am trying to say is that firewall will not be able to determen which gateway should it use, because you will have two different IP pools associated with same interface.

What you could to is:
- Create two separate gateways each assosiated with different tunnel interface, different IP pool. You could use the same SSL certificate and configure, so your GP portal use one FQDN for GP gateway and have your DNS to resolve it with primary and backup IP. Or configure GP portal to send two gateways with different priority and let the gp client detect when there is issue with primary

- Assing the GP gateway and portal IP address to loopback IP. Configure BGP with both of your ISP and advertise it from both. Configure single GP portal and gateway using the loopback. Leave the failover to the BGP and the ISPs

L1 Bithead

okay got it! but here is my confusion. I don't see any option to use FQDN for setting up the GP portal! its only IPv4 or IPv6. As i'm seeking redundancy, how can I ensure that if my GP Portal is dependant on IP only, and if that ISP goes down, so does GP portal.

L1 Bithead

gp.PNG

as seen here, no option to choose FQDN

Hi @rabbyx7xafc ,

That is correct, and if you think about it make sense. When you selecting IP address for GP gateway portal, you are telling the firewall on what socket to listen for connections. You cannot configure network socket with FQDN, right.

 

Take one step back to how GP works:

1. When user (aka gp client) wants to connect he will make a connection to the portal first.

2. User puts FQDN in the GP client, it resolves to an IP and then it tries to connect to that IP

3. Once connected and authenticated to the portal gp client will download instructions/settings for  GP application behaviour and how to establish the VPN tunnel. This will include the GP gateway (the endpoint to which the gp client will try to establish vpn tunnel)

4. In here your should put the FQDN for your GP gateway.

Astardzhiev_0-1629709063928.png

 

GP client will get this FQDN and again resolve it to get the IP to which it should connect.

In most cases people tend to use same IP and FQDN for gateway and portal, but again depends on your setup.

 

Now back to your question - how to configure redundancy for your GlobalProtect. If you notice above, in order for your VPN to work you need to have redundency for both portal and gateway.

From what I understand you are using two different ISPs, so my suggestions would be:

1. Create two separate GP deployments (portal and gateway). Each one associated with public IP from each ISP. When creating your DNS entry you need to use DNS failover service, which will monitor status for both GPs and resolve the FQDN to the primary and if it is down to the secondary ISP ip address.

2. Get public IP range that is assigned to your. Run BGP with both ISP and advertise this range to both ISP. Configure some IP addresses  as loopback interfaces and use those for one portal and gateway. Configure your GP FQDN to resolve to this one. So the DNS will always resolve to same IP, but if your ISP one is down BGP will advetise your public range via ISP two.

2.

L1 Bithead

ok got it. can you make one thing clear? is this true that if the ISP im using for GP PORTAL goes down, it doesnt matter as long as the GP gateway behind that portal are up? i just read that GP PORTAL just initially sends the client info regarding how to connect to GW. after thaat, it wont matter that GP portal ip is up or not. is this correct?

Hey @rabbyx7xafc ,

If GP Gateway is UP, your currently connected users will continue to work normally, but most probably users will not be able to establish new connections.

 

I am saying "most probably" because by design gp client will cache the settings and when restarted it will first try to use the "last known" working settings and gateway and connect straight to the GP gateway (without any attempts to connect to GP portal). I am not 100% sure, but I believe this is only valid for Always-On VPN connection. With One-Demand (I believe) it will always try to connect to portal and only after successful connection it will try to connect to the GP gateways.

 

Don't forget also that, once user is connected to GP gateway it will periodically connect to GP portal to check if there is change in the application config. Not sure what was the default, but something like every 6-8 hours. I am not sure what will happen if user is connected to GP gateway and try to refresh portal config - I assume nothing, user should stay connected without issues but still good to have it in mind.

 

Are you planning to use the GP with Always-On or On-Demand mode?

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!