disabling network access prior to connection?

[Lou Klepner]

Hi,

When waking my laptop from sleep, the email app generally runs a check
*prior* to tunnelblick initiating its connection. I'd like to prevent
this from happening, not only for the email app. Is there a way to
prevent network access prior to tunnelblick establishing its
connection?

Thanks,
Lou

[jkbull...gmail.com]

Not as far as I know.

One way that might work around it would be to somehow make your
network settings invalid, and have a "pre-connect" script in
Tunnelblick force them to valid values just before making the
connection. But that would still leave a window of time when other
network activity could take place -- between the time that Tunnelblick
forces them valid and the time the VNP connection is completely
established. I could put code in Tunnelblick that disabled the network
when going to sleep, and enabled it when waking up, but it would
suffer from the same timing problem. Essentially, Tunnelblick needs
network access to make a connection, and if Tunnelblick has network
access, then so does the rest of the system.

So I'm afraid you'd have to "suspend" the email program prior to
sleeping, and then "resume" it after Tunnelblick has re-established
the connection. Maybe you could write a script to do that -- one that
runs in the background all the time and reacts to sleep and wake
signals.

[Lou Klepner]

Thanks for the background info.

Sometimes my OpenVPN connection is interrupted for reasons other than sleep (hiccup on the openvpn server side of things, i'm guessing?) and in these cases my web and email traffic will flow through the default adapter(?) unencrypted. I'd much prefer to get a warning message and have tunnelblick halt all traffic and wait for reconnection.

I'm reminded of Little Snitch. I wonder how they accomplish their network access interrupt? I wonder if it'd be possible for Tunnelblick to hook in at a similar point and prevent traffic from flowing unencrypte if a tunnel was opening or reconnecting? Just brainstorming a bit, I might be completely off-base in terms of implementation.

> --
> You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.
> To post to this group, send email to tunnelbli...@googlegroups.com.
> To unsubscribe from this group, send email to tunnelblick-dis...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/tunnelblick-discuss?hl=en.
>

[jkbull...gmail.com]

Interrupting it like Little Snitch would work except there's still the
problem that Tunnelblick needs Internet access to reconnect. And so
the Internet connection would have to be turned on to do the
reconnection.

What we need is to have Tunnelblick (actually, OpenVPN, which does all
the work) have exclusive access to the network connection until the
VPN is established.

Maybe something like use the OS X Firewall to temporarily disable all
programs except OpenVPN from any access to the Internet?

Ideas, anyone?

[Lou Klepner]

Interrupting like Little Snitch, what if Tunnelblick explicitly routed its own requests around the block? In essence holding all network traffic other than the traffic originating in Tunnelblick?

[jkbull...gmail.com]

That would be fine, too. But I don't know how to do any of this stuff.

[Lou Klepner]

Hmmm. Neither do I. I wonder how Tunnelblick connects to the OS X network stack to begin with.

[Jonathan K. Bullard]

OpenVPN does all this, using the tun or tap .kexts. But I don't know the details.

[R.Stoye]

Am 09.10.2010 um 19:28 schrieb jkbull...gmail.com:

> That would be fine, too. But I don't know how to do any of this stuff.

We need to solve the following:

a) block some ports on sleep
b) detect vpn reconnection and delete the blocking rule

blocking some ports with ipfw is easy (as root):
ipfw add 4711 deny log ip from any to any 143,220,585,993,25 out
by using a rulenumber (4711) its also easy to delete this rule if
needet:
ipfw delete 4711
you can check the ipfw rules with
ipfw show

detecting sleep is not to difficult , i once needet to prevent a
machine from sleeping 2 times in a raw, because some software didn't
work after sleep
so i wrote a little program counting the sleeps and initiating a
restart on the second sleep.
(see the attached main.c file)

Maybe it is necessary to integrate the ipfw rule creation and deletion
into a small program which when running initiates the block everytime
a sleep is initiated. an example how to call ipfw as a shell
invocation from c, see the attachment call2.c
(must run as root to access ipfw)

Someone could use this info as a scribble to create a solution for the
op's problem.

Greetings
Ralf

[jkbull...gmail.com]

Thank you very much for this information, R.Stoye. Very helpful.

At a quick glance, I have three concerns about "ipfw add 4711 deny log
ip from any to any 143,220,585,993,25 out":

(1) Will it work on OS X 10.4, 10.5, and 10.6 without any changes?

(2) What happens if there already is a rule 4711? If ipfw returns an
error, Tunnelblick can try another (random) rule number until it gets
one that worked. If ipfw replaces the old rule with ours, that is a
big problem.

(3) Does this ipfw rule allow OpenVPN to reestablish the connection?

Assuming these can be dealt with, I could put this into Tunnelblick.

I would propose two options (both disabled by default -- at least at
first): block all connectivity unless there is a VPN connection
(BLOCK_ALL), and block only when waking up from sleep until a VNP
connection has been established (BLOCKWAKE). It will be complex to
implement them to work with the "connect when computer starts" option
available in Tunnelblick 3.1beta16, though, because Tunnelblick itself
isn't running -- only OpenVPN is running.

I guess I'll be looking closely at ipfw! I have a lot of stuff stacked
up, though, so it may be a while before I can get around to it.

>  main.c
> 5KViewDownload
>
>
>
>  callit2.c
> < 1KViewDownload
>
>

[R.Stoye]

Am 12.10.2010 um 16:43 schrieb jkbull...gmail.com:
> At a quick glance, I have three concerns about "ipfw add 4711 deny log
> ip from any to any 143,220,585,993,25 out":
>
> (1) Will it work on OS X 10.4, 10.5, and 10.6 without any changes?

runs on 10.4 and 10.5, didn't test 10.6 but hey it's puse bsd firewall
code!

>
> (2) What happens if there already is a rule 4711? If ipfw returns an
> error, Tunnelblick can try another (random) rule number until it gets
> one that worked. If ipfw replaces the old rule with ours, that is a
> big problem.

yes, one should use 'ipfw show' to test for used rule numbers

>
> (3) Does this ipfw rule allow OpenVPN to reestablish the connection?

this rule just blocks the given ports (143,.....)
the right thing would be to block anything but the ports one needs to
restablish the vpn connection, but i don't know them all
(can i?: bootp, dns, kerberos... ???)
so i started by just blocking mail related ports, i am sure this list
should be *carefully* choosen.
the right thing:
ipfw add <unused low number> <allow any local connections, just don't
remember syntax>
ipfw add <unused low number+1> allow ip from any to any <list of ports
needed to reestablish network> out
ipfw add <unused low number+2> deny ip from any to any

not shure if we really need 3 rulenumbers - maybe adding all with one
number is also ok
btw. OS X used to refuse to install own firewall rules once it detects
other rules are manually installed, that may be a problem.

>
> Assuming these can be dealt with, I could put this into Tunnelblick.

Be careful, i think this may should be another project, something like
little snitch, only for special cases.

>
> I would propose two options (both disabled by default -- at least at
> first): block all connectivity unless there is a VPN connection

for BLOCK_ALL we need to know all needet ports (see above)

> (BLOCK_ALL), and block only when waking up from sleep until a VNP
> connection has been established (BLOCKWAKE). It will be complex to
> implement them to work with the "connect when computer starts" option
> available in Tunnelblick 3.1beta16, though, because Tunnelblick itself
> isn't running -- only OpenVPN is running.

may be we could implement an service started at boot time, reading a
preference which ports to block,
reacting on some special signals ( or hooking into ntework change and
powerdown events ) or ...
just a scribble!

>
> I guess I'll be looking closely at ipfw! I have a lot of stuff stacked
> up, though, so it may be a while before I can get around to it.

sorry to tell you, currently i have no time left to help you
implementing the whole idea,
but don't hesitate to ask questions if you run into problems
(i'am still running tunnelblick 3.0b10 with some custom scripts for
regarding dns)

greetings
ralf

[jkbull...gmail.com]

Thanks! Very helpful.

[cprise]

I am also concerned about TB/openvpn disconnecting and allowing
traffic in the clear without any warnings. As it is now, I have to
constantly keep my eye on the TB icon for reassurance while using the
VPN.

This seems like a precariously insecure way to manage a VPN
connection. Should be made a priority, no?

[jkbull...gmail.com]

I agree that this is important and should be a priority. I'd like
anyone's/everyone's ideas about this.

Here are my current thoughts. (I'm looking for the "perfect", "easy"
solution first, but I'm aware that "the perfect is the enemy of the
good", so we may have to settle for less.):

1. The user should be able to specify (as an option) something like
"always send network traffic through the VPN".

2. This isn't needed for OpenVPN servers, only for OpenVPN clients.

3. Tunnelblick "knows" when the connection is made and broken (and
whether the make/break was requested by the user, caused by sleep/
wake, or the result of some problem), so Tunnelblick should deal with
these situations. That is, this should be handled by Tunnelblick, not
by an external program. (That's not to say it shouldn't be implemented
as a pair of external programs -- disable/enable, but that they should
be invoked by Tunnelblick.)

Complications:

1a. If the computer is connected to a "trusted" network (whatever
that means), the VPN should be inhibited. This handles the situation
of a laptop that should connect directly to a corporate network when
in the office, but use the VPN when out of the office. It isn't clear
how the user specifies such a "trusted" network to Tunnelblick.

1b. An option should exempt DNS traffic -- this is a very common
request. Maybe this is related to having different DNS servers for
different domains. For example, when connected to a work VPN at
example.com, we want all example.com DNS queries to go through the
VPN, but other queries to go to the local DNS. Or maybe local queries
(whatever they are) go through the local DNS, and all other queries go
through the VPN DNS?

1c. Should DHCP traffic always be exempt? I'm very fuzzy about how
DHCP interacts with a VPN. It seems to me that the computer's IP
address, subnet mask, and gateway must come from the local network so
the computer can access the VPN through that local network. But there
are some OpenVPN options that pass DHCP stuff through from the server
-- does this only affect how the computer deals with the far end of
the VPN?

1d. Must deal with "Connect when computer starts" connections --
inhibit network access at boot, then enable it only when connected to
the VPN, all before Tunnelblick runs (if it ever runs).

1e. This will require root access, so it should use "suid" -- but it
shouldn't allow non-administrators to bypass it. Can this be
accomplished?

1f. Can/should we inhibit all ports except a certain subset (DHCP,
OpenVPN, DNS, Bonjour(?))? That is, use a whitelist instead of a
blacklist?

1g. Should/how do we deal with simultaneous connections to multiple
VPNs?

1h. Can we avoid _any_ leakage of traffic? I don't think so -- if the
VPN goes down suddenly, there will be a time after it is torn down,
but before we disable network access, during which access is allowed.

As you can see, I'm not very expert about this -- I need lots of
input. All responses are welcome!

[Cole Greaves]

Hello all,

I want to say I really like the tunnelblick program.

First, I am a novice and I realized that every time I see the emails going
back and forth.

I do have a question. I am ussing Tunnelblick to connect to an Astaro
Security Appliance. It works fine and I am able to access the far end
network and web browse through that network, I even am doing my DNS queries
from the far network. (I verified by going a site that showed me the ISP
address, and check the DNS logs).

Should I be concerned about leakage? What type of information is sent out of
un-trusted network that I should be concerned about?

Thanks!

[jkbull...gmail.com]

Cole, thanks for your question. Please remember two things
1. All comments and questions are welcome -- sometimes even naive
ones can make us rethink our basic premises; and
2. Everyone was a novice at some point, nobody knows everything, and
everyone is a novice about some things.

Now, to address your question (I hope):

There is only "leakage" when the VPN is not connected:
1. The time from computer startup until the VPN is established;
2. The time from awakening from sleep until the VPN is reestablished;
and
3. The time from when the VPN connection goes down for any other
reason until it is reestablished.

As to what is "leaks" during those times, it depends on what is
running. If you start your browser or email program (for example) only
after the VPN is established and close them before putting your
computer to sleep, that takes care of 1 and 2. (Although other
programs like Apple's Software Update may make queries during these
times, that probably isn't a big problem for most people.)

There currently isn't a solution to 3; you have to "notice" that the
Tunnelblick icon is indicating that the VPN connection has been lost.
That's part of what this discussion is about.

As an interim measure, perhaps there should be an option to have
Tunnelblick put up a warning window when the VPN connection goes down.

Note: This entire discussion assumes that the "redirect-gateway"
OpenVPN option is specified in the client configuration file, or is
pushed from the server to the client -- otherwise only some traffic
goes through the VPN and the rest is sent normally, so a lot of stuff
is leaked.

On Dec 1, 11:16 am, Cole Greaves <coleridg...@gmail.com> wrote:
> Hello all,
>
> I want to say I really like the tunnelblick program.
>
> First, I am a novice and I realized that every time I see the emails going
> back and forth.
>
> I do have a question. I am ussing Tunnelblick to connect to an Astaro
> Security Appliance. It works fine and I am able to access the far end
> network and web browse through that network, I even am doing my DNS queries
> from the far network. (I verified by going a site that showed me the ISP
> address, and check the DNS logs).
>
> Should I be concerned about leakage? What type of information is sent out of
> un-trusted network that I should be concerned about?
>
> Thanks!
>

[Christopher Laprise]

Just checking, has any progress been made on this problem? I like some
of the points you brought up, JK.

I wouldn't think its necessary to give priority to the use case of
blocking traffic from bootup until the VPN starts. This isn't how most
VPN clients work, and its easier for an admin to supply a solution for
this requirement because both system startup and connection to the VPN
are controlled, user-initiated processes.

An unexpected disconnection, however, seems to be more of a problem. Its
uncontrolled and spills information the user thought was secure out onto
the open net.

Some thoughts:

1. If openvpn would signal that the connection was lost several seconds
before doing anything then maybe another program (like Tunnelblick)
could take action without exposing data.

2. I thought that if the VPN went down the routing tables had to be
restored to their prior 'normal' state so that network traffic can flow
(this is how I think openvpn normally works... it restores routing info
on exit).

If openvpn left the routing info untouched after a connection was lost
then wouldn't net access stay blocked (with zero leakage) until further
action was taken? This behavior would allow a GUI like Tunnelblick to
prompt the user about the lost connection and let them make a decision
-- to quit or reconnect -- in safety. This strikes me as a very natural
course to take involving the least amount of pain.

3. What options are there to persistently reconnect, and are the routing
tables touched while reconnection is being attempted? (Secure answer to
the last part I think would be 'No').

4. You are right: Options like 'redirect-gateway' which redirect all
traffic have an added security connotation to them: It is not up to the
client applications to specifically address a VPN-secured address range.

5. Openvpn and Tunnelblick should differentiate between 'initiated
connect', 'reconnect', 'lost connection' and 'initiated disconnect' as
distinct states or processes so that sessions can be managed securely.
The impression I'm getting is that the openvpn people have treated
reconnection as just being another connection process that happens
later, and that 'connection' isn't so much a conceptual phase that is
satisfied by code but more like just a phase in their code. This
thinking has lead to the leakage problem.

6. I think (1b - 1f) don't really apply to a 'lost connection' state
since that state is very temporary and not a part of system startup.

7. (1a) sounds very nice but I think its a separate feature. Flagging a
Mac OS Location+Interface combination as 'secure' in Tunnelblick could
make this usable.

8. Re: your (1g) point: When multiple connections are involved, only one
can actively have all traffic routed through it. The anti-leakage
measures would automatically act on only that connection.

9. I think its possible to prevent any/all leakage (1h) after a
connection is lost if the OS and openvpn help us out a little (see my #1-3).

10. Maybe you could get some of the openvpn people involved on this issue...

[jkbull...gmail.com]

I haven't had a chance to consider your comments as well as I would like to yet (but I hope to at some point).

I want to point out the following thread:

https://groups.google.com/d/topic/tunnelblick-discuss/Zfx42BAmHO8/discussion