TunnelBlick DNS and Tap Strangeness with Yosemite

[ttech]

Hello,

Here is my connection log: https://gist.github.com/Ttech/40055fcd71b2569942a2

I recently upgraded to Yosemite and I've noticed some strange behavior when connecting to various OpenVPN Servers. 

When connecting, DNS is updated to the proper internal DNS servers and nslookup, host, and dig work as expected.

However ping, curl, Firefox, Chrome, etc don't resolve the addresses on the internal DNS server(s).  

On connecting I've run `sudo discoveryutil udnsflushcaches &&dscacheutil -flushcache;sudo killall -HUP mDNSResponder`. 

Since these appear to be the various means of clearing DNS caching in different versions of OS X.  However, the addresses

still do not resolve properly. In Network Settings, the DNS field is updated with the proper values as well. 

I'm a bit perplexed by the fact that tools relying on /etc/resolv.conf work, but tools using getaddressinfo and friends fail since 

they all are set using the same tools. Additionally, these worked before Yosemite. I was hoping someone could shed some light

onto this is not working, its made it a bit of a pain to use VPNs right now.

On a side note, using a tap interface on a network that has IPv6 the addresses handed out to client do not appear to be assigned 

to the system. Using Wireshark I can see the router advertisements being received, but no action  seems to be taken to get an address

from the VPN link. 

Thanks!

[jkbull...gmail.com]

Instead of posting the log, please follow the instructions at Read Before You Post.

[tt...@mostlynothing.info]

Sorry about that. I've the snippet with the debug log removing addresses. 

(The connection works fine and disconnects fine aside from DNS and IPv6.)

[jkbull...gmail.com]

Several comments:

1. You probably don't want to be running the MTU test while you are trying to use the VPN:

2014-11-18 15:01:20 NOTE: Beginning empirical MTU test -- results should be available in 3 to 4 minutes.

(Un-check the "Run MTU maximum size test after connecting" checkbox on the "While Connected" tab of the "Advanced" settings window.)

2. There seems to be some kind of routing setup error:

route: writing to routing socket: File exists

add net 192.168.10.0: gateway 192.168.10.1: File exists

(That's an OpenVPN configuration issue.)

3. Some of the command line utilities do not use the same domain name resolution as most of OS X -- "nslookup" for example. So DNS is not being set up properly if nslookup works but Chrome doesn't. If nslookup works, it may or may not mean that DNS is set up properly.

I have emailed tt…@gmail.com privately with a link to a "snapshot" (pre-release version of Tunnelblick) which does additional DNS cache flushing.

[dki...@marketlive.com]

Was there a resolution to this issue.  I'm having the same symptoms, I connect to VPN just fine and nslookup on a valid name resolves to the correct IP but ssh, chrome, etc, all come back with DNS resolution errors for the same name.  I'm running Yosemite and have tried both tunnelblick 3.4.3 and 3.5beta06.

[Daniel Kinon]

Not completely clear at this point whether I was having the exact same issue listed in this thread but the symptoms seemed to be the same.

As of OSX Yosemite (and iOS 8.1), Apple has changed the way it resolves *.local domains.  According to RFC 6762 the *.local domain is reserved for multicast DNS resolution.  In previous version of OSX this RFC wasn't adhered to strictly but that has changed in OSX Yosemite (10.10) which now routes *.local exclusively to mDNSresponder which is primarily used by multicast services like Bonjour.  This namespace my VPN was attempting to route had a *.local name root.  To reproduce this issue: configure VPN to handle a *.local namespace, establish a VPN connection, run nslookup on a known good *.local name and you will retrieve the correct IP, then try to connect to a known good *.local name via ssh or web browser and you will receive a DNS resolution error.

This change flies in the face of ActiveDirectory which has been using *.local name resolution going on 2 decades.  It is perhaps for this enterprise compatibility reason only that Apple provides a work around by enabling the mdnsactivedirectory option in the discoveryutil service.  Here is the full thread on apple support.

To enable this option immediately run the following command: 

$ sudo discoveryutil mdnsactivedirectory yes

To enable this option permanently (during boot), one of the thread posts provided a plist file to drop in /Library/LaunchDaemons/ : https://gist.github.com/CodingMinds/509bd12a7c7e22f0cfdd

Hope this helps, this was definitely one of the more obscure issues I've run into.

--
You received this message because you are subscribed to a topic in the Google Groups "tunnelblick-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tunnelblick-discuss/Or7fe4ng71w/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tunnelblick-dis...@googlegroups.com.
Visit this group at http://groups.google.com/group/tunnelblick-discuss.
For more options, visit https://groups.google.com/d/optout.

[ad...@lau.net.au]

Helped me out Daniel, just wished I found your answer 4 hours ago!

To unsubscribe from this group and all its topics, send an email to tunnelblick-discuss+unsub...@googlegroups.com.