OTP Issues with several users

Just curious whether you came to a resolution on this issue? We've recently begun seeing the same issue at a site. Random users starting to see OTP auth failures. Resetting their token and getting user to re-add to MS authenticator solves the issue right away. If you check the time offset for the affected user, it returns an odd and unlikely time offset of some -796 seconds, although their mobile device and the firewall have matching date/time.

Did this issue ever make it to a published KIL?

They plan to fix it in next MR… Re-creating OTP is the only workaround.

I can confirm that we see it earlier as well. But we got a massive issue after updating to 20.0.2. Are you running a cluster of firewalls? One hint of the support was to do a manual sync of the auxiliary device before doing an update or reboot. Another suggestion is to use a backup of the firewall from the time before the update.

Yes, we have cluster.
Would be cool if Sophos simply fix the bug ;-)

does it happen when the cluster Primary Node changes?

i do not know, but yes I think so. We saw the issue earlier but only for single users, so we could not see a relation to a cluster failover or an update of the firewall. But the last time we updated the firewall, many users reported that they could not login to VPN because the OTP was broken.

and did you notice the Primary node has changed after the upgrade? e.g. when you have no preferred Primary node.

There is also an issue with heartbeat - computers powered on but no longer sending heartbeat are stored as bad computers in the database but of the primary node only. They do not sync it. I wonder if this is the case here too.

The primayry node did not change, because we have a preferred primary. But during the update, the first primary will sync with the previous auxiliary after the reboot. And if the auxiliary is not in sync with some tables, then you get the problems.

We will open a KIL soon. 

To summarize the issue: 
It has no relationship to an Firmware Update. 
Instead the issue is caused by the HA Cluster and the TakeOver. 
In certain situations, the OTP Token can be corrupt. Which means, it is valid on the current primary, but invalid on the AUX. If you perform a TakeOver to the AUX, it will be the corrupt Token in place and it will not work anymore for this particular user. 

We will fix the issue in V20.0 MR3 or V21.0 MR1 to NOT corrupt the token anymore, but we cant repair the tokens per se, if you already did a takeover.

What you can do to fix this issue before doing a takeover or a firmware update: 
The option "Sync Auxiliary Device" will repair the HA Cluster. 

Use this option to reboot the HA AUX Appliance (No downtime required) and it will repair the sync. 

Thanks for technical info and confirmation of the bug.

What is causing the corruption?

Is there a chance that some MFA on the aux node even corrupt in the short time between the sync and the HA-takeover?