Tunnelblick keeps old nameserver

[GoogleCodeExporter]

1. Start a VPN connection with the "set nameserver" toggle activated. 
2. Wait for connection 

The old name server (my router, 192...) is still there as number 0, the new
one as number 1, see scutil trace:
resolver #1
  nameserver[0] : 192.168.2.1
  nameserver[1] : 193.28.153.254
Number 0 is still used for resolving! (This has privacy issues in my case.)

I'm using Tunnelblick-Universal-3.0b6.dmg.asc; OSX 10.4, Intel.

Using the new client.up.osx.sh-script (from the wiki) produced the same
results.

Important: I'm using the "manual" TCP setting in the GUI, giving the
nameserver. If I use DHCP and don't enter a nameserver there, the problem
does not occur.
However, I must use the manual setting...

I tried to get rid of the first nameserver entry using scutil, but didn't
succeed. 

Do you see a solution?

Thank you,

Christian

Original issue reported on code.google.com by christia...@gmail.com on 29 Jul 2008 at 11:18

[GoogleCodeExporter]

Original comment by angelol...@gmail.com on 31 Jul 2008 at 10:38

• Changed state: Accepted

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

A clarification (ask if there are any questions):

When not connected, scutil --dns gives the "manual" dns server, and reading out 
the
dns-server analogue to the client.up.osx.sh gives _no_ dns server.

After connecting, scutil --dns gives the "manual" and pushed dns server, and 
reading
out the dns-server analogue to the client.up.osx.sh gives the pushed dns server.

Trick for checking which dns server is actually used: visite
http://entropy.dns-oarc.net/test/ which is a test site for dns vulnarability. It
automatically determines your dns server (magic, I guess).

Christian

Original comment by christia...@gmail.com on 4 Aug 2008 at 10:28

[GoogleCodeExporter]

Hey,

I have a Problem with Tunnelblick, because mine is doing the exact opposite:
When I connect my VPN w/ the 'set Nameserver' option, it overwrites my 
nameservers
that were set before. Judging from the up script, that's wanted behavior, 
because it
saves them in /tmp.
Obviously, I can live with that, because resolving now works through the remote
nameserver, but I still don't like it, because of 3 reasons:
1) The privacy issues already mentioned by chris.. I dont see, how you can have
privacy issues in your case, maybe you can enlighten me... because now my 
work's DNSd
gets to see all queries I make from here, which I might not want...
2) Performance issues. I don't see why I have to resolve all my domains through 
a
connection that goes half-way across the globe and back, and takes over 200ms 
for
that, when my local dns is just 20ms away. It is enough when I can just use that
resolver for whatever I need resolved within my company.
3) If the remote nameserver is not reachable, has problems or is down for 
whatever
reasons (but the VPN still works) I can't surf anymore. I had that problem 
once, and
it took me quite a while to figure out why.

Case in point, my suggestion is to have the option to 'add' the remote 
nameserver to
the front of the list, instead of replacing the old ones. So if it timeouts, the
default ones can still be used. OSX allows definition of up to 3 default 
nameservers.
Another good idea would be to specify a a search-domain for the VPN connection, 
i.e.
a domain (or domains) that is first resolved by the remote nameserver, and only 
if
that fails by any local/default ones. In my idea I only need the remote NS to 
resolve
the toplevel domains .dev/.sys for me - nothing else (and anything in it even
resolves to the same IP, which never changes.. maybe I should just add an entry 
in my
hosts file, and never worry again).
-V

Original comment by der...@gmail.com on 2 Sep 2008 at 2:07

[GoogleCodeExporter]

A little bit of an update:

I should have read and understood the openvpn options first, before I make
unsolicited comments in here, I am sorry about that.
There is an option, namely 'push dhcp-option DOMAIN <domain>' to set the domain 
of
the remote Nameserver.
But the script that comes with Tunnelblick does not do a good job of setting 
the new DNS.
I found a guy that had the same problems and created a python script for that,
because to get more flixibilty you need to set the settings directly into the
SystemConfiguration DB, looky here:
http://njr.sabi.net/2005/08/04/overriding-dns-for-domains-in-os-x-tiger/

After some frickeling I got that py script to work and used it w/ Tunnelblick, 
and I
think it does what it's supposed to do, i.e. set my DNS to this:

$scutil --dns
DNS configuration

resolver #1
  domain : lm
  search domain[0] : dev
  search domain[1] : sys
  search domain[2] : lm
  nameserver[0] : isp.ns.1
  nameserver[1] : isp.ns.2
  order   : 200000

resolver #2
  domain : .dev
  nameserver[0] : 192.168.0.250
  order   : 100400

resolver #3
  domain : .sys
  nameserver[0] : 192.168.0.250
  order   : 100401

And it also sets the new resolvers into /etc/resolv.conf
Because, turns out that not everyone listens to the SCInfoDB, if you try your 
shell,
only ping does, nslookup, dig and host only look in resolv.conf.
Only problem is, that it relies on the primary DNS to not being able to resolve 
the
names that we want to resolve, I think, timeout or return an error. Then it 
switches
over to the secondary DNS and resolves correctly. Maybe it would help to take 
search
domain[0] and search-domain[1] from my resolver#1, who knows. Acording to a 
developer
at Apple (ref. Mailinglist) search-domain entries in primary resolver entries 
are
ignored, anyway, so it might not.

Sadly enough, my ISP's NS is happy to resolve any domains it does not know to a 
def
IP and give me a page with lots of Homepage suggestions... you might know which 
ISP
I'm on... so the above configuration (and the python script) still doesn't work 
for me :(

Original comment by der...@gmail.com on 3 Sep 2008 at 6:21

[GoogleCodeExporter]

Hi derDoc!

Concerning 1) of your Sep 05 post (privacy issue): I use Tunnelblick to connect 
to a
provider who does not log my surfing behaviour. This lets me surf with peace of 
mind,
for example when looking up health information or tax stuff.

Did I understand correctly, that in the URL you gave above, the author states 
that
using scutil is superior/more elegant than using his script?

Greetings,

Christian

Original comment by christia...@gmail.com on 7 Sep 2008 at 9:53

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I experienced that tunnelblick was not setting the remote nameservers at all.
Here is what I had to change.

The first change is just removing two spaces around the equal sign, I don't 
know why,
but it points out working on OS X Tiger.

The 2nd change is more obvious, imagine we have two nameservers set by OpenVPN, 
we
need to pass both two scutil. This is achieved by using the complete content of 
the
shell array $vDNS by using ${vDNS[@]}. See 
http://tldp.org/LDP/abs/html/arrays.html
for more details. 

Please find the attached file below.

Kind regards
Thomas Reifferscheid

Original comment by thomas.r...@googlemail.com on 1 Oct 2008 at 8:40

Attachments:

• client.up.osx.sh.diff

[GoogleCodeExporter]

--- client.up.osx.sh    2008-07-24 22:06:25.000000000 +0200
+++ client.up.osx.sh    2008-10-01 10:34:07.000000000 +0200
@@ -20,7 +20,7 @@
 unset vOptions

 # This starts as 1 and enters the loop
-while vForOptions = foreign_option_${nOptionIndex};    [ -n "${!vForOptions}" 
]; 
+while vForOptions=foreign_option_${nOptionIndex}; [ -n "${!vForOptions}" ]; 
 do
        {

@@ -104,7 +104,7 @@
 scutil << EOF
 open
 d.init
-d.add ServerAddresses * $vDNS
+d.add ServerAddresses * ${vDNS[@]}
 d.add DomainName $domain
 set State:/Network/Service/${PSID}/DNS
 quit

Original comment by thomas.r...@googlemail.com on 1 Oct 2008 at 8:42

[GoogleCodeExporter]

I was also experiencing issues where the name servers would not be set 
correctly in
osx 10.5.5 - applying Thomas' patch solved the problem - thanks Thomas :-)

Original comment by marcgads...@gmail.com on 20 Oct 2008 at 3:26

[GoogleCodeExporter]

Passing the complete shell array, as shown in the diff, does not work for me, I 
don't
get a connection any more.

Original comment by christia...@gmail.com on 21 Oct 2008 at 10:15

[GoogleCodeExporter]

Christian: Please step more into detail, what version of tunnelblick, OSX, 
bash/shell
are you using? Can you *repeat* the behaviour even after a reboot of your 
system?

My guess is, that while playing around with the patch you or the logoff script 
was
removing all nameservers from your system, which in return makes your system 
pretty
clueless when connecting to a remote host starting with resolving the hostname.

-- 
reiffert
Contact me on #openvpn@freenode

Original comment by thomas.r...@googlemail.com on 22 Oct 2008 at 6:00

[GoogleCodeExporter]

Thomas:

Talking about the original issue 8, yes, I can repeat it every time.

Talking about comment 12, reverting the div gave me connections again, so no 
trouble
there.

My Specs: OSX 10.4.11, Tunnelblick 3.06b. Shell: Terminal-window says Bash.

Original comment by christia...@gmail.com on 22 Oct 2008 at 8:14

[GoogleCodeExporter]

Please update to the latest Tunnelblick 3.09b. After that please apply my patch 
to
client.up.osx.sh which lives in /Applications/Tunnelblick/Contents/Resources/

After that please run the following code in Terminal.app (bash), 
then connect to a remote vpn site and run the code again:

-- the code as follows: --

date

PSID=$( (scutil | grep PrimaryService | sed -e 's/.*PrimaryService : //')<< EOF
open
get State:/Network/Global/IPv4
d.show
quit
EOF
)

OLDDNS1=$( (scutil | grep '0 : ' | sed -e 's/\ *0 : //')<< EOF
open
get State:/Network/Service/${PSID}/DNS
d.show
quit
EOF
)

OLDDNS2=$( (scutil | grep '1 : ' | sed -e 's/\ *1 : //')<< EOF
open
get State:/Network/Service/${PSID}/DNS
d.show
quit
EOF
)

echo $OLDDNS1
echo $OLDDNS2

-- code end --

Please paste the output of Tunnelblick -> Details for your connection attempt 
as well.

Original comment by thomas.r...@googlemail.com on 24 Oct 2008 at 12:04

[GoogleCodeExporter]

I was having an issue where my OpenVPN DNS servers were not listed by 'scutil' 
but
after applying Thomas' patch in number 10 solved the problem for me, thanks 
very much
Thomas! :)

Original comment by chris.j....@gmail.com on 10 Nov 2008 at 10:25

[GoogleCodeExporter]

Hi Thomas,

I am still with version 3.06b, as the 09 seems to have so many bugs.

So, I (manually) applied the patch, but the script exits with error 2 (after the
connection is established), perhaps there is a incompatibility between the 2 
script
versions.

Also, I encountered a problem running the script in number 15, it says
"test_for_thomas.sh: command substitution: line 1: syntax error near unexpected 
token
`S'OFtowNetwork/Global/IPv4", which looks like a problem with the grep (running
scutil manually works).

A question: even if the patch worked, I guess it would not solve my problem, 
since it
would only ensure to pass a second nameserver if given. But would not eliminate 
the
"stealth" nameserver (manual TCP setting) in the system.

Sorry for taking so long to check this issue...

Christian

Original comment by christia...@gmail.com on 19 Nov 2008 at 11:26

[GoogleCodeExporter]

I have a similar problem.  NS[0] is my ISP NS[1] is my company internal 
nameserver.
As far as I can tell NS[1] is never questioned.

scutil --dns

DNS configuration

resolver #1
  domain : companydomain.local
  nameserver[0] : 198.60.22.2
  nameserver[1] : 10.1.1.18
  order   : 200000

resolver #2
  domain : companydomain.local
  nameserver[0] : 198.60.22.2
  nameserver[1] : 10.1.1.18
  order   : 200000

Original comment by sjbrow...@gmail.com on 4 Mar 2009 at 7:49

[GoogleCodeExporter]

This behavior is due to how Leopard/Tiger handles the DNS settings. In 
Leopard/Tiger
 if you configure manual DNS and then connect to a VPN server which provides
additional nameserver configurations, the O/S will aggregate those 
configurations
giving priority (i.e. listing higher on the list) those manually-configured DNS 
settings.

Sadly, this is inevitable and is done by the O/S itself, not by tunnelblick.  
This
behavior has been removed in Snow Leopard.  Now, in SL, if you set up manual
configurations, those are the only ones used.

This is an O/S "feature", and unfortunately there appears to be nothing we can 
do in
tunnelblick to fix the behavior without a sizeable risk of breaking the 
computer's
configuration altogether.

Original comment by diego.ri...@rbxglobal.com on 4 Oct 2009 at 11:58

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Original problem fixed in 3.0b10

Original comment by jkbull...@gmail.com on 4 Jun 2010 at 4:30

• Changed state: ThinkItsFixed

[GoogleCodeExporter]

I'm still seeing this problem in the latest version 3.0 (build 1437).  I can 
use nslookup to get dns results from my vpn's dns servers, but the remainder of 
my applications can not, including ssh and ping.   I used to be able to kill 
mDNSResponder and it would updated the server list, but this no longer works.

  System Version:   Mac OS X 10.6.4 (10F569)
  Kernel Version:   Darwin 10.4.0

Any ideas?

Original comment by joeldjoh...@gmail.com on 7 Jul 2010 at 6:23

[GoogleCodeExporter]

Just to be sure: you are not using any manual network settings, right? If you 
are, they take priority and are supposed to override anything else.

Perhaps this is a problem with DNS entries being cached. Try (on Snow Leopard) 
using the

  dscacheutil -flushcache

command after connecting.

Original comment by jkbull...@gmail.com on 7 Jul 2010 at 6:38

[GoogleCodeExporter]

r929, incorporated into Tunnelblick 3.1beta08 (2010-07-10) flushes the DNS 
cache after a tunnel is established and after it is torn down.

This is enabled by default but may be disabled by the per-connection 
"-doNotFlushCache" preference.

Original comment by jkbull...@gmail.com on 18 Sep 2010 at 9:00

• Changed state: Fixed

[GoogleCodeExporter]

Hi guys, 

I was using happily Tunnelblick until I started to play with dns. Indeed, i"ve 
got this strange behaviour with build 2132:

- i've got a connection from my dhcp server with dns and so on, with a correct 
resolv.conf
- i connect to my openvpn server which pushes dns configuration, i get the new 
one in scutil and not in resolv.conf (quite annoying for ping ssh etc..)
- I disconnect, my old dns settings are not restored whereas they appear in 
scutil list

I've tried with check connection checked and the 3 options to set the 
nameserver.

Does anyone could help ?
Thanks in advance.

Original comment by joseph.p...@gmail.com on 30 Nov 2010 at 1:15

[GoogleCodeExporter]

OS X 10.6?

This doesn't happen to me (OS X 10.6.5,  Tunnelblick 3.1.b20 (build 2132), 
using "Set nameserver", no "XYZ-doNotFlushCache" preference).

It sounds like an OS X problem -- Tunnelblick uses scutil to set DNS, and 
scutil should recreate /etc/resolv.conf. Maybe you should reapply 10.6.5 (or 
whatever you have) using the combo updater.

Otherwise, I suggest that you ask about this on the discussion group 
(http://groups.google.com/group/tunnelblick-discuss). Maybe other people are 
having the same problem.

Original comment by jkbull...@gmail.com on 1 Dec 2010 at 2:32