Set/Accept multiple Search Domains

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Set multiple push statements:
push "dhcp-option DOMAIN example0.com"
push "dhcp-option DOMAIN example1.com"
push "dhcp-option DOMAIN example2.com"
2. Connect client to server.

What is the expected output?
Multiple search domains, which OS X supports and so does scutil

What do you see instead?
The last dhcp-option DOMAIN is actually set, so in this case I would only 
have one search domain and it would be example2.com

What version of Tunnelblick are you using? On what version of OS X? PPC or
Intel?
OS X 10.6.2; Tunnelblick 3.0b26 (build 1395); OpenVPN 2.1.1

Please provide any additional information below. It is often helpful to
include your configuration file and the contents of the OpenVPN Log 
window,
but remember to remove any sensitive information such as IP addresses

Just the standard config. All the connections work properly it would be nice 
however to be able to set multiple search domains. Which on windows 
works.

Original issue reported on code.google.com by bretep on 11 Feb 2010 at 6:38

[GoogleCodeExporter]

Issue 146 has been merged into this issue.

Original comment by jkbull...@gmail.com on 2 Sep 2010 at 1:03

[GoogleCodeExporter]

Please try using "Set nameserver (alternate 1)" in Tunnelblick 3.1beta18.

Original comment by jkbull...@gmail.com on 18 Oct 2010 at 10:18

[GoogleCodeExporter]

Original comment by jkbull...@gmail.com on 31 Oct 2010 at 12:42

• Changed state: Abandoned

[GoogleCodeExporter]

I have this problem too & have been trying to find a workaround in order to 
keep my search domain on LAN as well as add the search domain for VPN...

Original comment by Still...@gmail.com on 13 Mar 2011 at 5:20

[GoogleCodeExporter]

@Still...@gmail.com:

And "Set nameserver (alternate 1)" doesn't help?

Original comment by jkbull...@gmail.com on 13 Mar 2011 at 8:31

• Changed state: New

[GoogleCodeExporter]

Original comment by jkbull...@gmail.com on 2 Apr 2011 at 6:58

• Changed state: Abandoned

[GoogleCodeExporter]

I also encountered the same problem. Looking inside client.3.up.tunnelblick.sh 
script (which is executed when using "Set nameserver (alternate 1)") seems that 
the problem resides in the logic handling the push "dhcp-option DOMAIN" (line 
105). It's being considered as a single value when it should be considered as a 
multiple value (like the DNS parameter). 

I have modified the script and now it seems to work fine. However this has been 
a very quick fix and I am far from an expert regarding this kind of scripts. 
Maybe one of the team members could check if its all right. 

Regards

Original comment by david.ba...@gmail.com on 12 Oct 2011 at 12:09

Attachments:

• client.3.up.tunnelblick.sh

[GoogleCodeExporter]

This would be great if we could get this into the next release :)
Just tested with the latest beta and is still just takes the last domain you 
specify and throws the others away.

Original comment by ea...@tubemogul.com on 31 Aug 2012 at 5:13

[GoogleCodeExporter]

This was added in Tunnelblick 3.3beta18 on 2012-08-04:

"Adds a new checkbox on the 'Advanced' settings page that tells Tunnelblick to 
add the domain name provided by OpenVPN to the start of the list of search 
domains. This checkbox is disabled and unchecked unless the DNS/WINS setting is 
set to 'Set nameserver'. Adding the domain name does not take place if the 
search domains are manually set."

If it isn't working for you, please post your configuration file and the full 
Tunnelblick log.

Original comment by jkbull...@gmail.com on 2 Sep 2012 at 5:44

• Changed state: Fixed

[GoogleCodeExporter]

Still not working as expected.

After downloading and installing the 3.3beta20 (build 3105), I configured the 
connection as stated in the previous comment, still having the same issue. The 
VPN server sends three different dhcp-option DOMAIN lines and only the last one 
is used (connection log attached).

As I did before (see my previous comment,  number 7), I took a look at the  
client.up.tunneblick.sh script and found the same thing: DOMAIN options are not 
stored in an array (lines 822 to 842):

    while vForOptions=foreign_option_$nOptionIndex; [ -n "${!vForOptions}" ]; do
        vOptions[nOptionIndex-1]=${!vForOptions}
        case ${vOptions[nOptionIndex-1]} in
            *DOMAIN* )
                sDomainName="$(trim "${vOptions[nOptionIndex-1]//dhcp-option DOMAIN /}")"
                ;;
            *DNS*    )
                aNameServers[nNameServerIndex-1]="$(trim "${vOptions[nOptionIndex-1]//dhcp-option DNS /}")"
                let nNameServerIndex++
                ;;
            *WINS*   )
                aWinsServers[nWinsServerIndex-1]="$(trim "${vOptions[nOptionIndex-1]//dhcp-option WINS /}")"
                let nWinsServerIndex++
                ;;
            *   )
                logMessage "Unknown: 'foreign_option_${nOptionIndex}' = '${vOptions[nOptionIndex-1]}' ignored"
                ;;
        esac
        let nOptionIndex++
    done

Therefore only the value in the last option is used. IMHO A code similar to the 
one I posted (in October 2011) should fix the issue, however I might be wrong 
given I'm not an expert in bash scripting. 

Regards.

Original comment by david.ba...@gmail.com on 3 Sep 2012 at 10:10

Attachments:

• tunnelblick.log

[GoogleCodeExporter]

I apologize. I was referring to a different problem with search domains.

Original comment by jkbull...@gmail.com on 4 Sep 2012 at 12:57

• Changed state: Accepted

[GoogleCodeExporter]

should be a pretty straight forward patch, no?... could we get that on next 
version? If you're too busy, I could try my hand at putting this change in?

Original comment by ea...@tubemogul.com on 4 Sep 2012 at 1:22

[GoogleCodeExporter]

It does look straightforward, but it needs to be applied to
client.up.tunnelblick.net, which is the default up script.

The purpose of the other scripts is for backward compatibility, so I do not
want to change client.3.up.tunnelblick.net, for example, (because that
defeats the purpose of the backward compatibility).

I try to be very careful about changing these scripts, because they run as
root and are used by so many people.

It would be great if you could create a new patch based on
client.up.tunnelblick.net. If I am able to really look at it and test it
out thoroughly I would put it into the next beta release, which I hope to
have out soon (either in the next few days or in a couple of weeks; it
depends on some other changes being ready).

Original comment by jkbull...@gmail.com on 4 Sep 2012 at 1:40

[GoogleCodeExporter]

I agree. In 2011 I made the fix in client.3.up.tunnelblick.net because it was 
the configuration I was using and I was not sure myself about which script 
should be fixed

As soon as I have some spare time I'll fix the client.up.tunnelblick.net  and 
send you the patch for testing.

Original comment by david.ba...@gmail.com on 4 Sep 2012 at 2:02

[GoogleCodeExporter]

That would be great!

Original comment by jkbull...@gmail.com on 4 Sep 2012 at 2:04

[GoogleCodeExporter]

Seems that I am not gonna make it. Not confident enough in the changes I made. 
Not sure about how the script should handle the different cases (also not sure 
about how many different cases there are) ^_^U

I have been digging into the script and there were several changes to be made. 
Detection of multiple push DOMAIN was easy to accomplish, however deciding what 
to do with the domains was not.

Current version of the script took one DOMAIN and set it, leave it, append it 
or prepended based on the current configuration, the configuration the user set 
manually, the OS version and the new "Prepend domain option". 

Currently I am a little confused about how the multiple domain should be 
treated. This is a very big script with tons of vars and I have the feeling 
that some of the logic is not needed. The different CUR_ and MAN_ vars confuse 
me. At first glance one would say that checking the current config is all that 
is needed, but what happens when the user has several simultaneos vpn sessions 
opened. Also the different behaviour between OS versions seems so arbitrary and 
needless. 

Maybe I am missing something (I am missing something for sure) cause as I 
stated before, I am not a Bash scripting expert and do not really know all the 
corner cases the script has to handle,  ^_^

So, I am only able to deliver a half assed script. Therefore I prefer not to 
deliver it.

My apologies :(

Original comment by david.ba...@gmail.com on 6 Sep 2012 at 8:17

[GoogleCodeExporter]

David, thank you very much for trying, and for articulating the complexity of 
the scripts.

Here are my comments; they may help anyone else looking at this script:

What to do with multiple domains: I think multiple domains should be treated 
the same as a single domain, either set (if there is no current domain), 
appended, prepended, or ignored (if there is a manual domain setting).

The CUR_xxx, MAN_xxx variables: The CUR_xxx variables contain the current 
network setting and the MAN_xxx contains the network settings that were set 
manually. The reason for having both is that as a general rule -- almost a 
philosophy -- we don't modify anything that was set manually. By having both we 
can see whether a particular setting was set manually or not.

Simultaneous VPN sessions: None of the Tunnelblick scripts work with that 
situation, as far as I know. The script for the second configuration to be 
connected would overwrite the variables stored by the script for the first 
configuration. I think each multi-VPN situation needs to be scripted by whoever 
sets up the VPN. (Again, as far as I know. Maybe there are some situations 
where the standard script works.)

The different behavior between OS versions is arbitrary and capricious because 
the different OS X versions are arbitrary and capricious. The goal is to handle 
OpenVPN VPN sessions the same way that OS X handles built-in VPN sessions like 
PPTP. Since OS X changed its behavior with the OS version, the script changes 
its behavior with the OS version.

Again, thanks David for looking into this.

Original comment by jkbull...@gmail.com on 6 Sep 2012 at 11:22

[GoogleCodeExporter]

i've the same trouble with multiple search domain.
so i'm waiting beta with this update. thanks

Original comment by a...@romanov.ws on 6 Oct 2012 at 7:51

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I have a question, related to a question I just asked on Issue 220 [1]:

     Why is "DOMAIN" being treated as a search domain?

OS X seems to have two different DNS parameters: a single "domain", and a set 
of zero or more "search domains". The existing Tunnelblick scripts seem to use 
"DOMAIN" for both.

Should the scripts be changed so that

* "SEARCH-DOMAIN" is a set of zero or more entries that are to be stored as OS 
X "search domains"; and
* "DOMAIN" is used (A) as the "domain" and (B) if no SEARCH-DOMAIN are 
specified, as the "search domain"?

This would be downward-compatible (I think) but would allow setting of an 
arbitrary list of search domains.

* The DOMAIN would replace any existing domain unless a domain is manually set.

* The SEARCH-DOMAINs would be set, appended, prepended, or ignored, just like 
DNS or WINS servers.

* Multiple "DOMAIN" entries would cause a warning to be put in the log and
  (A) Be ignored; or
  (B) Be treated as if they were "SEARCH-DOMAIN"

[1] http://code.google.com/p/tunnelblick/issues/detail?id=220

Original comment by jkbull...@gmail.com on 19 Feb 2013 at 6:57

[GoogleCodeExporter]

In my previous comment, "SEARCH-DOMAIN" should be "DOMAIN-SEARCH", sorry.

Original comment by jkbull...@gmail.com on 20 Feb 2013 at 4:05

[GoogleCodeExporter]

I believe multiple DOMAIN entries is non-standard and the client behavior is 
undefined; I think using DOMAIN-SEARCH is the better option.

FYI, OpenVPN on Windows behaves the same way (only the last DOMAIN is used), 
and Linux w/NetworkManager is the opposite (only uses the _first_ DOMAIN).  
Connecting from cmdline and using the update-resolv-conf script does add all of 
them to the search list, but that's to be expected since it just loops through 
the DHCP options.

Original comment by andrew.d...@gmail.com on 13 Mar 2013 at 8:43

[GoogleCodeExporter]

Agreed, Domain-Search would totally work for out needs!

Original comment by ea...@tubemogul.com on 13 Mar 2013 at 8:47

[GoogleCodeExporter]

Tunnelblick 3.3beta34 includes the following changes, which I think should 
close this Issue and Issue 220:

   * Multiple "DOMAIN-SEARCH" entries are allowed, and are set, prepended, or ignored, like DNS or WINS servers.

   * "DOMAIN" is used (A) as the "domain" and (B) if no DOMAIN-SEARCH entries are specified, as the "search domain"

   * Only the last "DOMAIN" entry is used (like Windows)

(But I'll leave this Issue and Issue 220 open for a while.)

Original comment by jkbull...@gmail.com on 27 Mar 2013 at 10:54

[GoogleCodeExporter]

Original comment by jkbull...@gmail.com on 10 Apr 2013 at 6:41

• Changed state: Fixed