Continuous retry causing password lock-out

Got a problem with Viscosity or need help? Ask here!


User avatar
Posts: 1
Joined: Fri Aug 05, 2022 3:21 am

Post by jms1 » Fri Aug 05, 2022 4:03 am
At work we're using Viscosity (we have a 70-seat license) to access a corporate VPN which uses some kind of Azure VPN "server", with the user authentication tied to the corporate "Azure AD". The "Azure AD" requires everybody to reset their passwords every 90 days, and _without fail_, after each user resets their password, the first time they try to use Viscosity to connect, their account ends up being locked for "excessive login attempts". The front-line support guys are able to do password resets, but they don't know anything about Viscosity (they're on the corpoprate side, but this VPN is limited to R&D people - they manage the user accounts and passwords but we manage the VPN "server" itself.)

I don't normally have to deal with this, I have a hardware device on my desk which maintains its own VPN connection to the R&D network and just connect my workstation to that.

Turns out I had to reset my own password earlier today, after having to help a user with this. Out of curiosity, I wanted to see if maybe the problem was with the user rather than with the VPN, so after changing my password I grabbed a laptop and tried to connect to the R&D VPN using Viscosity, using the same process we tell other users without the hardware VPN devices to do.
  • When Viscosity tried to connect, it failed - but rather than telling the user there was a problem, Viscosity just tried over and over. The log doesn't show any kind of "authentication failed" message, it just showed that the remote end just plain hung up without responding each time.
  • NOTHING in the app told me that there was any problem, until after about 45 seconds, when it occurred to me that it doesn't usually take this long, and that's when happened to notice it flipping between "Connecting" and "Authenticating" over and over again on the menu bar pull-down menu.
  • From what I can tell, Viscosity had been trying over and over, 2-3 times per second, for a little over a minute. The corporate AD locked my account after ten attempts.
_After_ calling corporate IT to unlock my account, I had to manually go into "Keychain Access", _identify_ which pair of keychain items correspond to the connection I'm having trouble with (nobody knows the numbers, users only see the names), delete the "username" and "password" items for that item, try to connect again, and then Viscosity prompted me for a new username and password.

  • If a connection attempt gets "hung up on", DON'T KEEP TRYING OVER AND OVER ... at least not without asking the user first. Maybe this can be configurable as well - some connections may not lock their account out for multiple retries, so doing this may not cause problems, I don't know ... but if it doesn't connect, the user should be notified.
  • In the Viscosity "Preferences" window's list of connections, add a way to change or "forget" a connection's username or password. This could be as simple as a "forget password" item on the right-click menu, or a button in the connection's Properties dialog's "Authentication" tab, or whatever - but forcing users to dig into "Keychain Access" because they need to update a stored password is ridiculous.
  • As an alternative, give the users a way to EASILY correlate the VPN connection profiles in the app, against the "connection numbers" used in the Keychain entries. This could be as simple as adding an "ID" column to the list of connections, adding something like "(8)" at the end of each connection's name, or adding a label with the number on the connection's Properties page "General" tab.
But PLEASE do SOMETHING ... having to walk users through finding and deleting Keychain entries is getting really really old.


User avatar
Posts: 2320
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Sat Aug 06, 2022 7:08 pm
Hi jms1,

It sounds highly likely the OpenVPN server is misconfigured in this instance.

What it should be doing is sending an AUTH_FAILED message upon it rejecting the username and password. This will trigger Viscosity to re-prompt the user for updated credentials and prevent further reconnection attempts. A user will be able to enter their updated password (and optionally save it) and reconnect.

Sending an AUTH_FAILED message is the default behaviour by OpenVPN when rejecting an incoming connection using an authentication script or via the management interface using "client-deny" (even if it's being rejected for a different reason). So, it's highly unusual for connections to simply be getting killed. It sounds likely the authentication setup on the OpenVPN server is misconfigured, leading to connections being essentially just dropped server-side.

I recommend reaching out to the administrator of the OpenVPN server: it should be trivially easy to fix, and it'll resolve the issue for all users. I would also recommend enabling the "auth-gen-token" option on the OpenVPN server, so the server uses session tokens for established VPN connections (so a user's established VPN session is not affected when their credentials change). You can specify a maximum lifetime for session tokens if needed.

If you have no control over the OpenVPN server and can't get its behaviour fixed, then you have several options to approach the reconnect behaviour. There are two reconnection mechanisms: Viscosity's reconnect behaviour, and OpenVPN's behaviour.

If you have the checkbox Automatically reconnect if disconnected ticked in Viscosity's connection editor for the connection, then Viscosity will automatically attempt to reconnect the VPN connection if it becomes disconnected (besides when manually disconnecting it). Viscosity will automatically scale these reconnection attempts so the scenario you’re seeing can't occur. It'll first try reconnecting immediately, and if that fails it'll wait an increasing amount of time between attempts (for example 5 seconds, then 10, then 30, then 60, etc. up to 10 minutes). It also respects the connect-retry-max command, so it also won't attempt to reconnect more times than set in this command. Because of this it shouldn't pose a problem for your setup, but you can turn it off via the "Automatically reconnect if disconnected" checkbox if desired.

The other form of reconnect behaviour is OpenVPN itself. For brief network dropouts, rather than mark the whole connection as disconnected (at which point Viscosity's reconnect logic will kick in) it'll try to seamlessly re-establish the connection without fully tearing down the VPN connection. This is essentially what you want for small dropouts (e.g. Wi-Fi dropping for a second) so everything keeps working. As it sounds likely the OpenVPN server you are connecting to is just killing the VPN session, OpenVPN is likely treating this as a network dropout and attempting to re-establish the link itself.

Considering the above, there are a few approaches you can take:

1. Disable OpenVPN's reconnect logic and just rely on Viscosity's logic. You can do this by adding the command "remap-usr1 SIGTERM" (without the quotes) as an advanced command to your connection. You can also optionally add the "connect-retry-max" command to limit the number of reconnection attempts as well.

2. Limit OpenVPN's reconnection attempts. You can do this by using the connect-retry and connect-retry-max advanced commands. For some dropout types OpenVPN may not respect these options (as it doesn't consider it a "reconnect").

3. Disable reconnect behaviour altogether by adding the command "remap-usr1 SIGTERM" (without the quotes) and also unchecking the "Automatically reconnect if disconnected" option.

Finally, if you're still stuck it's possible something else may be going on. In which case please send us the details requested here and we'll take a closer look for you.

2 posts Page 1 of 1