Get Tunnelblick to prefer Wifi?

[tink]

Several of our Mac users are on both wired and Wifi while at work (laptops attached to screens with ethernet cabling). 

When they connect to the VPN Tunnelblick prefers the wired connection, which means they lose connectivity to machines only reachable via VPN.  How can I make Tunnelblick use the Wifi interface?  We have a fairly unusual setup in that not all traffic is forced through the VPN, just the traffic to a bunch of dedicated machines. Setting the default route to go via wireless is undesirable, both wired and wireless are on DHCP (so 'local x.x.x.x' in the OpenVPN config portion doesn't seem feasible).

Any ideas?

Cheers,

Andrej

--

If one could run without getting tired, I don't think one would often want to do anything else. 

                                                                                                               --C. S. Lewis

[Tunnelblick developer]

A couple of questions:

• Are you running all network traffic through the VPN?
  
  
• Presumably Wi-Fi and Ethernet have different IP addresses; do they have different DNS servers serving them?
  
  
• When the VPN is not active, through which interface(s) do you want traffic directed and how do you cause that to happen?
  
  
• When the VPN is active, what do you want to go through Ethernet and what do you want to go through Wi-Fi?
  

Here's some background:

What network interfaces are used depends on how they are configured.

Older versions of macOS used only one network service, the one that appears at the top of the list in macOS's System Preferences : Network. Services (i.e., interfaces) appear in a specific order under the user's control. A service that is unavailable (Ethernet not connected or Wi-Fi turned off or not connected to a network) are moved below services that are available. On such older systems, either Wi-Fi or Ethernet would be used, but not both at the same time. If both were available, only the one the user put at the top of the list would be used (or the default; I don't remember the default order).

More recent versions of macOS may (I'm not sure) actually use both at the same time. I vaguely remember this being added to macOS a few years (and versions) ago, but I don't know if it is enabled by default, so it may not come into play here.

[tink]

On Wed, Oct 17, 2018 at 6:29 AM Tunnelblick developer <jkbu...@gmail.com> wrote:

A couple of questions:

• Are you running all network traffic through the VPN?
  

No, just a subset of our own address space (public IP addresses, but not reachable from outside - firewalled off; the

only way to get there is the VPN).

 

• Presumably Wi-Fi and Ethernet have different IP addresses; do they have different DNS servers serving them?
  

Different IPs, same network range, same default GW, same DNS servers

 

• When the VPN is not active, through which interface(s) do you want traffic directed and how do you cause that to happen?
  

It seems to default to wired, we're not too fussed; the advantage is performance on the wired network, Gigabit to the desks.

 

• When the VPN is active, what do you want to go through Ethernet and what do you want to go through Wi-Fi?
  

Through VPN (wifi) just a certain range of IPs that people may need to be able to get to while in a meeting (away from 

their desks).

Here's some background:

What network interfaces are used depends on how they are configured.

Older versions of macOS used only one network service, the one that appears at the top of the list in macOS's System Preferences : Network. Services (i.e., interfaces) appear in a specific order under the user's control. A service that is unavailable (Ethernet not connected or Wi-Fi turned off or not connected to a network) are moved below services that are available. On such older systems, either Wi-Fi or Ethernet would be used, but not both at the same time. If both were available, only the one the user put at the top of the list would be used (or the default; I don't remember the default order).

More recent versions of macOS may (I'm not sure) actually use both at the same time. I vaguely remember this being added to macOS a few years (and versions) ago, but I don't know if it is enabled by default, so it may not come into play here.

The order seems to be that MacOS prefers the faster device.  I checked on my laptop and that of one colleague.  I'll see if ordering the interfaces differently makes the VPN issue go away (it would obviously make the benefit of the fast connection go away altogether if the default route were changed to the wifi interface. Which is why I was asking whether tunnelblick had an  option to tie to a specific device.

Cheers,

Andrej

[Tunnelblick developer]

Tunnelblick itself has nothing to do with this, it is all done by OpenVPN. I'm not aware of anything in OpenVPN itself that would do what I think you want, either.

The only thing I can think of is for you to use pre-connect and post-disconnect scripts to disable and then re-enable Wi-Fi if both interfaces are connected. I'm not sure that's acceptable to you, though, and it's treating the symptom, not curing the problem, but it might be better than nothing.

On Tuesday, October 16, 2018 at 6:15:54 PM UTC-4, Andrej wrote:

[tink]

On Wed, Oct 17, 2018 at 1:47 PM Tunnelblick developer <jkbu...@gmail.com> wrote:

Tunnelblick itself has nothing to do with this, it is all done by OpenVPN. I'm not aware of anything in OpenVPN itself that would do what I think you want, either.

The only thing I can think of is for you to use pre-connect and post-disconnect scripts to disable and then re-enable Wi-Fi if both interfaces are connected. I'm not sure that's acceptable to you, though, and it's treating the symptom, not curing the problem, but it might be better than nothing.

Seems a bit like overkill; I think for the "migrants" here I'll just re-order the interfaces and penalise them with poorer performance; if they

don't like that it'll be a training thing - disconnect VPN, unplug machine, reconnect VPN. ;)

 

Thank you very much for your help! :)

Cheers,

Andrej

On Tuesday, October 16, 2018 at 6:15:54 PM UTC-4, Andrej wrote:

On Wed, Oct 17, 2018 at 6:29 AM Tunnelblick developer <> wrote:

A couple of questions:

• Are you running all network traffic through the VPN?
  

No, just a subset of our own address space (public IP addresses, but not reachable from outside - firewalled off; the

only way to get there is the VPN).

 

• Presumably Wi-Fi and Ethernet have different IP addresses; do they have different DNS servers serving them?
  

Different IPs, same network range, same default GW, same DNS servers

 

• When the VPN is not active, through which interface(s) do you want traffic directed and how do you cause that to happen?
  

It seems to default to wired, we're not too fussed; the advantage is performance on the wired network, Gigabit to the desks.

 

• When the VPN is active, what do you want to go through Ethernet and what do you want to go through Wi-Fi?
  

Through VPN (wifi) just a certain range of IPs that people may need to be able to get to while in a meeting (away from 

their desks).

Here's some background:

What network interfaces are used depends on how they are configured.

Older versions of macOS used only one network service, the one that appears at the top of the list in macOS's System Preferences : Network. Services (i.e., interfaces) appear in a specific order under the user's control. A service that is unavailable (Ethernet not connected or Wi-Fi turned off or not connected to a network) are moved below services that are available. On such older systems, either Wi-Fi or Ethernet would be used, but not both at the same time. If both were available, only the one the user put at the top of the list would be used (or the default; I don't remember the default order).

More recent versions of macOS may (I'm not sure) actually use both at the same time. I vaguely remember this being added to macOS a few years (and versions) ago, but I don't know if it is enabled by default, so it may not come into play here.

The order seems to be that MacOS prefers the faster device.  I checked on my laptop and that of one colleague.  I'll see if ordering the interfaces differently makes the VPN issue go away (it would obviously make the benefit of the fast connection go away altogether if the default route were changed to the wifi interface. Which is why I was asking whether tunnelblick had an  option to tie to a specific device.

Cheers,

Andrej

--
You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tunnelblick-dis...@googlegroups.com.
Visit this group at https://groups.google.com/group/tunnelblick-discuss.
For more options, visit https://groups.google.com/d/optout.

[tink]

How does Tunnelblick invoke openvpn?  I was wondering whether I could "calculate" the IP tied to the wifi interface and pass it to openvpn with the --local flag from Tunnelblick.

[Tunnelblick developer]

Invoking OpenVPN

OpenVPN is started by the Tunnelblick daemon (tunnelblickd) which runs as root and launches OpenVPN running as root. (OpenVPN must start as root so it is able to make the network changes needed to implement the VPN, such as routing.)

Tunnelblick itself sends commands to tunnelblickd, and so does a legacy command-line program, "openvpnstart" which is included inside of the Tunnelblick application.

You include OpenVPN options in the (static) OpenVPN configuration file, but you can't pass them through Tunnelblick any other way. Tunnelblick "locks down" the configuration file and options that it sends OpenVPN for security reasons.

Using --local

I can think of two ways to have a "dynamic" IP address in a --local OpenVPN configuration, as follows:

Method #1 (I'm not absolutely sure this will work, but I think so)

1. Include a pre-connect.sh script (see Using Scripts) in your Tunnelblick VPN Configuration. The script should:
1. Determines the IP address of the Wi-Fi interface
2. If Wi-Fi is active, writes one line: "local <Wi-Fi IP address" to a file named config2.ovpn to somewhere outside of Tunnelblick's notice.
3. If Wi-Fi isn't active, writes a one-line comment "# No Wi-Fi" to the file described in 1.2 above.
   
   
2. Include the following line in the "normal" OpenVPN configuration file that Tunnelblick uses:
   

config "<path-to-the-file-created-in-1.2"

OpenVPN would in effect include the "local <Wi-Fi IP address" in the options it processes.

The "file-created-in-1.2" should be owned by root/wheel with 744 permissions so it can't be modified by any unprivileged programs. It should be located outside of the Tunnelblick configuration; you could put it in /private/tmp (see Paths, below). If you have more than one VPN configuration, you should probably name the file so it includes the VPN configuration's name instead of the fixed "config2.ovpn" mentioned above.

 

Method #2

1. Create a "pre-connect.sh" script that calculates the Wi-Fi IP address and appends one line ("local <Wi-Fi IP address>") to the end of the config.ovpn file inside of the Tunnelblick VPN Configuration.

2.  Create a "post-disconnect.sh" script that removes the line (e.g. using "head -n -1 config.ovpn > temp.txt ; mv temp.txt config.ovpn". 

(The reason for removing the line after disconnecting is so that Tunnelblick won't notice that the configuration file has changed and require a computer administrator's approval to use the change.)

 

Method #2 has the disadvantage that if for some reason the post-disconnect.sh script doesn't run (e.g., the computer or OpenVPN crashes), the configuration file will have been modified, and the next time the user connects the configuration he/she will will be asked to provide a computer administrator's authorization to "secure" the script. In that situation,

Paths: Be sure to specify appropriate paths. The working directory for scripts is /private/var, and the scripts are located in the same folder as the config.ovpn the are used with, so to get the path for config.ovpn you'll have to calculate it from the scripts $0 parameter (which will be a full path, not a relative path).

Please post details of what you end up doing.

On Wednesday, October 17, 2018 at 5:18:26 PM UTC-4, Andrej wrote:

How does Tunnelblick invoke openvpn?  I was wondering whether I could "calculate" the IP tied to the wifi interface and pass it to openvpn with the --local flag from Tunnelblick.

On Wed, Oct 17, 2018 at 2:48 PM tink <> wrote:

[tink]

Thanks for the most helpful response (and the links provided). I like the design and clarity of method 1.

I have read and understood https://tunnelblick.net/cUsingScripts.html ... last piece of the puzzle missing

for me is the "where do I put pre-connect.sh I can't seem to locate it anywhere in the file-system and the

doco doesn't seem to mention its location?

Cheers,

Andrej

--

You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tunnelblick-dis...@googlegroups.com.
Visit this group at https://groups.google.com/group/tunnelblick-discuss.
For more options, visit https://groups.google.com/d/optout.

[Tunnelblick developer]

The scripts go in a "Tunnelblick VPN Configuration"; see  Creating and Installing a Tunnelblick VPN Configuration.

Thanks for the feedback – I'll add a link to it in Using Scripts.

On Wednesday, October 17, 2018 at 7:23:55 PM UTC-4, Andrej wrote:

Thanks for the most helpful response (and the links provided). I like the design and clarity of method 1.

I have read and understood https://tunnelblick.net/cUsingScripts.html ... last piece of the puzzle missing

for me is the "where do I put pre-connect.sh I can't seem to locate it anywhere in the file-system and the

doco doesn't seem to mention its location?

Cheers,

Andrej

[tink]

You're welcome, and we're sorted.  

I have created two subdirs (we have two servers we can connect to):

mkdir ~/confs/{1,2}.tblk 

In {1,2}.conf in the respective subdir I removed "nobind" and replaced it with config /Users/andrej/confs/config2.conf

pre-connect.sh (copied into both directories) looks like so:

#!/bin/bash

addr=$(ipconfig getifaddr $(networksetup -listallhardwareports | awk '/Hardware Port: Wi-Fi/{getline; print $2}'))

if [ ${#addr} -ge 7 ]; then

  echo "local $addr" > /Users/andrej/confs/config2.conf

else

  echo "#NO WiFi active"  > /Users/andrej/confs/config2.conf

fi

chmod 0640 /Users/andrej/confs/config2.conf

Dragged & Dropped those directorier onto Tunnelblick and life is good - I'm using Wifi for VPN =}

Thanks again for your patience and helpfulness - really appreciate it!

Cheers,

Andrej

--

You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tunnelblick-dis...@googlegroups.com.
Visit this group at https://groups.google.com/group/tunnelblick-discuss.
For more options, visit https://groups.google.com/d/optout.

[Andrej]

Help?

My beautiful workaround doesn't work anymore - Tunnelblick 3.8.0 is telling me:

How do I get my functionality back? :/

Cheers,

Andrej

On Thursday, October 18, 2018 at 1:46:20 PM UTC+13, Andrej wrote:

You're welcome, and we're sorted.  

I have created two subdirs (we have two servers we can connect to):

mkdir ~/confs/{1,2}.tblk 

In {1,2}.conf in the respective subdir I removed "nobind" and replaced it with config /Users/andrej/confs/config2.conf

pre-connect.sh (copied into both directories) looks like so:

#!/bin/bash

addr=$(ipconfig getifaddr $(networksetup -listallhardwareports | awk '/Hardware Port: Wi-Fi/{getline; print $2}'))

if [ ${#addr} -ge 7 ]; then

  echo "local $addr" > /Users/andrej/confs/config2.conf

else

  echo "#NO WiFi active"  > /Users/andrej/confs/config2.conf

fi

chmod 0640 /Users/andrej/confs/config2.conf

Dragged & Dropped those directorier onto Tunnelblick and life is good - I'm using Wifi for VPN =}

Thanks again for your patience and helpfulness - really appreciate it!

Cheers,

Andrej

 

The scripts go in a "Tunnelblick VPN Configuration"; see  Creating and Installing a Tunnelblick VPN Configuration.

[Tunnelblick developer]

Hmmm. Good question.

The change (not allowing configuration options in the configuration file) is for security reasons. Tunnelblick needs to know what's in the configuration file, and if it can invoke other configuration files (which can then invoke others…) it can't properly secure everything.

I don't think we're going to revert to allow it, but I will post here in a couple days to let everyone know.

[andrej]

Heh.

Thanks for the fast (although not very favourable) response ... I guess I could ask people not to update their Tunnelblick (or give up on the idea

of having a wired connection while at their desk) ... neither sounds overly desirable, but I can see where you're coming from.

*sigh*

Stuck between a rock and a hard place.

Cheers,

Andrej

--
You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tunnelblick-dis...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/tunnelblick-discuss/1278e822-6239-41e1-9764-6eedcc3b4c2c%40googlegroups.com.

--

Andrej