[SOLVED] Correct config for robust automatic reconnect?

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

henris

Posts: 3
Joined: Mon May 12, 2014 4:25 am

Post by henris » Mon May 12, 2014 5:31 am
I've been a Viscosity user for about a year now and I've been mostly happy with the product. I'm using the latest Viscosity version running on Windows 8.1 and my VPN provider is IPredator. Bandwidth and ping wise I have a very good connection to their site since I'm living fairly close to them.

But lately I've been experiencing disconnects and inability to automatically reconnect. I've read through the threads with similar problems and fully understand that the cause of the disconnects themselves is most likely either with the provider or somewhere else along the route and not in Viscosity.

My problem is more on the reconnecting which seems quite unstable for some reason and this all on Viscosity's side to my understanding. To debug the situation I started to look at the Viscosity log and also attached connected/connecting/disconnected scripts. Once I realised I had to add "remap-usr1 SIGTERM" command to get the disconnected script triggered I started to see some problems in the way Viscosity behaved or at least I couldn't understand why it behaved the way it did. As examples of unexpected behaviour I could see Viscosity trying to reconnect once and if it failed it just gave up and was stuck in disconnected state or it would get an authentication failed (for unknown reason) on reconnect and then the next attempt brought up the user name / password dialog. In either case the end result is no vpn connection running.

I'm using the settings from the IPredator configuration guide with the addition of the "remap-usr1 SIGTERM". I'm also currently experimenting with disabled "Persist Tun" setting as suggested in a recent post.

Few questions:
1. Which settings (general or connection specific) control the reconnection process?
2. How does the "remap-usr1 SIGTERM" and disabled "Persist Tun" affect each other? Should I see automatic reconnection at all with these two settings?
3. Is there a configuration for automatic reconnect which would not give up?
4. Is there any way to avoid the username name / password dialog from appearing when connection attempt failed due to authentication failure? I know it's there for not getting the account locked but for some reason authentication fails even though the username and password are correct.

Any assistance is well appreciated. I have quite a few log snippets available so just tell what do you need to see.
Last edited by henris on Fri May 16, 2014 11:46 pm, edited 1 time in total.

Eric

User avatar
Posts: 1146
Joined: Sun Jan 03, 2010 3:27 am

Post by Eric » Mon May 12, 2014 2:37 pm
Hi henris,
Which settings (general or connection specific) control the reconnection process?
The persist settings in the Options tab are the only settings that will really effect a reconnection. It is important to note though, even disabling these, iPredator might be pushing them to your client anyway, which means disabling them has no effect.
2. How does the "remap-usr1 SIGTERM" and disabled "Persist Tun" affect each other? Should I see automatic reconnection at all with these two settings?
remap-usr1 SIGTERM will prevent a reconnection occurring at all. This tells OpenVPN in the event of a dropout, disconnect, do not attempt to reconnect.
3. Is there a configuration for automatic reconnect which would not give up?
Yes, the default one. Remove remap-usr1 SIGTERM and your connection will attempt to reconnect forever. The problem is, if your VPN Provider is pushing new options with persist-tun, or the server is rejecting the reconnection attempt, attempting to reconnect forever will never work, you need to disconnect, allow everything to be reset, and then reconnect.
4. Is there any way to avoid the username name / password dialog from appearing when connection attempt failed due to authentication failure? I know it's there for not getting the account locked but for some reason authentication fails even though the username and password are correct.
This is actually an issue at your VPN Providers end. Some Providers only allow a user to have one simultaneous connection. Sometimes, their records are not very quick to refresh, so if you have a dropout and then reconnect, their end still thinks you are logged in, so they will reject your login. If you wait a few seconds, their records will refresh and your login details will not be rejected by the server.

Even though Viscosity asks for your username/password again, it should be pre-filled with your saved credentials so you can just hit enter, is this happening correctly?

You will need to speak to your VPN Provider about these drop outs. They will be able to find a solution for you so the drop outs don't even occur, which we think is the ideal way to prevent these issues even being issues :).

Let us know if you have further questions.

Regards,

Eric
Eric Thorpe
Viscosity Developer

Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs

henris

Posts: 3
Joined: Mon May 12, 2014 4:25 am

Post by henris » Tue May 13, 2014 2:37 am
Thank you for the answers! Few comments below.
Eric wrote:
henris wrote:
3. Is there a configuration for automatic reconnect which would not give up?
Yes, the default one. Remove remap-usr1 SIGTERM and your connection will attempt to reconnect forever. The problem is, if your VPN Provider is pushing new options with persist-tun, or the server is rejecting the reconnection attempt, attempting to reconnect forever will never work, you need to disconnect, allow everything to be reset, and then reconnect.
I had it like that (Persist tunnel and no "remap-usr1 SIGTERM") originally and for some reason it did not try reconnect forever but instead gave up after few tries and wound up in disconnected state. Since I have a workaround (see below) I will propably not revert settings to test it further.
Eric wrote:
henris wrote:
4. Is there any way to avoid the username name / password dialog from appearing when connection attempt failed due to authentication failure? I know it's there for not getting the account locked but for some reason authentication fails even though the username and password are correct.
This is actually an issue at your VPN Providers end. Some Providers only allow a user to have one simultaneous connection. Sometimes, their records are not very quick to refresh, so if you have a dropout and then reconnect, their end still thinks you are logged in, so they will reject your login. If you wait a few seconds, their records will refresh and your login details will not be rejected by the server.

Even though Viscosity asks for your username/password again, it should be pre-filled with your saved credentials so you can just hit enter, is this happening correctly?
That's a good catch, it is definitely related to the single simultaneous connection. And yes, I'm seeing the pre-filled dialog as supposed to.
Eric wrote:
You will need to speak to your VPN Provider about these drop outs. They will be able to find a solution for you so the drop outs don't even occur, which we think is the ideal way to prevent these issues even being issues :).
They had a big hw crash a few days ago and I think the previous weeks were showing some signs of that. The connection is still very flaky especially at night time. But I've been experimenting with an "external" reconnect script which is attached to the disconnect script setting in Viscosity.
Code: Select all
echo %date% %time% Disconnected >> c:\utils\viscosity.log
echo Waiting for 120 seconds >> c:\utils\viscosity.log
call c:\utils\utils\sleep.cmd 120
echo Trying to re-connect using command line >> c:\utils\viscosity.log
"C:\Program Files\Viscosity\Viscosity.exe" connect "IPredator" >> c:\utils\viscosity.log 
Combined to disabled tunnel persistence and "remap-usr1 SIGTERM" this has been working nicely for the last 24h. I added a hefty 120 second delay to avoid authentication failures and to give the server side time to recover. Sometimes it takes 30-40 minutes before the connection is re-established but in my use case it does not matter. Eventually I will look at a different provider if the problems do not go away. But this will suffice for now.

Thanks again for your fast and precise response!

henris

Posts: 3
Joined: Mon May 12, 2014 4:25 am

Post by henris » Fri May 16, 2014 11:42 pm
Just a small update. The external reconnect script has been working perfectly. At the same time the amount of disconnects and time to reconnect has reduced significantly so it seems things on the IPredator side have stabilised. This issue can be considered solved on my part. Thanks again for your support!
4 posts Page 1 of 1