We've been using OpenVPN and Viscosity successfully at our office for quite a while. We recently deployed a new OpenVPN 2.5.2 server at a remote location. This is an Access Server, not the Community Edition, in case that's relevant.

While things are largely working, we're seeing that connections that run for an extended period (like overnight) always eventually terminate with an "Authentication Failed" dialog. Once this happens, the failure seems to "stick". Attempts to reconnect fail until we cancel out and disable the connection. When the connection is reenabled, it works again. Until somewhere around 24 hours where the same problem happens again.

This problem isn't isolated to one person or location. Everyone who has a long lived overnight connection sees this failure. This includes people who are offsite as well as in the office, so with at least three different ISPs involved it seems unlikely to be Internet connectivity related. Most of us are using the latest shipping version of Viscosity.

After searching this forum it sounds like this issue might be resolved in a recent beta of Viscosity. But I tried Viscosity 1.7.10b2 (1452) and it doesn't resolve the problem.

One other fact that might be related is that we're running our 2.5.2 OpenVPN server in high availability mode. When we were testing this configuration, we killed one server and let the other one take over. When we did this, we saw the same kind of "Authentication Failed" behavior. Namely the failure was sticky until we disable and reenable the connection.

When we ran into this we figured failover was such a rare problem that it wasn't worth reporting. But now we're seeing what appears to be the same behavior on a daily basis without the server failing over, it seems like this is a bug that is worth understanding.

I'm not saying that something related to the high availability configuration is causing the problem. I'm suggesting that that is one reliable way of reproducing what seems to be the same client side failure. Perhaps it would be easier to debug than waiting 24-ish hours. Or at the very least, maybe there's some similarity between the cases that might help with an "ah-ha" moment that explains the problem.

In case the client side logs are helpful, I've included them here (scrubbing our IP addresses):

What you're running into is related to session tokens. OpenVPN-AS automatically generates a session token when a user successfully connects: this allows a user to avoid needing to re-enter their credentials (or re-authenticate using two-factor) for short disconnects, dropouts, sleeps, etc

After being connected for a long time (I believe OpenVPN AS's default is 24 hours) the session token will eventually expire (for security reasons) and so if a dropout occurs, or a regular TLS session re-key, the cached session token will be rejected by the server. The client should then attempt to re-authenticate as normal.

Viscosity has always handled session tokens correctly, and so normally this wouldn't be an issue. However unfortunately direct client session token support was recently added to OpenVPN itself, which doesn't work correctly. When the expired session token is rejected, instead of trying again with the proper credentials, it'll just keep trying the session token forever. I believe a fix is coming in the next OpenVPN update, however in the meantime you have a couple of options:

1. Have Viscosity handle the session token, which will handle it correctly. The trick to this is to let Viscosity handle reconnects rather than OpenVPN. To do this, make sure the "Automatically reconnect if disconnected" option is ticked under the General tab when editing the connection, and then add the command "remap-usr1 SIGTERM" (without quotes) to the advanced commands area:https://www.sparklabs.com/support/kb/ar ... -commands/

We've gone ahead and patched OpenVPN to disable its inbuilt session token support in the latest beta version of Viscosity. This should resolve the issue you're having with expired session tokens, as Viscosity itself will handle them. Please give it a try and let us know if you run into any issues.https://www.sparklabs.com/support/kb/ar ... -versions/