Force OS X to use ONLY my Tunnelblick connection?

3,482 views
Skip to first unread message

Paul

unread,
Mar 3, 2010, 11:20:42 AM3/3/10
to tunnelblick-discuss
Is there any way to force OS X (10.5 in my case) to use ONLY my VPN/
Tunnelblick connection? When my VPN connection fails, I don't want my
applications to start using my normal, non-VPN connection.

Rory

unread,
Mar 4, 2010, 10:24:57 AM3/4/10
to tunnelblick-discuss
From what I know, adding the following line to your VPN's
configuration file will tell your computer to redirect all traffic
through the VPN connection once it is established.

redirect-gateway def1

You can tell it is in effect if you go to a site like whatismyip.com
and you see the WAN IP for the VPN server instead of the WAN IP of the
network you're currently on.

-Rory

Paul

unread,
Mar 5, 2010, 12:01:41 PM3/5/10
to tunnelblick-discuss
right, when it's working, all traffic is handled through tunnelblick;
when tunnelblick is connected, all is well. what i'm trying to do is
to make sure that when the connection to my vpn goes down, that my
computer doesn't automatically start using my non-vpn connection.

the reason i bring this up is, every 2 hours tunnelblick was seeing a
dns problem ("DNS configuration has changed") and trying to re-
configure something ("process restarting"). once in a while, this
restarting process would fail ("AUTH: Received AUTH_FAILED control
message" and "process exiting"). from then on, my normal, non-vpn
connection would resume, which is what i'm trying to avoid.

Diego Rivera

unread,
Mar 5, 2010, 12:28:58 PM3/5/10
to tunnelbli...@googlegroups.com
First off, Tunnelblick itself uses OpenVPN, which itself uses the TUN/TAP driver.  This last bit is the important one: that driver allows you to create a *virtual* interface to use as the tunnel endpoint, using software to write/read from it (and thus encapsulate the traffic, encrypt, etc..).

From that point of view, I don't think there's a way to tell MacOS X to ignore physical devices and only use the virtual one(s).  If there were, I'd be very (unpleasantly) surprised.

Furthermore, tunnelblick (and by extension openvpn) doesn't implement itself as a network service, so there is even less chance you'll be able to tell MacOS X to ignore "rightfully-configured" network services in favor of "some user's virtual concoction" (which, from the OS's point of view, is what tunnelblick is, coldly speaking), which would in any case depend on one of those "rightfully-configured" services to begin with unless you have a way to use the network and thus tunnelblick, without having to resort to Mac's traditional network services.

It becomes a chicken-egg scenario, and Mac will always err on the side of "sanity" (i.e. configurations and services that are part of the base OS's design).

Hope this helps clarify why I believe what you're wanting to do is impossible.

The best you can hope for is a big bad alarm that tells you "TUNNELBLICK IS DOWN!! STOP USING THE NETWORK!!" or, failing that, some script that disconnects all your networking devices via software as a result of Tunnelblick disconnection - which will inevitably result in you having to manually reconnect them (again, by software).

Cheers.
--
Diego Rivera
Director / System Operations
Roundbox Global : enterprise : technology : genius
------------------------------------------------------------------------------------------------------------------
Avenida 11 y Calle 7-9, Barrio Amón, San José, Costa Rica
tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506) 2258-3695
email: diego....@rbxglobal.com | www.rbxglobal.com
------------------------------------------------------------------------------------------------------------------
signature.asc

Niels Peen

unread,
Mar 5, 2010, 12:54:32 PM3/5/10
to tunnelbli...@googlegroups.com
I've tried this only on Linux, but imagine something similar is possible on OS/X:

- Manually configure the IP address and netmask for your Ethernet device.
- Do NOT configure a default gateway.
- Manually add a route to the IP of your VPN server, using your gateway (what normally would have been your default gateway)

This should cut you off the Internet almost completely, and allow you to connect to the VPN only.

Two notes:
- Make sure your VPN server is specific by IP, or that its hostname is in your /etc/hosts file, or that your gateway can function as a DNS. (I guess you could also add a route to your DNS server.)
- I haven't tested if the Tunnelblick scripts work without a default gateway.

Niels

Paul

unread,
Mar 5, 2010, 1:01:10 PM3/5/10
to tunnelblick-discuss
thanks, i think i can understand the outline of the problem now. part
of my problem is, i don't really get how, say, safari is able to see/
prefer/use the openvpn "concoction" (you say it's not a network
service). but that's ok, i don't really need to, at least not yet. :)

the next step for me will be trying to see if i can have tunnelblick
execute some script when its connection breaks, and then have that
script automatically drop my internet connection (by taking down my
ethernet or airport service, perhaps, which i would then need to re-
establish manually). i don't anticipate an unexpectedly-dropped
connection happening too often (once i figure out the cause of the dns
problem above), so hopefully this won't be too much of an
inconvenience.

thanks!

jkbull...gmail.com

unread,
Mar 5, 2010, 1:01:52 PM3/5/10
to tunnelblick-discuss
One possibility: A custom "down" script that leaves everything routed
to localhost. Something like:

/sbin/route add -net 0.0.0.0 127.0.0.1 128.0.0.0
/sbin/route add -net 128.0.0.0 127.0.0.1 128.0.0.0

I think (but haven't checked) that the next connect would then
override this and send everything through the tunnel.

On Mar 5, 12:28 pm, Diego Rivera <diego.riv...@rbxglobal.com> wrote:
> First off, Tunnelblick itself uses OpenVPN, which itself uses the TUN/TAP driver.  This last bit is the important one: that driver allows you to create a *virtual* interface to use as the tunnel endpoint, using software to write/read from it (and thus encapsulate the traffic, encrypt, etc..).
> From that point of view, I don't think there's a way to tell MacOS X to ignore physical devices and only use the virtual one(s).  If there were, I'd be very (unpleasantly) surprised.
> Furthermore, tunnelblick (and by extension openvpn) doesn't implement itself as a network service, so there is even less chance you'll be able to tell MacOS X to ignore "rightfully-configured" network services in favor of "some user's virtual concoction" (which, from the OS's point of view, is what tunnelblick is, coldly speaking), which would in any case depend on one of those "rightfully-configured" services to begin with unless you have a way to use the network and thus tunnelblick, without having to resort to Mac's traditional network services.
> It becomes a chicken-egg scenario, and Mac will always err on the side of "sanity" (i.e. configurations and services that are part of the base OS's design).
> Hope this helps clarify why I believe what you're wanting to do is impossible.
> The best you can hope for is a big bad alarm that tells you "TUNNELBLICK IS DOWN!! STOP USING THE NETWORK!!" or, failing that, some script that disconnects all your networking devices via software as a result of Tunnelblick disconnection - which will inevitably result in you having to manually reconnect them (again, by software).
> Cheers.

> On 3/5/10 11:01 AM, Paul wrote:right, when it's working, all traffic is handled through tunnelblick; when tunnelblick is connected, all is well. what i'm trying to do is to make sure that when the connection to my vpn goes down, that my computer doesn't automatically start using my non-vpn connection. the reason i bring this up is, every 2 hours tunnelblick was seeing a dns problem ("DNS configuration has changed") and trying to re- configure something ("process restarting"). once in a while, this restarting process would fail ("AUTH: Received AUTH_FAILED control message" and "process exiting"). from then on, my normal, non-vpn connection would resume, which is what i'm trying to avoid.--Diego Rivera


> Director / System Operations
> Roundbox Global :enterprise : technology : genius
> ------------------------------------------------------------------------------------------------------------------
> Avenida 11 y Calle 7-9, Barrio Amón, San José, Costa Rica
> tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506) 2258-3695
> email:diego....@rbxglobal.com|www.rbxglobal.com
> ------------------------------------------------------------------------------------------------------------------
>
>
>

>  signature.asc
> < 1KViewDownload

Diego Rivera

unread,
Mar 5, 2010, 1:21:11 PM3/5/10
to tunnelbli...@googlegroups.com
You can do something like that, but then that both butchers your networking configuration, and also creates the need to maintain a public set of IP's.

Also bear in mind that this may also cause other subtle problems at the routing level since it is, in essence, a kludge.

I think a wiser approach would be to ask these three questions:
  1. Why exactly is it so unacceptable to continue to use the network when the VPN is down?
  2. What is the most frequent negative impact (in your particular use cases) of accessing the network outside of the VPN?
  3. What are the greatest risks you face while using the network normally (i.e. via the VPN), that would eventuate should the VPN go down, and you continue to use the network without the VPN (would you even notice that?!?)
I find that simplicity always yields better results... hence why I think a cold look at the problem might yield more truth than a perceived solution that simply doesn't appear to smoothly fit "nature"...

Just my $0.02

Cheers.
--
signature.asc

jkbull...gmail.com

unread,
Mar 5, 2010, 2:05:47 PM3/5/10
to tunnelblick-discuss
I don't understand why you say it "creates the need to maintain a

public set of IP's".

It guess it does "butcher" the networking configuration, but that's
the point.

The reason to block all network activity when the VPN is down is to
prevent information leaks.

If you are using a VPN, you are hiding web browsing activity from all
intermediaries.
That can be important if your internet access is provided or monitored
by a "repressive" government, for example.

If the VPN is down and you continue to access the Internet, you expose
your activities.

On Mar 5, 1:21 pm, Diego Rivera <diego.riv...@rbxglobal.com> wrote:
> You can do something like that, but then that both butchers your networking configuration, and also creates the need to maintain a public set of IP's.
> Also bear in mind that this may also cause other subtle problems at the routing level since it is, in essence, a kludge.

> I think a wiser approach would be to ask these three questions:Why exactly is it so unacceptable to continue to use the network when the VPN is down?What is the most frequent negative impact (in your particular use cases) of accessing the network outside of the VPN?What are the greatest risks you face while using the network normally (i.e. via the VPN), that would eventuate should the VPN go down, and you continue to use the network without the VPN (would you even notice that?!?)I find that simplicity always yields better results... hence why I think a cold look at the problem might yield more truth than a perceived solution that simply doesn't appear to smoothly fit "nature"...
> Just my $0.02
> Cheers.
> On 3/5/10 12:01 PM, jkbull...gmail.com wrote:One possibility: A custom "down" script that leaves everything routed to localhost. Something like: /sbin/route add -net 0.0.0.0 127.0.0.1 128.0.0.0 /sbin/route add -net 128.0.0.0 127.0.0.1 128.0.0.0 I think (but haven't checked) that the next connect would then override this and send everything through the tunnel. On Mar 5, 12:28 pm, Diego Rivera<diego.riv...@rbxglobal.com>wrote:First off, Tunnelblick itself uses OpenVPN, which itself uses the TUN/TAP driver.  This last bit is the important one: that driver allows you to create a *virtual* interface to use as the tunnel endpoint, using software to write/read from it (and thus encapsulate the traffic, encrypt, etc..). From that point of view, I don't think there's a way to tell MacOS X to ignore physical devices and only use the virtual one(s).  If there were, I'd be very (unpleasantly) surprised. Furthermore, tunnelblick (and by extension openvpn) doesn't implement itself as a network service, so there is even less chance you'll be able to tell MacOS X to ignore "rightfully-configured" network services in favor of "some user's virtual concoction" (which, from the OS's point of view, is what tunnelblick is, coldly speaking), which would in any case depend on one of those "rightfully-configured" services to begin with unless you have a way to use the network and thus tunnelblick, without having to resort to Mac's traditional network services. It becomes a chicken-egg scenario, and Mac will always err on the side of "sanity" (i.e. configurations and services that are part of the base OS's design). Hope this helps clarify why I believe what you're wanting to do is impossible. The best you can hope for is a big bad alarm that tells you "TUNNELBLICK IS DOWN!! STOP USING THE NETWORK!!" or, failing that, some script that disconnects all your networking devices via software as a result of Tunnelblick disconnection - which will inevitably result in you having to manually reconnect them (again, by software). Cheers. On 3/5/10 11:01 AM, Paul wrote:right, when it's working, all traffic is handled through tunnelblick; when tunnelblick is connected, all is well. what i'm trying to do is to make sure that when the connection to my vpn goes down, that my computer doesn't automatically start using my non-vpn connection. the reason i bring this up is, every 2 hours tunnelblick was seeing a dns problem ("DNS configuration has changed") and trying to re- configure something ("process restarting"). once in a while, this restarting process would fail ("AUTH: Received AUTH_FAILED control message" and "process exiting"). from then on, my normal, non-vpn connection would resume, which is what i'm trying to avoid.--Diego Rivera Director / System Operations Roundbox Global :enterprise : technology : genius ------------------------------------------------------------------------------------------------------------------ Avenida 11 y Calle 7-9, Barrio Amón, San José, Costa Rica tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506) 2258-3695email:diego....@rbxglobal.com|www.rbxglobal.com------------------------------------------------------------------------------------------------------------------  signature.asc < 1KViewDownload--Diego Rivera

Diego Rivera

unread,
Mar 5, 2010, 2:30:04 PM3/5/10
to tunnelbli...@googlegroups.com
See below


On 3/5/10 1:05 PM, jkbull...gmail.com wrote:
I don't understand why you say it "creates the need to maintain a
public set of IP's".
  
Sorry....meant "static" not public - had my head in several places at the time and mixed up my words :)

It guess it does "butcher" the networking configuration, but that's
the point.

The reason to block all network activity when the VPN is down is to
prevent information leaks.

If you are using a VPN, you are hiding web browsing activity from all
intermediaries.
That can be important if your internet access is provided or monitored
by a "repressive" government, for example.

  
I see your point - the VPN isn't being used to access a private network, but to safely tunnel through a "hostile" network and continue access public resources.

If the VPN is down and you continue to access the Internet, you expose
your activities.
  
Yes, now I see your point.  Then again - the "mysterious, encrypted traffic traveling from Mr. A's computer to some other computer somewhere over this protocol and port" is kind of a dead giveaway anyhow, don't you think? :)  If the "repressive" entity has any hint of competence, this will certainly be a giveaway.  If not, then a little bit of "leaked" traffic won't be such a problem b/c of their incompetence anyhow methinks...

At any rate, the best place to hide the truth is between two lies (and vice-versa).  Thus, it might be easier to disguise the actual tunneled traffic among "normal" traffic... wouldn't it?

Cheers.

On Mar 5, 1:21 pm, Diego Rivera <diego.riv...@rbxglobal.com> wrote:
  
You can do something like that, but then that both butchers your networking configuration, and also creates the need to maintain a public set of IP's.
Also bear in mind that this may also cause other subtle problems at the routing level since it is, in essence, a kludge.
I think a wiser approach would be to ask these three questions:Why exactly is it so unacceptable to continue to use the network when the VPN is down?What is the most frequent negative impact (in your particular use cases) of accessing the network outside of the VPN?What are the greatest risks you face while using the network normally (i.e. via the VPN), that would eventuate should the VPN go down, and you continue to use the network without the VPN (would you even notice that?!?)I find that simplicity always yields better results... hence why I think a cold look at the problem might yield more truth than a perceived solution that simply doesn't appear to smoothly fit "nature"...
Just my $0.02
Cheers.
On 3/5/10 12:01 PM, jkbull...gmail.com wrote:One possibility: A custom "down" script that leaves everything routed to localhost. Something like: /sbin/route add -net 0.0.0.0 127.0.0.1 128.0.0.0 /sbin/route add -net 128.0.0.0 127.0.0.1 128.0.0.0 I think (but haven't checked) that the next connect would then override this and send everything through the tunnel. On Mar 5, 12:28 pm, Diego Rivera<diego.riv...@rbxglobal.com>wrote:First off, Tunnelblick itself uses OpenVPN, which itself uses the TUN/TAP driver.  This last bit is the important one: that driver allows you to create a *virtual* interface to use as the tunnel endpoint, using software to write/read from it (and thus encapsulate the traffic, encrypt, etc..). From that point of view, I don't think there's a way to tell MacOS X to ignore physical devices and only use the virtual one(s).  If there were, I'd be very (unpleasantl
y) surprised. Furthermore, tunnelblick (and by extension openvpn) doesn't implement itself as a network service, so there is even less chance you'll be able to tell MacOS X to ignore "rightfully-configured" network services in favor of "some user's virtual concoction" (which, from the OS's point of view, is what tunnelblick is, coldly speaking), which would in any case depend on one of those "rightfully-configured" services to begin with unless you have a way to use the network and thus tunnelblick, without having to resort to Mac's traditional network services. It becomes a chicken-egg scenario, and Mac will always err on the side of "sanity" (i.e. configurations and services that are part of the base OS's design). Hope this helps clarify why I believe what you're wanting to do is impossible. The best you can hope for is a big bad alarm that tells you "TUNNELBLICK IS DOWN!! STOP USING THE NETWORK!!" or, failing that, some script that disconnects all your networking devices v
ia software as a result of Tunnelblick disconnection - which will inevitably result in you having to manually reconnect them (again, by software). Cheers. On 3/5/10 11:01 AM, Paul wrote:right, when it's working, all traffic is handled through tunnelblick; when tunnelblick is connected, all is well. what i'm trying to do is to make sure that when the connection to my vpn goes down, that my computer doesn't automatically start using my non-vpn connection. the reason i bring this up is, every 2 hours tunnelblick was seeing a dns problem ("DNS configuration has changed") and trying to re- configure something ("process restarting"). once in a while, this restarting process would fail ("AUTH: Received AUTH_FAILED control message" and "process exiting"). from then on, my normal, non-vpn connection would resume, which is what i'm trying to avoid.--Diego Rivera Director / System Operations Roundbox Global :enterprise : technology : genius ----------------------------------------------
-------------------------------------------------------------------- Avenida 11 y Calle 7-9, Barrio Amón, San José, Costa Rica tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506) 2258-3695email:diego....@rbxglobal.com|www.rbxglobal.com------------------------------------------------------------------------------------------------------------------  signature.asc < 1KViewDownload--Diego Rivera
Director / System Operations
Roundbox Global :enterprise : technology : genius
------------------------------------------------------------------------------------------------------------------
Avenida 11 y Calle 7-9, Barrio Amón, San José, Costa Rica
tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506) 2258-3695
email:diego....@rbxglobal.com|www.rbxglobal.com
------------------------------------------------------------------------------------------------------------------



 signature.asc
< 1KViewDownload
    
  

--
signature.asc

Mohammad A. Haque

unread,
Mar 5, 2010, 10:05:25 PM3/5/10
to tunnelbli...@googlegroups.com, tunnelblick-discuss
The following will only work for protocols that can be proxied and
actually honor system wide proxy settngs:

* Setup a proxy (SOCKS) on the private network. This can be a real
proxy server or you can fake it by setting up ssh to act a proxy.
* Configure your Ethernet/Airport interfaces to use proxy

Now web browsing (and others that understand this setup) will always
attempt to go through the private proxy. If the VPN is down, it won't
be able to reach the proxy and fail.

Sent from my iPhone

On Mar 5, 2010, at 13:01, "jkbull...gmail.com" <jkbu...@gmail.com>
wrote:

> --
> 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
> .
>

Disconnect

unread,
Mar 9, 2010, 9:17:45 PM3/9/10
to tunnelblick-discuss
If openvpn doesn't reset the gateway (or any other routes) when it goes down, it will behave the way the OP wants it to - when its up, it works. When it goes down, only the vpn endpoint is reachable and you need to take manual steps to use the local network.

Requires a patch to openvpn but its one I'm comfortable saying is safe (might even get accepted upstream) because it -removes- functionality (so no security impact)
Reply all
Reply to author
Forward
0 new messages