Skip to content
In the meantime, I figured I'd try reinstalling Viscosity and when I tried connecting, got a more verbose log regarding something OpenVPN doesn't like, which is odd, because it had been working.
Disconnected VPN Session Not Killing Network
Got a problem with Viscosity or need help? Ask here!
First post, hopefully something easy that I'm missing here.
Was using the 0.0.0.0 routing trick over a session specified to go completely through Viscosity. The apparent "dead route" VPN disconnect trick was my go to method for my intended purpose and simplicity sake. Well today that happened, and everything I expected to work, didn't.
I can browse the web just fine and use the network as if I wasn't on VPN at all, and strangely cannot connect back into any of my VPN providers profiles (PIA).
Running on Win8.1 x64, FWIW. Any ideas on what's going on?
Was using the 0.0.0.0 routing trick over a session specified to go completely through Viscosity. The apparent "dead route" VPN disconnect trick was my go to method for my intended purpose and simplicity sake. Well today that happened, and everything I expected to work, didn't.
I can browse the web just fine and use the network as if I wasn't on VPN at all, and strangely cannot connect back into any of my VPN providers profiles (PIA).
Running on Win8.1 x64, FWIW. Any ideas on what's going on?
Hi petepete,
I'm afraid this article needs to be updated and we haven't made it to it yet. The routing method rarely works on newer versions of Windows. The reason for this is while Unix can only have one default route, thus this method will overwrite it, Windows doesn't have a default route persay, so this method does not overwrite your main adapters default route, it simply adds another one. My apologies for the confusion.
We recommend you use the scripting method instead on Windows - http://www.sparklabs.com/support/preven ... fic_leaks/
This will terminate your network adapter on a disconnect and is the only real proven method. We also highly recommend that you test any method you implement.
In regards to the error you are receiving below, it looks like you have a file lock. You will need to restart your PC to release this.
Regards,
Eric
I'm afraid this article needs to be updated and we haven't made it to it yet. The routing method rarely works on newer versions of Windows. The reason for this is while Unix can only have one default route, thus this method will overwrite it, Windows doesn't have a default route persay, so this method does not overwrite your main adapters default route, it simply adds another one. My apologies for the confusion.
We recommend you use the scripting method instead on Windows - http://www.sparklabs.com/support/preven ... fic_leaks/
This will terminate your network adapter on a disconnect and is the only real proven method. We also highly recommend that you test any method you implement.
In regards to the error you are receiving below, it looks like you have a file lock. You will need to restart your PC to release this.
Regards,
Eric
Eric Thorpe
Viscosity Developer
Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs
Viscosity Developer
Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs
Thanks for the clarification, Eric. I follow you on the routing complexities between *nix and Windows. Can Viscosity handle Powershell .ps1 scripts as connect/disconnect options, or am I going to have to wrap/call it from within a batch file?
Unfortunately, restarting still results in the following error.
Unfortunately, restarting still results in the following error.
Code: Select all
Is there something on Viscosity's install dir folder ACL I need to check? If all else fails, I could simply reinstall and see how that goes.Jan 18 07:39:08: State changed to Disconnected
Jan 18 07:40:08: State changed to Connecting
Jan 18 07:40:08: 1.5.3 (1300)
Jan 18 07:40:08: Running on Microsoft Windows 8.1 Pro
Jan 18 07:40:09: Bringing up interface...
Jan 18 07:40:14: Checking reachability status of connection...
Jan 18 07:40:14: Connection is reachable. Starting connection attempt.
Jan 18 07:40:15: Unable to set permissions on secure folder. This access control list is not in canonical form and therefore cannot be modified.
The OpenVPN subsystem could not be started. Please check the following:
- Check for any error messages above this notification.
- Ensure ViscosityService is running.
- Make sure the configuration is valid if this is a Custom Gateway.
Jan 18 07:40:16: State changed to Disconnected
Hi petepete,
Viscosity won't run powershell scripts but it is something we could look at implementing. At the moment only Batch and VBS are supported.
My apologies, I did not see the complete error before, the forum has cut off part of the image for me. The folder Viscosity uses to write configs to is C:\Program Files\Common Files\Viscosity. I haven't seen this error before. Check this folder and folders under it have security set correctly. If you right click each folder, go to Properties, then go to the Security tab and then Edit, you should be greeted with an option to Re-order the permissions. If not, simply try deleting the folder at C:\Program Files\Common Files\Viscosity and connecting again.
Let us know how you go. We'll look at seeing if we can have Viscosity repair this automatically.
Regards,
Eric
Viscosity won't run powershell scripts but it is something we could look at implementing. At the moment only Batch and VBS are supported.
My apologies, I did not see the complete error before, the forum has cut off part of the image for me. The folder Viscosity uses to write configs to is C:\Program Files\Common Files\Viscosity. I haven't seen this error before. Check this folder and folders under it have security set correctly. If you right click each folder, go to Properties, then go to the Security tab and then Edit, you should be greeted with an option to Re-order the permissions. If not, simply try deleting the folder at C:\Program Files\Common Files\Viscosity and connecting again.
Let us know how you go. We'll look at seeing if we can have Viscosity repair this automatically.
Regards,
Eric
Eric Thorpe
Viscosity Developer
Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs
Viscosity Developer
Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs
Eric wrote:Hi petepete,Getting native posh support added would be great
Viscosity won't run powershell scripts but it is something we could look at implementing. At the moment only Batch and VBS are supported.
My apologies, I did not see the complete error before, the forum has cut off part of the image for me. The folder Viscosity uses to write configs to is C:\Program Files\Common Files\Viscosity. I haven't seen this error before. Check this folder and folders under it have security set correctly. If you right click each folder, go to Properties, then go to the Security tab and then Edit, you should be greeted with an option to Re-order the permissions. If not, simply try deleting the folder at C:\Program Files\Common Files\Viscosity and connecting again.
Let us know how you go. We'll look at seeing if we can have Viscosity repair this automatically.
Regards,
Eric
In the meantime, I figured I'd try reinstalling Viscosity and when I tried connecting, got a more verbose log regarding something OpenVPN doesn't like, which is odd, because it had been working.
Code: Select all
In the meantime, I'll check the ACE's on that directory and make sure they look in good form.Jan 18 07:54:14: State changed to Connecting
Jan 18 07:54:15: 1.5.3 (1300)
Jan 18 07:54:15: Running on Microsoft Windows 8.1 Pro
Jan 18 07:54:16: No associated network adapter was found, creating one. This process may take up to a minute or two.
Jan 18 07:54:16: State changed to Creating...
Jan 18 07:54:26: Network adapter created. Proceeding with connection attempt
Jan 18 07:54:26: State changed to Connecting
Jan 18 07:54:26: Bringing up interface...Jan 18 07:54:33: Checking reachability status of connection...
Jan 18 07:55:14: Connection is reachable. Starting connection attempt.
Jan 18 07:55:30: OpenVPN 2.3.6 Windows-MSVC [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Dec 2 2014
Jan 18 07:55:30: library versions: OpenSSL 1.0.1j 15 Oct 2014, LZO 2.06
The OpenVPN subsystem could not be started. Please check the following:
- Check for any error messages above this notification.
- Ensure ViscosityService is running.
- Make sure the configuration is valid if this is a Custom Gateway.
Jan 18 07:55:30: State changed to Disconnected
Hi petepete,
That's even more strange. Viscosity was unable to communicate with the running OpenVPN process. The first thing to check is that there are no stuck openvpn.exe processes in task manager. If there are, terminate them and try again. Also worth making sure no firewall or AV software are blocking local ports.
Regards,
Eric
That's even more strange. Viscosity was unable to communicate with the running OpenVPN process. The first thing to check is that there are no stuck openvpn.exe processes in task manager. If there are, terminate them and try again. Also worth making sure no firewall or AV software are blocking local ports.
Regards,
Eric
Eric Thorpe
Viscosity Developer
Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs
Viscosity Developer
Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs
I did have an OpenVPN Daemon process running, but idle, and I suspect that was there from my last failed connect attempt. Anyway, I killed it and tried connecting again through Viscosity using a fresh opvn configuration file.
I was prompted for credentials, but then immediately beyond that I was booted. Contacted my VPN provider and they insisted I use their inhouse application which installed a TAP Win32 v9 driver but could never actually use their app since it said it needed to be "reinstalled" non-stop.
At any rate, shortly after that, my connection began working. I don't know if their V9 TAP driver fixed something, or what, but I'll keep an eye on it.
Thanks again for the quick contact, Eric.
I was prompted for credentials, but then immediately beyond that I was booted. Contacted my VPN provider and they insisted I use their inhouse application which installed a TAP Win32 v9 driver but could never actually use their app since it said it needed to be "reinstalled" non-stop.
At any rate, shortly after that, my connection began working. I don't know if their V9 TAP driver fixed something, or what, but I'll keep an eye on it.
Thanks again for the quick contact, Eric.
7 posts
Page 1 of 1