HA swap and SSL VPN sessions

[Toshi_Esumi]

I thought SSL VPN sessions were synced so I could do the swap stealthy to recover the "Error"ed tokens after a swap over when the cluster was upgraded last night to 6.4.9. I was wrong and all SSL VPN customers are complaining about the drops. All active SSL VPNs seemed to have dropped.
Would you expect this, while all IPSec VPNs (I meant site-to-site. We don't have dialup IPsec VPNs) are kept up?

Toshi

[kcheng · Accepted solution]

Hi @Toshi_Esumi 

Generally, SSLVPN session failover is not supported. That said, the end-user will get disconnected and reconnect when the HA failover is triggered. When session sync is enabled, SSLVPN authentication and cookie failover are supported. You may refer to the following document for the respective:

https://docs.fortinet.com/document/fortigate/6.0.0/handbook/752215/terminated-sessions

[Toshi_Esumi]

Thanks Kayzie for pointing me to the handbook section.

Based on below a little bit cryptic explanation,

"Session failover is not supported for SSL VPN tunnels. However, authentication failover is supported for SSL VPN web mode sessions. This means that after a failover, SSL VPN web mode sessions can re-establish the SSL VPN session between the SSL VPN client and the FortiGate without having to authenticate again.

Authentication failover is not supported for FortiClient SSL VPN sessions."

Any tunnel mode SSL VPNs need to be reauthenticated and reestablished by clients. We don't use web mode so pretty much no failover.

It was ironic because we had to swap back HA pair to recover those customers who use SSL VPNs with FTMs from unable to activate tokens, which caused all those, more than 200 spread multiple VDOMs, on-going SSL VPN sessions to be dropped.

Toshi

[kcheng]

Hi @Toshi_Esumi 

Glad to hear that the handbook is helpful. Technically for all failover that I've performed, reconnection of SSLVPN would be required. In your case, I would think that it would be best to sort out the FTM error that you mentioned with our TAC. Making sure that it's registered to the primary unit would be worth checking.

[Toshi_Esumi]

It's a known issue, at least for us, when HA failover happens whatever the reason is, like our case an upgrade. If that happens, we have to swap back and remove those tokens and re-apply the license to recover those token. In my opinion that's a design issue for tokens with HA set ups. Because if the cause of the failover was a hardware issue or something that we can't recover right away, we wouldn't be able to swap HA back. Meanwhile nobody(no customers) on the FGT can activate new tokens that registered to the unit that's not running.

Toshi