global protect multiple portal issue

[NIRAVK9]

We want to configure Portal level redundancy in Global protect .If we bind 2 IPs of 2 different location firewalls to our portal address then how does clinent interpret the DNS resolution .after how much time client will try on another system 

[bmorris1]

Hi @NIRAVK9,

You would need a script to automatically modify the DNS record if the 1st site was to go down. You can poll the firewall to see if it is up/interface up using SNMP. 

Though you can set the portal cookie to stay for a week on clients so they only need to connect to the portal once every 5-7 days, this is usually enough time to get the portal up and running again if it goes down (RMA/case with ISP etc.).

Alternatively you could look at GP in the cloud?

https://www.paloaltonetworks.com/products/innovations/globalprotect-cloud-service

hope this helps,

Ben

[Mick_Ball]

@bmorris1. Hi..

Though you can set the portal cookie to stay for a week on clients so they only need to connect to the portal once every 5-7 days

is this in the GP App config,

[NIRAVK9]

@bmorris1thankyou for the response. Whwre can i find the cookie setting? 

if i map 2 IPs to portal address,then whether GP client will try to both Ips one by one ??

[bmorris1]

@Mick_Ball

Yes it is in the GP app config, in the GP portal

@NIRAVK9 I'm not sure on this one as I have never done it myself as I've never needed portal redundancy due the above cookie authentication.

A solution may be to allow users to change the portal address and use different portals but the same gateways. GP should connect to the gateway that responds first.

[Mick_Ball]

if DNS resolves to 2 ip addresses your globalprotect client will only recieve 1.

if the portal connection fails then nothing else will happen.

if you reconnect GP then it may get the same address or it may get the second address. it's pretty random and probably not a good idea to use this for redundancy.

this is known as DNS "round robin"

i would still like to know also about the cookie setting.  where is it...

[Mick_Ball]

sorry @bmorris1, just posted after you...

[NIRAVK9]

BUt isn't this cookie only for authnetication prupose.?

or the cookie also saves the gateways sent to client  during previous connect to portal?

[Mick_Ball]

cookie authentication.,,,,,,,

i dont think "cookie auth" answers your question but if you use GP with portal auth only that generates a cookie for the gateway auth then you will need to extend this for when your portal fails.

i don't think the cached portal ever expires. i only say this because i cannot see any info/help/advice.

somebody else can jump in if they can advise further.

[NIRAVK9]

Thankyou @bmorris1 .

Just to make my question more clearer

What i am looking for is  that when my primary portal fails/goes down  then 

1) whether client still try to get the gateway from its cache and connect to one of the gateway which was given to it when it last conencted to portal 

2) whether thwere is any way at DNS provider end that i can change the IP mapped to portal address to my secondary location address

[Mick_Ball]

@NIRAVK9.

1) whether client still try to get the gateway from its cache and connect to one of the gateway which was given to it when it last conencted to portal 

Yes.

2) whether thwere is any way at DNS provider end that i can change the IP mapped to portal address to my secondary location address

yes. we have access tou our DNS records and can change them any time. this will depend on your provider. you may have to call/log a call with them.

please note that it will not be an immediate change. DNS replication is quite fast these days but it could take up to 24 hours to fully replicate across www.

[NIRAVK9]

1) so for first is there ant way i can see where is this cache stored in users machine and how long it will be there?

[Mick_Ball]

i have no idea, i doubt you will be able to see it.

[Mick_Ball]

in you host file within windows you could try to add your portal to a non existent address. try to connect GP and check to see what it says in the logs.

i've only ever seen "using cached portal" but there may be other info...