SparkLabs Forum.

Community Help.

Programmatically control Viscosity, unattended

I need to use, from a Windows 7 Prof computer, a VPN provider that provides OpenVPN services. I also need to be able to start/stop "random" OpenVPN connections under programmatic control, unattended. My usage scenario is approximately: I have a long-running app on the computer, from time to time this app gets messages from a queue, and based on those messages it needs to start a specific OpenVPN connection and do some additional work.

I looked briefly at the OpenVPN client app, and while it works decently well in GUI mode, it seems unnecessarily baroque for my use above: once started from the commandline it doesn't "return" but stays running until stopped; all further communication with that running connection is done by telnet-ing into a "management" server; the batch file running all this needs to run as administrator, gets a UAC dialog, etc. That last one, UAC dialog, is a showstopper because I haven't figured a reasonable way to make that run unattended.

So I'm very hopeful for Viscosity billing itself as a scriptable OpenVPN client.

Finally, questions, please:

1) would Viscosity be usable in the unattended scripting scenario mentioned above?

2) I saw the ViscosityCC commands at the following link; are there other commands? Is there a user manual, perhaps? ... g-windows/

3) it seems admin privileges are required on Windows for the way openvpn works -- it rewrites routing tables, and on Windows that requires elevated perms. How does Viscosity get around this?

Thank you
Hi tek,

ViscosityCC and Viscosity's scripting in general is quite simple. There should be enough for basic control of connections there though, if you're looking for something specific, you're welcome to make a feature suggestion and we can investigate if there is enough interest from the wider community. Viscosity requires a user desktop to function correctly, so will not run headless. As long as a user is logged in on, Viscosity can be used with scripting.

Viscosity uses a System Service for elevated commands.

Viscosity has a built in 30 day free trial, I encourage you to try Viscosity to see if it meets your needs.

Eric, thanx. I did download Viscosity trial as you suggested, and already like enough of what I see that you should soon get some of my money very soon.

What I like are:

-- straightforward install sets up Viscosity for non-admin non-UAC usage
-- light-feeling GUI
-- capable command line for workable scripting (but read on)

What I don't like are:

-- this business of importing or creating all ovpn configs I think I will use. That works for a few dozen; not for 1k-2k (yes, possible 2k different servers). Is there a mechanism whereby I could pass the config to use to ViscosityCC? And a mechanism to pass in the user/pwd as well? (Again, unattended is more important than secure; the machine it will be running on is secure enough) With several hundred configs imported Viscosity ui hung so unresponsively that viscocitycc was timing out, and I ended up rebooting the machine.

-- related, needing to set up each imported config with user/pwd is inconvenient at best. Is there a way to indicate a global user/pwd to use per group of configs, or similar?

Do you have any suggestion re the above 2 items?

Thank you
Hi tek,

Thanks for the feedback, we do appreciate it!

Viscosity was simply never designed for thousands of connections. I'm afraid it's not something we'll handle in the near future, but will consider down the line.

For sharing credentials, please see the following - ... nnections/

Viscosity will also try and import an auth up file into it's credential storage if one is present when importing the connection - ... -user-pass

You can import a connection using:

Code: Select all

"C:\Program Files\Viscosity\Viscosity.exe" "C:\Path\To\config"

However the only way to remove one without the UI would be to remove the configuration at %appdata%\Viscosity\OpenVPN and then restart Viscosity.


Thanx for the insight. I skimmed the articles re providing user creds ... and both methods should be workable for my purposes: the former -- setting creds per "folder" -- would seem easier, except the latter -- pointing to an up-file during connection import -- is likely more useful in my case.

Why more useful? Because I cannot get away from need to connect to any one of several hundred servers. These connections are serial, i.e. one at a time, not simultaneous, so I wish Viscosity/CC could simply "use" a connection-config file "pointed to" via a commandline arg, make the connection, forget about the file, rather than hold it in memory or some such for ever and anon! I suppose a workaround would be, in script:

-- import a connection, alongwith up-file
-- use viscositycc to start/stop connection
-- after every ~ 50 config imports, "purge" viscosity, go back to step one

I wish these contortions were unnecessary. Is there another approach you could suggest?
Hi tek,

This is probably the best process we can offer.

Got it. Thank you for the corroboration.
Eric, my Viscosity-related experiments continue:

-- I see that ViscosityCC numbers connections 1..n in the order they were imported; is there a way to get names/numbers of currently-connected connections?

-- re your earlier note about providing to Viscosity an up-file during connection import ( ... y-commands), it seems this is accomplished by specifying "#viscosity auth-user-pass path-to-file" in the "Extra OpenVPN configuration commands..." textarea of the GUI when creating (importing?) a connection via the UI, correct? ( ... -user-pass). More important, is there a a commandline method of importing a connection and specifying an up-file, as well?

-- does ViscosityCC provide a way to purge connections en masse from Viscosity? Does Viscosity itself take a commandline argument that does, perhaps?

Please advise, thx!
Hi tek,

Please refer to the getstate command in our scripting KB, you would need to loop known connections, there is no way to get a list of connections by state, only state by connection.

Please refer to my previous replies for your other two questions.

Eric wrote:

Viscosity will also try and import an auth up file into it's credential storage if one is present when importing the connection - ... -user-pass


However the only way to remove [a connection] without the UI would be to remove the configuration at %appdata%\Viscosity\OpenVPN and then restart Viscosity.


Thanx for the input. I did see getstate, need to futz around some more w/ Viscosity connection import (I suspect it's a GUI-only thing but will find out), and had overlooked the "restart Viscosity" in your earlier response.

What I'm coming to for myself is that I don't want to jump through the hoops of connection counting/purging/re-importing/whatever. That's just too much hassle, and better I spend that time going the openvpn route and writing, say, a telnet-wrapper to manage the fiddliness of its manager interface.

Thing is, given the "advanced pass-through" commands that Viscosity accepts perhaps it itself is a wrapper to the openvpn client? If so let me tell you -- you've done a wonderful job of creating a simple and robust interface, and I balk at reinventing the wheel.

In fact my biggest takeaway since I re-started Viscosity-related experiments yesterday is what a pleasure it is to use: the scripting interface has adequate commands; the commands themselves are simple, direct, and useful; the implementation is robust.

My current thought is to increase RAM on the computer, perhaps allocate Viscosity extra memory or some such, just so I can continue using it as-is.

That said, I would *love* for Viscosity not to use this naive, unnecessarily-limiting, hold-everything-in-memory approach.

Is Viscosity a .NET wrapper or similar around the openvpn client? Is any version of Viscosity opensource? If so I could probably mod it to read connection-info as needed from disk or similar, and contribute the edits back, of course.

Hhh, so close, I tell you -- so close :-)
12 posts Page 1 of 2

Copyright © 2016 SparkLabs Pty Ltd. All Rights Reserved. Privacy Policy