Enh Req: UI takeover of existing tunnel, option to leave up when UI exits

[GoogleCodeExporter]

I'd like to deploy a system where I want the VPN tunnel to come up (if it
can) as soon as OS X boots.  When a user logs in, I'd like Tunnelblick to
see the existing VPN and allow the user to disconnect/reconnect/view
log/conf files.

Of less importance would be a user option to leave a tunnel up when the UI
exits, where each config could be set to 1) exit, 2) stay connected, or 3)
prompt user for choice.  Right now (3.0b22 build 1246), obviously, when
TunnelBlick is closed, the connection is closed too.

If you're familiar with the Windows OpenVPN GUI, this would be similar to
running it in Service mode, where the GUI starts and stops the OpenVPN
service instead of launching the OpenVPN client directly.

I looked at the command-line openvpnstart utility, but either I don't
understand how to use it to connect to the UI, or it doesn't work as I
expected.  The CL kill parameter took down a connection started by the UI,
but starting one via CL did not change the UI state, and the UI does not
see existing CL-started connections when it starts.

Original issue reported on code.google.com by petiep...@gmail.com on 4 Nov 2009 at 6:40

[GoogleCodeExporter]

Why? I'm not trying to be snarky, but what are you trying to accomplish?

Are you trying to set up an OpenVPN _server_ that allows clients to connect? 
For that, I can see why you'd want the 
VPN to come up with the computer and stay up all the time, through logins and 
logouts. But if it's a server, why 
would you ever want the tunnel to close just because a user logged out?

If you are talking about a client, there isn't much benefit from having the 
tunnel open when there is nobody logged 
in. Setting Tunnelblick to launch on login and to connect a tunnel on launch is 
easy, and it shouldn't take more than 
a few seconds for the launch and connection. 

Tunnelblick is designed such that the GUI controls OpenVPN. You can use 
openvpnstart to do just that: start 
OpenVPN. But that doesn't connect it to the GUI. And it can kill OpenVPN 
processes, too, of course, as you have 
seen.

Tunnelblick could be easily modified (I think) to leave OpenVPN running when 
Tunnelblick itself exists, but since 
OpenVPN would still be a child process of the logged-in user, I think OpenVPN 
would be killed when the user logs 
out.

I think it would be a lot of work to have Tunnelblick do what you want.

Original comment by jkbull...@gmail.com on 5 Nov 2009 at 1:44

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I've got a few systems that will be used by executives.  You know, 5th-grade 
level
users.  They forget things, like, oh, their passwords.

I'd like the Macs to bring up the VPN as soon as they come online so that I can
manage them, diagnose issues, reset passwords, etc.

Also, the Macs are in a closed user group with access to a patching/update 
system
that's only available when they're VPN'd in.  Periodic updates are easier for 
them to
comply with if its 1 step: turn it on, as opposed to, 1) turn it on, 2) login, 
and 3)
lock the screen.  Yes, they're really this spoiled.

This system worked well using Service mode in the Windows OpenvPVN GUI, but for 
other
reasons, we're switching to an all-Mac solution.

I could use openvpnstart in an rc-type launch script to kick it off on boot-up, 
and
then TunnelBlick would restart the tunnel when the user logs in.  Its a little 
messy
with back-to-back connections, but should work.  As for leaving a session going 
when
the user logs off, its not strictly necessary for my implementation, but feels 
like
it would make the feature complete.

As for openvpn being killed when the user logs out, are you sure?  I see the 
parent
pid for the openvpn process as 1 (launchd), even when launched by TunnelBlick.  
Iow,
it's fully deamonized.  Guess that's easy enough to test: start with 
openvpnstart,
and logoff...

Original comment by petiep...@gmail.com on 5 Nov 2009 at 2:10

[GoogleCodeExporter]

> I've got a few systems that will be used by executives.  You know, 5th-grade 
level
users.  They forget things, like, oh, their passwords.

Maybe I missed this but....

Why do they need the Tunnelblick GUI then? Just setup openvpn as a service to 
run 
through launchd.

Original comment by batman...@gmail.com on 5 Nov 2009 at 7:17

[GoogleCodeExporter]

"As for openvpn being killed when the user logs out, are you sure?  I see the 
parent
pid for the openvpn process as 1 (launchd), even when launched by TunnelBlick.  
Iow,
it's fully deamonized.  Guess that's easy enough to test: start with 
openvpnstart,
and logoff..."

When Tunnelblick is terminated (by quitting, it, for example, or if the user 
logs off), it kills all OpenVPN processes that are 
running. It even kills OpenVPN processes that it didn't start. Since it does 
this as root, it will kill _all_ OpenVPN processes. (It 
does this by killing all processes with the name "openvpn".)

But if you aren't running Tunnelblick (starting OpenVPN via openvpnstart or 
otherwise), then the processes are not killed 
because Tunnelblick never terminates.

I'm leaving this Issue open because it would be nice if Tunnelblick could be 
used to interface with "daemon" instances of 
OpenVPN that were started before a user logs in.

Original comment by jkbull...@gmail.com on 21 Nov 2009 at 4:03

[GoogleCodeExporter]

http://openvpn.net/index.php/open-source/documentation/miscellaneous/79-manageme
nt-interface.html
describes the management interface, and from what I read there, it looks like 
you
could leave the vpn client running by issuing the 'exit' command.  If a client 
is
started up outside of Tunnelblick with the -management flag (but without
-management-hold), it seems it should be possible for Tunnelblick to attach to 
it,
query status, and control it.

There would have to be some way to tell Tunnelblick about the existing 
connection,
however.  I don't think it would be wise for Tunnelblick to try to establish 
control
over all existing clients it sees running on the system, just as I don't 
necessarily
agree with it killing all clients when exiting.

Perhaps TunnelBlick could look at the commandline parameters of existing 
clients and
try to attach to any clients using the config files it finds for the user.  If 
all
users should be able to control the client, it could be setup in deploy mode.  
If
only a single user should have control, the startup (launchd) script can 
specify the
config file in that user's directory.  If Tunnelblick should not be able to 
control a
client, it can be launched using a config file which Tunnelblick would not ever 
use
itself.

In the same theme, perhaps Tunnelblick can remember which client was already
connected when it was launched, and use that as a flag to know not to shut that
client down when exiting.  It could indicate that by adding a " (persistent)" 
flag at
the end of the config tab title on the Details dialog.  That seems easier and 
less
confusing than adding another checkbox...

Some caveats: multi-users, multi-vpns, no management port, alternative port 
number,
connecting to a client in hold state, more?

I'd like to try some of this out myself, time permitting, but I don't know how 
much
time my hectic life will permit in the near future.

A question (which I could answer myself if I looked through the code, but will 
ask
anwyway as it shouldn't take long for you to answer): I notice when I click the
Disconnect button, there are no log entries showing the client shutting down
(restoring/deleting routes/dns, etc.).  Does Tunnelblick sent a SIGTERM to the 
client
pid, or send a "signal SIGTERM" command via the management channel, or something
else?  If the first or third, has the second been tried?  Is there some way to 
get
the shutdown log entries through the management connection?  Ok, more than one
question there; sorry.  Maybe that should be broken off into a separate bug/enh
discussion.

@batmanppc, I want to be able to talk them through stopping/starting the VPN 
via the
phone.  Plus I want to give them a visual indication of the tunnel's status
(disconnected/attempting conn/connected).

Original comment by petiep...@gmail.com on 2 Dec 2009 at 5:58

[GoogleCodeExporter]

Thanks for all the info and your thoughts.

A quick answer to the question about log entries not appearing after 
disconnecting: I noticed the same thing 
myself, and fixed it in r272. The problem was that Tunnelblick was killing the 
OpenVPN process (which is OK 
and works even if the management connection has somehow failed, which is why we 
do it that way) and then 
immediately terminating the management connection. Now it waits for the 
management connection to get an 
entry indicating the connection is closed, thus displaying the route 
restoration, etc., before the management 
connection is terminated.  (The log entries all come through the management 
connection.) I hope this answers 
your question.

Original comment by jkbull...@gmail.com on 2 Dec 2009 at 6:19

[GoogleCodeExporter]

Yes, that answers my question, thanks.

And you're welcome.  Hope it helps.

Original comment by petiep...@gmail.com on 2 Dec 2009 at 8:04

[GoogleCodeExporter]

Tunnelblick 3.1beta06 implements this enhancement, using the "Automatically 
connect...when computer starts" checkbox and button.

Original comment by jkbull...@gmail.com on 8 Jun 2010 at 12:55

• Changed state: Fixed

[GoogleCodeExporter]

Although the status is "fixed", I don't understand what has been fixed? Right 
now, about two years after the last comment on this ticket, I have a similar 
issue with Tunneblick.

My use case is, that managing OpenVPN configuration is fine and I don't want to 
use command line tools and configuration files to startup tunnels manually. 
But: When I started a download from a VPN source, then I want it to complete in 
the background even when I lock the screen. Downloads can take hours and I 
don't want to leave my screen unlocked if I'm away. As soon as I use the "lock" 
command in Mac OS X, the tunnel is disconnected. I can't actually tell if 
Tunnelblick is closed by OS X at this moment or is kept in the background.

How can keep the vpn tunnel open while I locked the screen? I don't mean the 
sleep mode.

Original comment by martenle...@googlemail.com on 17 Jul 2012 at 12:05

[GoogleCodeExporter]

Different issue, my friend.  This is expected behavior with Fast User Switching 
enabled (default setting in Lion, possibly earlier).

To disable, open up the VPN Details... dialog from the drop down menu, select 
your VPN in the Configurations tab, view the settings, and click the 
Advanced... button.  That will pull up another dialog allowing you to uncheck 
options for "Disconnect when user switches out" and "Reconnect when user 
switches in."

Original comment by petiep...@gmail.com on 18 Jul 2012 at 6:12

[GoogleCodeExporter]

Thanks, I guess I had never found that options on my own!

Original comment by martenle...@googlemail.com on 20 Jul 2012 at 6:02

[GoogleCodeExporter]

I had the same problem, and I tried unchecking the disconnect/reconnect boxes 
as suggested in comment 10, but I find that when I lock the screen and then log 
back in, the previous OpenVPN process is not recognised by TunnelBlick, which 
offers to ignore or terminate it. Either way it opens a new connection.

Original comment by jayjhenn...@gmail.com on 19 Sep 2013 at 12:45

[GoogleCodeExporter]

jayjhennessy -

There are three different situations:

When the computer goes to sleep.

When the computer user changes (not via logout/login, but by "fast user 
switching").

When the computer user logs out.

Tunnelblick's behavior in the first two situations is controlled by three 
checkboxes on the "Advanced" window.

Tunnelblick will disconnect all configurations when you log out except for 
configurations that are set to connect "When the computer starts". (That 
setting is on the "Settings" tab.)

So some questions:

What versions of OS X and Tunneblick are you using?

Are you logging out and logging back in again? Or are you locking the screen 
and then entering your password to unlock the screen? Or locking the screen and 
then logging in as a different user?

Original comment by jkbull...@gmail.com on 19 Sep 2013 at 1:10