VPN remote access behavior during jumbo hotfix install

[the_rock]

Hey guys,

Not sure if this is the right board to post this in, but just wanted to see if someone could share some insight into it. I could be wrong when I say this, but Im pretty sure that when failing over a cluster or when one member reboots, that people connected to VPN via remote access should not have any interruptions...well, this is not what I experienced at all when installing latest jumbo hotfix 118 in customers environment.

These are 6000 appliances I believe running R80.40 and I uploaded latest jumbo on backup member, it installed and I saw it started to reboot and that is when I lost my RA vpn connection and when trying to reconnect, it kept saying that I could not get office mode due to license issue (??!!). That does not make any sense, since no license had been changed at all in the last 8 months. Since I had access on external interface, I was able to confirm that backup member came back, at which point I logged into external interface of current active fw, installed jumbo and rebooted.

Even after 10 mins, I could still not connect to vpn, as it kept complaining about same thing in regards to not being able to assign office mode because gateway did not have license, though I saw that fw2 (original backup) came back as master, which was expected, so that clearly shows clustering is working. Literally as I was about to call Account services to confirm the license, vpn was able to reconnect (this took about 20 mins all together at least).

Now, confusing part to me, why would remote access vpn go down during this activity? I had seen many customers do this without any issues at all...I will throw this into the mix, though not sure if it matters...their clustering shows ccp in unicast mode, but I personally dont think that should matter, as VIP would always be tied to whatever member is active.

Any thoughts? I ask because I dont them to go through this experience next time...

Thanks a lot in advance.

[PhoneBoy]

That sounds like a license issue.
I assume both members have the same license level, right? (i.e. compare cplic print on both members)

Where you might lose VPN connectivity during failover is if the client is connecting in Visitor Mode.

[the_rock]

Hey phoneboy...yes, cplic print is exactly the same and as I mentioned, license had not changed in 8 months. Now, I find it interesting for visitor mode you mentioned, because I did this for 3 other customers where visitor mode is enabled on gateway on port 443 and never a problem during failover. Are you saying this could be something on the client side?

[PhoneBoy]

It’s not being enabled that’s the issue, it’s the client actually using it (versus regular IPSec mode).
This may be a setting on the client (don’t recall offhand) but the client will also try it if IPSec doesn’t work for some reason.
Since Visitor Mode terminates on the gateway itself, that connection wouldn’t be synced on failover.
I believe the client will try to reconnect, though, and you shouldn’t be seeing a license issue in the process.

[the_rock]

Yea...thats what confused me. I agree with your assessment about visitor mode, but license error definitely makes no sense to me.

[the_rock]

Also, I thought about the visitor mode a bit more and correct me if Im wrong, but isnt the whole point of having a cluster for things like this, where if one member goes down, customer can rely on connections failing over? I get that visitor mode terminates on the gateway, but does that technically mean even if any member is processing traffic it still would not work for RA vpn client??

[PhoneBoy]

Connections that ultimately terminate on the gateway never survive a failover.
While that will definitely affect the HTTPS tunnel, it may not impact connections going through that (which do get synced).
That said, in R81, we moved visitor mode from userspace to CPAS, which might survive failover (not 100% sure on that).