DNS servers revert after a while (DHCP?)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use an internet connection with DHCP settings.
2. Connect to a VPN server, and leave it on for a while. Tell it to pull DNS 
settings from the 
remote server.
3. Leave your connection online for a while.

What is the expected output? What do you see instead?

After a while, a DHCP update is made on the internet connection which changes 
the DNS server 
settings back to the ISP DNS.

Instead, as long as the connection is up, DNS updates via DHCP should be 
surpressed and 
instead, DNS should be the one via the VPN.

What version of Tunnelblick are you using? On what version of OS X? PPC or 
Intel?

Tunnelblick_3.0b10, intel.

Please provide any additional information below.

Not using the VPN to route Internet traffic, just to route traffic to the 
remote LAN.

Original issue reported on code.google.com by pervonzw...@gmail.com on 15 Dec 2008 at 8:01

[GoogleCodeExporter]

I believe this might be what is happening to me.
On my current internet connections (A DSL modem), I find that my DNS resolution 
for
machines inside the VPN stops working after some arbitrary amount of time.  
Existing
connections are okay, but I have to disconnect and reconnect the VPN in order 
to be
able to create new connections.

Original comment by deinspanjer on 9 Jan 2009 at 4:22

[GoogleCodeExporter]

I've experienced the same issues. However it doesn't seam to affect all users 
I've
had test, I'm trying to investigate if it's a DHCP server issue.

Original comment by jpeterss...@gtempaccount.com on 4 Feb 2009 at 7:09

[GoogleCodeExporter]

I have the same problem. It's only a problem when using the vpn connection on 
the
wireless network on the university and not when I am at home on my own dhcp 
network
(not wireless)

Original comment by powerla...@gmail.com on 10 Feb 2009 at 9:38

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

The same happens for me as well. I'm using 3.0b10.

 Steps to verify:

1. Open a VPN-tunnel
2. Check that the DNS is set to the VPN's DNS
3. Re-new the DHCP lease of your LAN or WLAN connection
4. The DNS has been reset to the ones of the ISP

Original comment by stefan.k...@codearts.com on 11 Feb 2009 at 5:42

[GoogleCodeExporter]

Just adding a /me too. I'm in an environment where DHCP lease time is set to 10
minutes, causing a DNS change after 5 minutes, quite annoying actually :-)

I think it should be noted that this wasn't an issue with 3.0b9 or ealier 
because on
these versions the connection was completely reset (which caused different 
problems).

Would it be possible to still respond to the NetworkDidChange notification, not 
by
resetting the whole connection but only setting DNS (and routes?) once again?

Original comment by michael....@gmail.com on 9 Mar 2009 at 3:48

[GoogleCodeExporter]

I am also having this issue

Original comment by storagen...@gmail.com on 16 Mar 2009 at 8:17

[GoogleCodeExporter]

We are also having this issue, besides putting remote servers in the hosts file 
do we
have an ETA, or a work around for this issue?

Original comment by John.Gra...@gmail.com on 12 Apr 2009 at 10:28

[GoogleCodeExporter]

Same here

Original comment by slackero on 23 Apr 2009 at 12:40

[GoogleCodeExporter]

Is there any update on this defect? 

Original comment by John.Gra...@gmail.com on 22 May 2009 at 3:19

[GoogleCodeExporter]

Issue 68 has been merged into this issue.

Original comment by jkbull...@gmail.com on 8 Jun 2009 at 3:19

[GoogleCodeExporter]

You may want to try the scripts attached to my post.

Those scripts fix this issue on Leopard (Intel, obviously) and Tiger (PPC, at 
least).

Cheers.

Original comment by diego.ri...@rbxglobal.com on 8 Jun 2009 at 5:14

Attachments:

• tunnelblick-dns-dhcp-fix-20090608-01.tar.gz

[GoogleCodeExporter]

Sorry - neglected to mention: just drop the contents of the script, via command 
line,
into /Applications/Tunnelblick.app/Content/Resources (assuming Tunnelblick is
installed in /Applications).

Original comment by diego.ri...@rbxglobal.com on 8 Jun 2009 at 5:15

[GoogleCodeExporter]

Diego's scripts have been added in r94.

Original comment by jkbull...@gmail.com on 19 Jun 2009 at 1:52

• Changed state: Fixed

[GoogleCodeExporter]

I'm getting the same issue with 3.0b26.

Does it require "monitor connection" to be enabled?  I currently have that 
disabled
because of the restart issue with WINS.

Original comment by graeme.o...@googlemail.com on 19 Feb 2010 at 11:10

[GoogleCodeExporter]

I am having a similar, if not the same issue as described in this ticket.  
Basically,
after a certain amount of time my DNS config gets reverted back to the ISP's 
settings
after some seemingly random amount of time (or perhaps something is triggering 
it
from the ISP, not sure).

I am running : 2010-03-16 14:47:30 *Tunnelblick: OS X 10.6.2; Tunnelblick 3.0 
(build
1437); OpenVPN 2.1.1

I have been battle with this issue for pretty much all of the 3.0bXX runs and 
would
love to see it solved.

thanks,
george .

Original comment by garde...@gmail.com on 17 Mar 2010 at 1:47

[GoogleCodeExporter]

What happens when you enable "Monitor connections"?

Original comment by jkbull...@gmail.com on 17 Mar 2010 at 1:51

[GoogleCodeExporter]

When i enable "Monitor connections" i keep getting a message about "WINS
configuration has changed: ..." and the connect constantly disconnects then
reconnects, making the VPN connection unstable.  This could be an issue with my
current network config, i am working on figure this out now.  

thanks for the quick reply,

george .

Original comment by garde...@gmail.com on 17 Mar 2010 at 2:15

[GoogleCodeExporter]

If "Monitor connections" is enabled, Tunnelblick monitors the network interface 
that is used to connect to the 
VPN. If there is a change to the interface (new DNS info from a DPCH renewal, 
for example), Tunnelblick 
forces the VPN connection to be restarted. That is what you need to have 
happen, so the DNS settings will 
return to the settings for the VPN.

However, there are some situations where Tunnelblick restarts the connection 
because it thinks that there was 
a change, but there wasn't one (or at least not the type of change that should 
cause a restart). I think that's 
what is happening to you.

It would be very helpful if you posted the part of your OpenVPN log that shows 
Tunnelblick doing this (one or 
two restart cycles) -- it would help us fix it so Tunnelblick will ignore this 
type of change.

Original comment by jkbull...@gmail.com on 17 Mar 2010 at 2:27

[GoogleCodeExporter]

Hi

I've the same config as gardelea and have the same problem.
Here is a Tunnelblick log that could help.

If you need something else, don't hesitate.

Original comment by olivier....@gmail.com on 26 Mar 2010 at 11:39

Attachments:

• tunnelblick.rtf

[GoogleCodeExporter]

Thanks, Olivier. I'll post here if I get it fixed.

Original comment by jkbull...@gmail.com on 26 Mar 2010 at 9:56

[GoogleCodeExporter]

I'm having the same issue. My local DHCP server provides me with DNS 
information and when starting the tunnel, 
I get this from my OpenVPN server. When my local DHCP lease expires, I get DNS 
information from my local 
DHCP server again. This causes my tunnel to restart (when monitor connection is 
enabled; this causes open 
connections to hosts in my VPN network to be closed) or I loose the lookups to 
VPN network.
Any idea how to solve this?

Original comment by prut...@gmail.com on 4 Apr 2010 at 5:04

[GoogleCodeExporter]

I'm curious -- how often does your ISP renew your DHCP lease?

What's happening is that (outside of Tunnelblick and OpenVPN), something 
changes the network interface. In this 
case, it is a DHCP renewal.

If Tunnelblick and OpenVPN ignore this (which is what happens if "Set 
nameserver" is not checked), your 
computer will not be using the DNS and WINS pushed by the OpenVPN server, so 
the DNS and WINS resolution 
on your computer won't work properly. So that's no good.

If Tunnelblick and OpenVPN restart the connection (which is what they do if 
"Set nameserver" is checked), the 
VPN connections are closed and automatically restarted. That results in 
everything working properly, at the 
expense of the VPN connection being down temporarily. Not great, but it keeps 
things working.

The only other thing that I can think of would be for Tunnelblick to forcibly 
change the DNS and WINS settings 
back to the settings that were in effect just after the VPN was established.

I am uneasy about fiddling with the network settings this way. One problem is 
that traffic after the settings were 
changed by the DHCP renewal and before Tunnelblick can change the settings back 
would be lost and/or 
misdirected. But maybe that's better than requiring a restart.

Does anyone know what happens on Windows in this situation?

Maybe there should be a preference that would enable this behavior?

What do people think?

Original comment by jkbull...@gmail.com on 4 Apr 2010 at 5:40

• Changed state: Accepted

[GoogleCodeExporter]

I definitely think that subtle changes like DNS (or WINS, I guess, if I used 
it) changes should be automatically 
reverted to whatever the OpenVPN server had sent down the pipe when the 
connection was initialized, 
overriding the DHCP-specified ones.  Less subtle changes, such as a different 
IP, should definitely trigger a 
reconnect, but minor stuff like this, yes, please just restore the setting, 
don't reconnect.  

I think your worry about what happens to the traffic in the period between when 
the DHCP renewal happens 
and when the values are restored to the proper VPN settings might be a bit of a 
red herring.  When the renewal 
happens, the traffic is going off that way anyway.  AFAICT, the lag between the 
renewal and Tunnelblick's 
detection of the renewal will be the same, regardless.  The big difference is 
how many more packets will be lost 
between the reset of the VPN options vs the reconnection to the VPN.  I may be 
wrong here, but I'd think it'd be 
quicker to reset to the original VPN settings, thus reducing the number of 
wayward packets.  

I support about 25 - 30 OS X users who mostly use Tunnelblick to connect to our 
OpenVPN server.  It seems 
that a week doesn't go by without at least one person asking me, "Why is 
Tunnelblick so unstable?" or, "Why 
can't it maintain a connection?", especially when we had the DHCP lease 
accidentally set to 20 seconds vs 20 
minutes.  I try to explain to them what's really happening, but they just glaze 
over.  Unfortunately, I don't have 
a very good fix for them, aside from hacking leasewatch or telling them that 
this is the preferred behavior.

I, too, am curious to hear how the Windows GUI, Viscosity, or other OpenVPN 
clients handle this situation.

Original comment by shub...@gmail.com on 19 Apr 2010 at 3:12

[GoogleCodeExporter]

OK, I decided to try this approach.  Here's my patch to leasewatch.  It 
compares the DNS settings after the VPN 
is brought up (DNS_GOOD) to what they are now (DNS_NOW) and to what they were 
before the VPN was 
brought up (DNS_OLD).  If DNS_GOOD and DNS_NOW are not the same, then DNS_NOW 
and DNS_OLD are 
compared.  If they are the same, then it's assumed that a DHCP renew just reset 
the DNS settings and scutil is 
used to restore the DNS_GOOD settings.  If they're different, then a bigger 
change is assumed and SIGUSR1 is 
sent to the OpenVPN process.

There doesn't seem to be a State:/Network/OpenVPN/OldWINS state captured, so I 
couldn't test WINS very 
much.  I did try to make it so that WINS changes are just recovered with 
scutil, much as DNS changes are.  
Only differences in DNS settings can trigger a restart, since I can compare 
DNS_OLD and DNS_NOW.  

I've been using the attached patch for the past few days on my 10.6.3 MBP.  Is 
seems to be working well, but 
I've only really tested DNS performance.  Please consider applying this change 
to the Tunnelblick trunk.  

Any feedback is welcome.

Pete

Original comment by shub...@gmail.com on 25 Apr 2010 at 5:25

Attachments:

• tunnelblick-gracefulreset.patch

[GoogleCodeExporter]

Thanks! I am definitely interested in putting this into the trunk. I have a 
couple of concerns, though:

(1) I think we could have the up scripts save the OldWINS state, too, so it 
could work the same way as DNS. The 
comments seem to indicate it is saved, but the script doesn't seem to actually 
do so.

(2) I think if a DHCP renew also changes the IP address (and/or subnet mask 
and/or gateway), the script with 
your changes might only restore DNS settings, even though a restart of the 
connection is (I think) required. 
Maybe we have to save those settings in the up scripts, too, and test for them?

Original comment by jkbull...@gmail.com on 25 Apr 2010 at 5:53

[GoogleCodeExporter]

I'd be happy to look into getting (1) done, though I'm not sure I can test 
much.  

Saving some of the connection details, such as IP, mask, gw, etc. seems 
reasonable.  I assume that on small-to-
maybe-medium networks at least, DHCP renews tend to help clients keep the same 
IP during a visit and that IP 
changes will mean DNS changes too.  This assumption might not always apply 
though, so recording this info and 
checking would probably cover more possibilities.  I'll look into this too.

Original comment by shub...@gmail.com on 25 Apr 2010 at 6:18

[GoogleCodeExporter]

Please try Tunnelblick 3.1beta18 with a check in the "Monitor connection" 
checkbox.

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

[GoogleCodeExporter]

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

• Changed state: Abandoned

[GoogleCodeExporter]

I have been having this issues as well.
It used to be much worse when I had monitor connections checked (3.1, build 
2190), but ever since unchecking that box, at least my ssh sessions stay alive 
this way.

However, I noticed that my dns settings were being reverted (presumably after 
dhcp renewals).
I see that the beta versions have all been deprecated, so does that mean there 
is not a current version that incorporates just refreshing the DNS entries when 
they are overwritten by local dhcp without restarting the vpn connection? 
Thanks! :)

Original comment by tunnelbl...@herag.com on 12 Dec 2010 at 6:09

[GoogleCodeExporter]

> I have been having this issues as well.

What issue?

Tunnelblick 3.1 is the stable version, and includes everything in the betas.

To restore DNS settings when they are changed by DHCP, you must have "Monitor 
connection" checked. Version 3.1 should restore the settings instead of 
restarting the VPN connection. If it isn't, please post your logs.

Original comment by jkbull...@gmail.com on 12 Dec 2010 at 6:16

[GoogleCodeExporter]

My apologies for not being clear.

I have issues regardless of whether I check "Monitor connector" or not.

If it is unchecked, my ssh sessions stay up, but the DNS gets reset by local 
dhcp renwals and my dns resolving goes away.

If it is checked, then my ssh sessions timeout when tunnelblick detects that my 
dns has changed (presumably by a local dhcp renewal) and resets the vpn 
connection. However, I can continue to resolve dns entries after this event.

Ideally, I would want the ssh stability behavior that unchecking the box 
provides, with the continued dns resolvability that checking the box provides.

I have attached my log detailing this. Line 65 where leasewatch is triggered is 
the point of interest.

Original comment by tunnelbl...@herag.com on 12 Dec 2010 at 7:12

Attachments:

• DNSresetVPN.log

[GoogleCodeExporter]

I see the problem -- the new DNS settings don't match the pre-VPN settings. 
Usually they do, if the DNS change is the result of a DHCP renewal.

The way that the DNS is restored (usually) when a DHCP renewal occurs is that 
"leasewatch", the script that is run when "Monitor connection" is checked, sees 
that a network change has occurred, and that the DNS settings have been changed 
to the way they were before the VPN was established. When the script sees that, 
it restores the DNS settings to the way they were after the VPN was established 
and continues without restarting the VPN.

That usually works fine, but in your case, the DHCP renewal results in 
different DNS settings, settings that have not seen before. The script then 
resets the connection.

The only way around it that I can see is for you to modify the script in your 
copy of Tunnelblick to never reset the VPN, but always just restore the DNS 
settings. That is easy to do. Change line 107 of 
Tunnelblick.app/Contents/Resources/leasewatch
from
        if [ "${DNS_NOW}" = "${DNS_OLD}" ] ; then
to something like:
        if [ "true" ] ; then

I don't know what other side-effects, if any, might occur. The network change 
that the script detects could have changed other things, too, or the network 
settings change could have been the result of something other than a DNS 
renewal, for example, a dropped connection. That might cause the routing that 
was set up by OpenVPN to be discarded, and without restarting the VPN, I don't 
think the network would behave properly after such an event. But you can try 
and play around with it.

Original comment by jkbull...@gmail.com on 12 Dec 2010 at 7:42

[GoogleCodeExporter]

Actually, I guess it should be

        if "true" ; then

Original comment by jkbull...@gmail.com on 12 Dec 2010 at 7:50

[GoogleCodeExporter]

I think the reason the DNS values aren't the same when they come back from the 
DHCP server is because my network tries to do load-balancing on their dns 
servers so no single one gets overloaded. They shuffle their dns entries at 
each dhcp renewal, and that's why things have changed.

This one line fix should be just fine for me, as I can't imagine a situation 
where DNS entry changes alone could warrant a change in the VPN 
connectivity/routing. The VPN's DNS entries should always trump local dhcp dns 
entries.

I do agree though, if there were other changes (like an interface IP change 
upon dhcp renewal, or a routing table change), these should definitely trigger 
VPN resets as the VPN would be inaccessible without/until a reset occurred. I 
don't see leasewatch checking anything other than DNS or WINS entries, so I'm 
not quite sure how it would catch something like an IP or route change. Maybe 
that code is somewhere else.

At just an initial glance, I think the leasewatch script might be overly 
cautious when trying to check for DNS/WINS changes. It might be sufficient to 
just look at the post-VPN connect DNS and monitor that for any changes and 
revert it back to the VPN DNS when that has changed.

Original comment by tunnelbl...@herag.com on 12 Dec 2010 at 10:32

[GoogleCodeExporter]

Yes, the script only checks for DNS and WINS changes.

I think it should also check for IP address changes, and routing or other 
changes, but it doesn't do that. I'd love  help on this from anyone who has 
sufficient expertise and testing facilities -- or different ideas.

Original comment by jkbull...@gmail.com on 12 Dec 2010 at 11:25

[GoogleCodeExporter]

In case it's useful, I've added these changes in as a patch to the current 
(3.1, build 2190) version of leasewatch. I had to disable checking against 
pre-VPN versions of the WINS settings also.

Original comment by tunnelbl...@herag.com on 14 Dec 2010 at 2:26

Attachments:

• leasewatch.patch