os x Yosemite - 10.10.5 (14F27) - do not send DNS lookups

[gregory.k...@team.wrike.com]

Hi All. I have a problem with openvpn - tunnelblick on os X, after sucessfull connection via openvpn, TCP/UDP/ICMP traffics goes without problem if I use ip_addr. OpenVPN server push via DHCP options corporate DNS server, direct lookups via dig tool works fine but if I use Web browser or command line tools like ssh or ping - `Could not resolve hostname` error appears. Wireshark shoes that there is no DNS lookup queries in moments when I have error, looks like this is some mac os related specific may be some bug.

If I use public DNS servers like Google or dynamic_dns there is no such problem with name resolving.

OS: Mac os X 10.10.5

OpenVPN client: Tunnelblick 3.6beta10 (build 4400) and Tunnelblick 3.5.4

OpenVPN server: 2.3.6 Centos7 and Centos6

Thanks in advance

[jkbull...gmail.com]

Please follow the instructions at Read Before You Post.

[gregory.k...@team.wrike.com]

Thanks, just done all steps from instruction.

Heres is connection log(Diagnostic):

Gist

2015-10-10 16:46:50 *Tunnelblick: OS X 10.10.5; Tunnelblick 3.6beta10 (build 4400); prior version 3.5.4 (build 4270.4395)

2015-10-10 16:46:51 *Tunnelblick: Attempting connection with xxx-spb using shadow copy; Set nameserver = 1; monitoring connection

2015-10-10 16:46:51 *Tunnelblick: openvpnstart start xxx-spb.tblk 1337 1 0 1 0 541042 -ptADGNWradsgnw 2.3.7

2015-10-10 16:46:52 *Tunnelblick: openvpnstart log:

     Loading tap-signed.kext

     OpenVPN started successfully. Command used to start OpenVPN (one argument per displayed line):

     

          /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.7/openvpn

          --daemon

          --log

          /Library/Application Support/Tunnelblick/Logs/-SUsers-Sgkomissarov-SLibrary-SApplication Support-STunnelblick-SConfigurations-Sxxx--spb.tblk-SContents-SResources-Sconfig.ovpn.1_0_1_0_541042.1337.openvpn.log

          --cd

          /Library/Application Support/Tunnelblick/Users/gkomissarov/xxx-spb.tblk/Contents/Resources

          --verb

          3

          --config

          /Library/Application Support/Tunnelblick/Users/gkomissarov/xxx-spb.tblk/Contents/Resources/config.ovpn

          --cd

          /Library/Application Support/Tunnelblick/Users/gkomissarov/xxx-spb.tblk/Contents/Resources

          --management

          127.0.0.1

          1337

          --management-query-passwords

          --management-hold

          --script-security

          2

          --up

          /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -9 -a -d -f -m -w -ptADGNWradsgnw

          --down

          /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -9 -a -d -f -m -w -ptADGNWradsgnw

          --route-pre-down

          /Applications/Tunnelblick.app/Contents/Resources/client.route-pre-down.tunnelblick.sh -9 -a -d -f -m -w -ptADGNWradsgnw

2015-10-10 16:46:51 OpenVPN 2.3.7 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [PKCS11] [MH] [IPv6] built on Sep 23 2015

2015-10-10 16:46:51 library versions: OpenSSL 1.0.2d 9 Jul 2015, LZO 2.09

2015-10-10 16:46:51 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:1337

2015-10-10 16:46:51 Need hold release from management interface, waiting...

2015-10-10 16:46:51 *Tunnelblick: openvpnstart starting OpenVPN

2015-10-10 16:46:52 *Tunnelblick: Established communication with OpenVPN

2015-10-10 16:46:52 *Tunnelblick: Obtained VPN username and password from the Keychain

2015-10-10 16:46:52 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:1337

2015-10-10 16:46:52 MANAGEMENT: CMD 'pid'

2015-10-10 16:46:52 MANAGEMENT: CMD 'state on'

2015-10-10 16:46:52 MANAGEMENT: CMD 'state'

2015-10-10 16:46:52 MANAGEMENT: CMD 'bytecount 1'

2015-10-10 16:46:52 MANAGEMENT: CMD 'hold release'

2015-10-10 16:46:52 MANAGEMENT: CMD 'username "Auth" "xxx.yyy"'

2015-10-10 16:46:52 MANAGEMENT: CMD 'password [...]'

2015-10-10 16:46:52 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2015-10-10 16:46:52 Socket Buffers: R=[196724->65536] S=[9216->65536]

2015-10-10 16:46:52 MANAGEMENT: >STATE:1444484812,RESOLVE,,,

2015-10-10 16:46:52 UDPv4 link local: [undef]

2015-10-10 16:46:52 UDPv4 link remote: [AF_INET]w.x.y.z:5511

2015-10-10 16:46:52 MANAGEMENT: >STATE:1444484812,WAIT,,,

2015-10-10 16:46:52 MANAGEMENT: >STATE:1444484812,AUTH,,,

2015-10-10 16:46:52 TLS: Initial packet from [AF_INET]w.x.y.z:5511, sid=ec458d86 98a6ef5c

2015-10-10 16:46:52 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this

2015-10-10 16:46:52 VERIFY OK: depth=1, C=US, ST=CA, L=San Jose, O=xxx Inc., OU=EastDC, CN=xxx Inc. CA, name=EasyRSA, emailAddress=n...@team.xxx.com

2015-10-10 16:46:52 VERIFY OK: nsCertType=SERVER

2015-10-10 16:46:52 VERIFY OK: depth=0, C=US, ST=CA, L=San Jose, O=xxx Inc., OU=EastDC, CN=spb-admins, name=EasyRSA, emailAddress=n...@team.xxx.com

2015-10-10 16:46:52 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key

2015-10-10 16:46:52 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

2015-10-10 16:46:52 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key

2015-10-10 16:46:52 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

2015-10-10 16:46:52 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA

2015-10-10 16:46:52 [spb-admins] Peer Connection Initiated with [AF_INET]w.x.y.z:5511

2015-10-10 16:46:53 MANAGEMENT: >STATE:1444484813,GET_CONFIG,,,

2015-10-10 16:46:54 SENT CONTROL [spb-admins]: 'PUSH_REQUEST' (status=1)

2015-10-10 16:46:54 PUSH: Received control message: 'PUSH_REPLY,route 192.168.2.0 255.255.255.0,route 50.117.24.96 255.255.255.224,route 69.46.91.194 255.255.255.255,route 69.46.91.197 255.255.255.255,route 70.33.176.0 255.255.255.224,route 80.254.60.0 255.255.255.240,dhcp-option DNS 172.16.1.1,dhcp-option DNS 8.8.8.8,dhcp-option DOMAIN .,route-gateway 172.16.1.1,ifconfig 172.16.1.9 255.255.255.0'

2015-10-10 16:46:54 OPTIONS IMPORT: --ifconfig/up options modified

2015-10-10 16:46:54 OPTIONS IMPORT: route options modified

2015-10-10 16:46:54 OPTIONS IMPORT: route-related options modified

2015-10-10 16:46:54 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified

2015-10-10 16:46:54 TUN/TAP device /dev/tap0 opened

2015-10-10 16:46:54 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0

2015-10-10 16:46:54 MANAGEMENT: >STATE:1444484814,ASSIGN_IP,,172.16.1.9,

2015-10-10 16:46:54 /sbin/ifconfig tap0 delete

                                        ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address

2015-10-10 16:46:54 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure

2015-10-10 16:46:54 /sbin/ifconfig tap0 172.16.1.9 netmask 255.255.255.0 mtu 1500 up

2015-10-10 16:46:54 /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -9 -a -d -f -m -w -ptADGNWradsgnw tap0 1500 1574 172.16.1.9 255.255.255.0 init

                                        **********************************************

                                        Start of output from client.up.tunnelblick.sh

                                        Configuring tap DNS via OpenVPN

                                        Retrieved from OpenVPN: name server(s) [ 172.16.1.1 172.16.1.1 8.8.8.8 ], domain name [ . ], search domain(s) [  ], and SMB server(s) [  ]

                                        Not aggregating ServerAddresses because running on OS X 10.6 or higher

                                        Setting search domains to '.' because running under OS X 10.6 or higher and the search domains were not set manually and 'Prepend domain name to search domains' was not selected

                                        Saved the DNS and SMB configurations so they can be restored

                                        Changed DNS ServerAddresses setting from '172.23.32.1' to '172.16.1.1 172.16.1.1 8.8.8.8'

                                        Changed DNS SearchDomains setting from '' to '.'

                                        Changed DNS DomainName setting from '' to '.'

                                        Did not change SMB NetBIOSName setting of ''

                                        Did not change SMB Workgroup setting of ''

                                        Did not change SMB WINSAddresses setting of ''

                                        DNS servers '172.16.1.1 172.16.1.1 8.8.8.8' will be used for DNS queries when the VPN is active

                                        NOTE: The DNS servers include one or more free public DNS servers known to Tunnelblick and one or more DNS servers not known to Tunnelblick. If used, the DNS servers not known to Tunnelblick may cause DNS queries to fail or be intercepted or falsified even if they are directed through the VPN. Specify only known public DNS servers or DNS servers located on the VPN network to avoid such problems.

                                        Flushed the DNS cache via dscacheutil

                                        /usr/sbin/discoveryutil not present. Not flushing the DNS cache via discoveryutil

                                        Notified mDNSResponder that the DNS cache was flushed

                                        Setting up to monitor system configuration with process-network-changes

                                        End of output from client.up.tunnelblick.sh

                                        **********************************************

2015-10-10 16:46:57 MANAGEMENT: >STATE:1444484817,ADD_ROUTES,,,

2015-10-10 16:46:57 /sbin/route add -net 192.168.2.0 172.16.1.1 255.255.255.0

                                        add net 192.168.2.0: gateway 172.16.1.1

2015-10-10 16:46:57 /sbin/route add -net 50.117.24.96 172.16.1.1 255.255.255.224

                                        add net 50.117.24.96: gateway 172.16.1.1

2015-10-10 16:46:57 /sbin/route add -net 69.46.91.194 172.16.1.1 255.255.255.255

                                        add net 69.46.91.194: gateway 172.16.1.1

2015-10-10 16:46:57 /sbin/route add -net 69.46.91.197 172.16.1.1 255.255.255.255

                                        add net 69.46.91.197: gateway 172.16.1.1

2015-10-10 16:46:57 /sbin/route add -net 70.33.176.0 172.16.1.1 255.255.255.224

                                        add net 70.33.176.0: gateway 172.16.1.1

2015-10-10 16:46:57 /sbin/route add -net 80.254.60.0 172.16.1.1 255.255.255.240

                                        add net 80.254.60.0: gateway 172.16.1.1

2015-10-10 16:46:57 Initialization Sequence Completed

2015-10-10 16:46:57 MANAGEMENT: >STATE:1444484817,CONNECTED,SUCCESS,172.16.1.9,w.x.y.z

2015-10-10 16:46:58 *Tunnelblick: No 'connected.sh' script to execute

2015-10-10 16:47:02 *Tunnelblick process-network-changes: A system configuration change was ignored

2015-10-10 16:47:03 *Tunnelblick: This computer's apparent public IP address (95.161.239.97) was unchanged after the connection was made

[jkbull...gmail.com]

Your setup sets DNS to "172.16.1.1 8.8.8.8". That means that 172.16.1.1 will be used for all DNS lookups. 8.8.8.8 will not be used unless 172.16.1.1 fails to respond at all and times out. (That's different from Windows, where DNS requests will be sent to both 172.16.1.1 and 8.8.8.8 and the first one to respond will supply the DNS info. Also, note that that, unlike Unix, OS X does not use /etc/resolv.conf for DNS information and that several command line programs on OS X do not use the DNS resolution mechanism that everything else on OS X does. So "ping", "dig", etc., can get (incorrect) results that are different from the results you would get from anywhere else in OS X, such as a browser.)

 

Your setup also does not route all IPv4 requests through the VPN. So when you try to go to, say, apple.com, your DNS query will go out normally (not through the VPN).

The combination of the two settings means that 172.16.1.1 will get a request from your computer's public IP address of 95.161.239.97, which is NOT an address from within the VPN. So the 172.16.1.1 server will presumably ignore the request.

It's hard to advise you, because you only posted a tiny part of the diagnostic info, but:

• You could add routing so requests for the DNS server at 172.16.1.1 are routed through the VPN. That way DNS requests would appear at the 172.16.1.1 server as coming from within the VPN, so it probably would respond.
  
  
• You could route all IPv4 traffic through the VPN, which would have the same effect (and more, of course). An easy way to do that is by putting a check in the corresponding box on the "Settings" tab of the "VPN Details" window while your configuration is selected in the left side of the window.
  

[gregory.k...@team.wrike.com]

I captured traffic on all network interfaces - DNS lookups goes only to 172.16.1.1, so there is no traffic to/from external/public DNS servers/ip_addrs.

Looks like You write about console tools like: ncat, ssh, ping they do not call DNS client to resolv names and return errors like `nodename nor servname provided, or not known`. At the same time WEB browsers(Chromium Based) use 172.16.1.1 as well, I see lookup in Wireshark and succeed replies to.

Firefox Have the same befavier like  ncat, ssh, ping.

[gregory.k...@team.wrike.com]

After OS restart I found that some time lookups goes to 8.8.8.8.

[gregory.k...@team.wrike.com]

And src ip_addr is from my en0 USB-Ethernet interface not from tap0 - OpenVPN created.