DNS Problem after updating to Mavericks: search domain "openvpn" set by Tunnelblick makes access fail

[Simon]

Hello,

when I connect to my OpenVPN server I get DNS pushed. But also a search domain "openvpn" is set. I can nslookup hosts from terminal but not ping nor use browser to connect to those domains within the OpenVPN network.
If I configure Tunneblick not to set DNS and I add DNS entry manually without search domain "openvpn" in osx network preferences everything works fine.

How can I make Tunnelblick only set DNS entry without a search domain?

Thanks for a response!

Regards,

Simon

[jkbull...gmail.com]

If you are having a problem with Tunnelblick, please include the following with your question.

• the contents of your configuration file;
  
• the entire contents of the Tunnelblick log; and
  
• the end of the Console log.

Be sure to X out any sensitive information such as server IP addresses.

It is best to open the "VPN Details…" window and click on the "Log" tab before doing a complete connect/disconnect cycle (if you can).

In Tunnelblick 3.3beta38 and higher, the "Copy Diagnostic Info to the Clipboard" button on the "Log" tab of the "Preferences" panel of the "VPN Details…" window will copy all of this to the Clipboard. Then you can paste it into an email or web form and edit out sensitive information.

[Simon]

Hello

Thanks for your reply.

here is the data:

##############################################
# Sample client-side OpenVPN 2.0 config file #
# for connecting to multi-client server.     #
#                                            #
# This configuration can be used by multiple #
# clients, however each client should have   #
# its own cert and key files.                #
#                                            #
# On Windows, you might want to rename this  #
# file so it has a .ovpn extension           #
##############################################

# Specify that we are a client and that we
# will be pulling certain config file directives
# from the server.
client

# Use the same setting as you are using on
# the server.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
;dev tap
dev tun

# Windows needs the TAP-Windows adapter name
# from the Network Connections panel
# if you have more than one.  On XP SP2,
# you may need to disable the firewall
# for the TAP adapter.
;dev-node MyTap

# Are we connecting to a TCP or
# UDP server?  Use the same setting as
# on the server.
;proto tcp
proto udp

# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
remote anon.xxx.org 1194
;remote my-server-2 1194

# Choose a random host from the remote
# list for load-balancing.  Otherwise
# try hosts in the order specified.
;remote-random

# Keep trying indefinitely to resolve the
# host name of the OpenVPN server.  Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite

# Most clients don't need to bind to
# a specific local port number.
nobind

# Downgrade privileges after initialization (non-Windows only)
;user nobody
;group nobody

# Try to preserve some state across restarts.
persist-key
persist-tun

# If you are connecting through an
# HTTP proxy to reach the actual OpenVPN
# server, put the proxy server/IP and
# port number here.  See the man page
# if your proxy server requires
# authentication.
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]

# Wireless networks often produce a lot
# of duplicate packets.  Set this flag
# to silence duplicate packet warnings.
;mute-replay-warnings

# SSL/TLS parms.
# See the server config file for more
# description.  It's best to use
# a separate .crt/.key file pair
# for each client.  A single ca
# file can be used for all clients.
ca ca.crt
cert anon.crt
key anon_enc.key

# Verify server certificate by checking
# that the certicate has the nsCertType
# field set to "server".  This is an
# important precaution to protect against
# a potential attack discussed here:
#  http://openvpn.net/howto.html#mitm
#
# To use this feature, you will need to generate
# your server certificates with the nsCertType
# field set to "server".  The build-key-server
# script in the easy-rsa folder will do this.
;ns-cert-type server

# If a tls-auth key is used on the server
# then every client must also have the key.
;tls-auth ta.key 1

# Select a cryptographic cipher.
# If the cipher option is used on the server
# then you must also specify it here.
;cipher x

# Enable compression on the VPN link.
# Don't enable this unless it is also
# enabled in the server config file.
comp-lzo

# Set log file verbosity.
verb 3

# Silence repeating messages
;mute 20











2013-11-17 15:20:32 *Tunnelblick: OS X 10.9.0; Tunnelblick 3.4beta14 (build 3649)
2013-11-17 15:20:32 *Tunnelblick: Attempting connection with yyyy using shadow copy; Set nameserver = 1; monitoring connection
2013-11-17 15:20:32 *Tunnelblick: openvpnstart start yyyy.tblk 1337 1 0 1 0 305 -ptADGNWradsgnw 2.2.1
2013-11-17 15:20:33 *Tunnelblick: openvpnstart log:
     Loading tun-signed.kext
    
     OpenVPN started successfully. Command used to start OpenVPN (one argument per displayed line):
    
          /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.2.1/openvpn
          --cd
          /Library/Application Support/Tunnelblick/Users/hox/yyyy.tblk/Contents/Resources
          --daemon
          --management
          127.0.0.1
          1337
          --config
          /Library/Application Support/Tunnelblick/Users/hox/yyyy.tblk/Contents/Resources/config.ovpn
          --log
          /Library/Application Support/Tunnelblick/Logs/-SUsers-Shox-SLibrary-SApplication Support-STunnelblick-SConfigurations-Syyyy.tblk-SContents-SResources-Sconfig.ovpn.1_0_1_0_305.1337.openvpn.log
          --management-query-passwords
          --management-hold
          --script-security
          2
          --up
          /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -m -w -d -f -ptADGNWradsgnw
          --down
          /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -m -w -d -f -ptADGNWradsgnw
          --up-restart

2013-11-17 15:20:32 *Tunnelblick: openvpnstart starting OpenVPN:
                    *                    /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.2.1/openvpn --cd /Library/Application Support/Tunnelblick/Users/hox/yyyy.tblk/Contents/Resources --daemon --management 127.0.0.1 1337 --config /Library/Application Support/Tunnelblick/Users/hox/yyyy.tblk/Contents/Resources/config.ovpn --log /Library/Application Support/Tunnelblick/Logs/-SUsers-Shox-SLibrary-SApplication Support-STunnelblick-SConfigurations-Syyyy.tblk-SContents-SResources-Sconfig.ovpn.1_0_1_0_305.1337.openvpn.log --management-query-passwords --management-hold --script-security 2 --up /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -m -w -d -f -ptADGNWradsgnw --down /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -m -w -d -f -ptADGNWradsgnw --up-restart
2013-11-17 15:20:33 *Tunnelblick: Established communication with OpenVPN
2013-11-17 15:20:33 OpenVPN 2.2.1 i386-apple-darwin10.8.0 [SSL] [LZO2] [PKCS11] [eurephia] built on Oct 25 2013
2013-11-17 15:20:33 MANAGEMENT: TCP Socket listening on 127.0.0.1:1337
2013-11-17 15:20:33 Need hold release from management interface, waiting...
2013-11-17 15:20:33 MANAGEMENT: Client connected from 127.0.0.1:1337
2013-11-17 15:20:33 MANAGEMENT: CMD 'pid'
2013-11-17 15:20:33 MANAGEMENT: CMD 'state on'
2013-11-17 15:20:33 MANAGEMENT: CMD 'state'
2013-11-17 15:20:33 MANAGEMENT: CMD 'bytecount 1'
2013-11-17 15:20:33 MANAGEMENT: CMD 'hold release'
2013-11-17 15:20:33 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2013-11-17 15:20:33 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2013-11-17 15:20:33 *Tunnelblick: Obtained VPN passphrase from the Keychain
2013-11-17 15:20:33 MANAGEMENT: CMD 'password [...]'
2013-11-17 15:20:33 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2013-11-17 15:20:33 LZO compression initialized
2013-11-17 15:20:33 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
2013-11-17 15:20:33 Socket Buffers: R=[196724->65536] S=[9216->65536]
2013-11-17 15:20:33 MANAGEMENT: >STATE:1384698033,RESOLVE,,,
2013-11-17 15:20:34 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
2013-11-17 15:20:34 Local Options hash (VER=V4): '41690919'
2013-11-17 15:20:34 Expected Remote Options hash (VER=V4): '530fdded'
2013-11-17 15:20:34 UDPv4 link local: [undef]
2013-11-17 15:20:34 UDPv4 link remote: x.x.x.x:1194
2013-11-17 15:20:34 MANAGEMENT: >STATE:1384698034,WAIT,,,
2013-11-17 15:20:34 MANAGEMENT: >STATE:1384698034,AUTH,,,
2013-11-17 15:20:34 TLS: Initial packet from x.x.x.x:1194, sid=06f89532 a60a944e
2013-11-17 15:20:37 VERIFY OK: depth=1, /CN=ca-yyyy
2013-11-17 15:20:37 VERIFY OK: depth=0, /CN=yyyy.dyndns.org
2013-11-17 15:20:42 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
2013-11-17 15:20:42 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
2013-11-17 15:20:42 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
2013-11-17 15:20:42 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
2013-11-17 15:20:42 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 4096 bit RSA
2013-11-17 15:20:42 [yyyy.dyndns.org] Peer Connection Initiated with x.x.x.x:1194
2013-11-17 15:20:44 MANAGEMENT: >STATE:1384698044,GET_CONFIG,,,
2013-11-17 15:20:45 SENT CONTROL [yyyy.dyndns.org]: 'PUSH_REQUEST' (status=1)
2013-11-17 15:20:45 PUSH: Received control message: 'PUSH_REPLY,route 192.168.3.0 255.255.255.0,dhcp-option DNS 192.168.3.1,redirect-gateway def1,route 10.8.0.1,topology net30,ping 15,ping-restart 60,ifconfig 10.8.0.6 10.8.0.5'
2013-11-17 15:20:45 OPTIONS IMPORT: timers and/or timeouts modified
2013-11-17 15:20:45 OPTIONS IMPORT: --ifconfig/up options modified
2013-11-17 15:20:45 OPTIONS IMPORT: route options modified
2013-11-17 15:20:45 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2013-11-17 15:20:45 ROUTE default_gateway=192.168.1.1
2013-11-17 15:20:45 TUN/TAP device /dev/tun0 opened
2013-11-17 15:20:45 MANAGEMENT: >STATE:1384698045,ASSIGN_IP,,10.8.0.6,
2013-11-17 15:20:45 /sbin/ifconfig tun0 delete
                                        ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
2013-11-17 15:20:45 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
2013-11-17 15:20:45 /sbin/ifconfig tun0 10.8.0.6 10.8.0.5 mtu 1500 netmask 255.255.255.255 up
2013-11-17 15:20:45 /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -m -w -d -f -ptADGNWradsgnw tun0 1500 1542 10.8.0.6 10.8.0.5 init
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: Retrieved from OpenVPN: name server(s) [ 192.168.3.1 ], search domain(s) [ ] and SMB server(s) [ ] and using default domain name [ openvpn ]
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG: MAN_DNS_CONFIG = No such key
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG: MAN_SMB_CONFIG = No such key
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG: CUR_DNS_CONFIG = <dictionary> { ServerAddresses : <array> { 192.168.1.1 } }
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG: CUR_SMB_CONFIG = No such key
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG: DYN_DNS_DN = openvpn; DYN_DNS_SA = 192.168.3.1; DYN_DNS_SD =
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG: DYN_SMB_NN = ; DYN_SMB_WG = ; DYN_SMB_WA =
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG: MAN_DNS_DN = ; MAN_DNS_SA = ; MAN_DNS_SD =
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG: MAN_SMB_NN = ; MAN_SMB_WG = ; MAN_SMB_WA =
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG: CUR_DNS_DN = ; CUR_DNS_SA = 192.168.1.1; CUR_DNS_SD =
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG: CUR_SMB_NN = ; CUR_SMB_WG = ; CUR_SMB_WA =
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: ServerAddresses were not aggregated because running on OS X 10.6 or higher
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: Setting search domains to 'openvpn' 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
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG: FIN_DNS_DN = openvpn; FIN_DNS_SA = 192.168.3.1; FIN_DNS_SD = openvpn
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG: FIN_SMB_NN = ; FIN_SMB_WG = ; FIN_SMB_WA =
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG: OS X 10.8 or higher, so will modify DNS settings using Setup: in addition to State:
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG: SKP_DNS = ; SKP_DNS_SA = ; SKP_DNS_SD = ; SKP_DNS_DN =
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG: SKP_SETUP_DNS =
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG: SKP_SMB = #; SKP_SMB_NN = #; SKP_SMB_WG = #; SKP_SMB_WA = #
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG: /etc/resolve = nameserver 192.168.1.1
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG: scutil --dns BEFORE CHANGES = DNS configuration resolver #1 nameserver[0] : 192.168.1.1 if_index : 4 (en0) flags : Request A records reach : Reachable,Directly Reachable Address resolver #2 domain : local options : mdns timeout : 5 flags : Request A records order : 300000 resolver #3 domain : 254.169.in-addr.arpa options : mdns timeout : 5 flags : Request A records order : 300200 resolver #4 domain : 8.e.f.ip6.arpa options : mdns timeout : 5 flags : Request A records order : 300400 resolver #5 domain : 9.e.f.ip6.arpa options : mdns timeout : 5 flags : Request A records order : 300600 resolver #6 domain : a.e.f.ip6.arpa options : mdns timeout : 5 flags : Request A records order : 300800 resolver #7 domain : b.e.f.ip6.arpa options : mdns timeout : 5 flags : Request A records order : 301000 DNS configuration (for scoped queries) resolver #1 nameserver[0] : 192.168.1.1 if_index : 4 (en0) flags : Scoped, Request A records reach : Reachable,Directly Reachable Address
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG: Configuration changes:
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG: ADD State: ServerAddresses 192.168.3.1
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG: ADD State: SearchDomains openvpn
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG: ADD State: DomainName openvpn
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG: ADD Setup: ServerAddresses 192.168.3.1
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG: ADD Setup: SearchDomains openvpn
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG: ADD Setup: DomainName openvpn
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG: ##ADD State: NetBIOSName
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG: ##ADD State: Workgroup
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG: ##ADD State: WINSAddresses
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-17 15:20:47 *Tunnelblick client.up.tunnelblick.sh: DEBUG: Pause for configuration changes to be propagated to State:/Network/Global/DNS and .../SMB
2013-11-17 15:20:48 /sbin/route add -net x.x.x.x 192.168.1.1 255.255.255.255
                                        add net x.x.x.x: gateway 192.168.1.1
2013-11-17 15:20:48 /sbin/route add -net 0.0.0.0 10.8.0.5 128.0.0.0
                                        add net 0.0.0.0: gateway 10.8.0.5
2013-11-17 15:20:48 /sbin/route add -net 128.0.0.0 10.8.0.5 128.0.0.0
                                        add net 128.0.0.0: gateway 10.8.0.5
2013-11-17 15:20:48 MANAGEMENT: >STATE:1384698048,ADD_ROUTES,,,
2013-11-17 15:20:48 /sbin/route add -net 192.168.3.0 10.8.0.5 255.255.255.0
                                        add net 192.168.3.0: gateway 10.8.0.5
2013-11-17 15:20:48 /sbin/route add -net 10.8.0.1 10.8.0.5 255.255.255.255
                                        add net 10.8.0.1: gateway 10.8.0.5
2013-11-17 15:20:48 Initialization Sequence Completed
2013-11-17 15:20:48 MANAGEMENT: >STATE:1384698048,CONNECTED,SUCCESS,10.8.0.6,x.x.x.x
2013-11-17 15:20:48 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-17 15:20:48 *Tunnelblick client.up.tunnelblick.sh: DEBUG: Configurations as read back after changes:
2013-11-17 15:20:48 *Tunnelblick client.up.tunnelblick.sh: DEBUG: State:/.../DNS = <dictionary> { DomainName : openvpn SearchDomains : <array> { openvpn } ServerAddresses : <array> { 192.168.3.1 } }
2013-11-17 15:20:48 *Tunnelblick client.up.tunnelblick.sh: DEBUG: State:/.../SMB = No such key
2013-11-17 15:20:48 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-17 15:20:48 *Tunnelblick client.up.tunnelblick.sh: DEBUG: Setup:/.../DNS = <dictionary> { DomainName : openvpn SearchDomains : <array> { openvpn } ServerAddresses : <array> { 192.168.3.1 } }
2013-11-17 15:20:48 *Tunnelblick client.up.tunnelblick.sh: DEBUG: Setup:/.../SMB = No such key
2013-11-17 15:20:48 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-17 15:20:48 *Tunnelblick client.up.tunnelblick.sh: DEBUG: State:/Network/Global/DNS = <dictionary> { DomainName : openvpn SearchDomains : <array> { openvpn } ServerAddresses : <array> { 192.168.3.1 } }
2013-11-17 15:20:48 *Tunnelblick client.up.tunnelblick.sh: DEBUG: State:/Network/Global/SMB = No such key
2013-11-17 15:20:48 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-17 15:20:48 *Tunnelblick client.up.tunnelblick.sh: DEBUG: Expected by process-network-changes:
2013-11-17 15:20:48 *Tunnelblick client.up.tunnelblick.sh: DEBUG: State:/Network/OpenVPN/DNS = <dictionary> { DomainName : openvpn SearchDomains : <array> { openvpn } ServerAddresses : <array> { 192.168.3.1 } }
2013-11-17 15:20:48 *Tunnelblick client.up.tunnelblick.sh: DEBUG: State:/Network/OpenVPN/SMB = <dictionary> { TunnelblickNoSuchKey : true }
2013-11-17 15:20:48 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-17 15:20:48 *Tunnelblick client.up.tunnelblick.sh: DEBUG: /etc/resolve = search openvpn nameserver 192.168.3.1
2013-11-17 15:20:48 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-17 15:20:48 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-17 15:20:48 *Tunnelblick client.up.tunnelblick.sh: DEBUG: scutil --dns AFTER CHANGES = DNS configuration resolver #1 search domain[0] : openvpn nameserver[0] : 192.168.3.1 flags : Request A records reach : Reachable resolver #2 domain : local options : mdns timeout : 5 flags : Request A records order : 300000 resolver #3 domain : 254.169.in-addr.arpa options : mdns timeout : 5 flags : Request A records order : 300200 resolver #4 domain : 8.e.f.ip6.arpa options : mdns timeout : 5 flags : Request A records order : 300400 resolver #5 domain : 9.e.f.ip6.arpa options : mdns timeout : 5 flags : Request A records order : 300600 resolver #6 domain : a.e.f.ip6.arpa options : mdns timeout : 5 flags : Request A records order : 300800 resolver #7 domain : b.e.f.ip6.arpa options : mdns timeout : 5 flags : Request A records order : 301000 DNS configuration (for scoped queries) resolver #1 search domain[0] : openvpn nameserver[0] : 192.168.3.1 if_index : 4 (en0) flags : Scoped, Request A records reach : Reachable
2013-11-17 15:20:48 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-17 15:20:48 *Tunnelblick client.up.tunnelblick.sh: Saved the DNS and SMB configurations for later use
2013-11-17 15:20:48 *Tunnelblick: No 'connected.sh' script to execute
2013-11-17 15:20:48 *Tunnelblick client.up.tunnelblick.sh: Flushed the DNS Cache
2013-11-17 15:20:48 *Tunnelblick client.up.tunnelblick.sh: Set up to monitor system configuration with process-network-changes
2013-11-17 15:20:53 *Tunnelblick process-network-changes: A system configuration change was ignored
2013-11-17 15:20:54 *Tunnelblick: This computer's apparent public IP address changed from y.y.y.y before connection to x.x.x.x after connection
2013-11-17 15:21:01 *Tunnelblick: Disconnecting; 'disconnect' button pressed
2013-11-17 15:21:01 *Tunnelblick: Disconnecting using 'killall'
2013-11-17 15:21:01 event_wait : Interrupted system call (code=4)
2013-11-17 15:21:01 TCP/UDP: Closing socket
2013-11-17 15:21:01 /sbin/route delete -net 10.8.0.1 10.8.0.5 255.255.255.255
                                        delete net 10.8.0.1: gateway 10.8.0.5
2013-11-17 15:21:01 /sbin/route delete -net 192.168.3.0 10.8.0.5 255.255.255.0
                                        delete net 192.168.3.0: gateway 10.8.0.5
2013-11-17 15:21:01 /sbin/route delete -net x.x.x.x 192.168.1.1 255.255.255.255
                                        delete net x.x.x.x: gateway 192.168.1.1
2013-11-17 15:21:01 /sbin/route delete -net 0.0.0.0 10.8.0.5 128.0.0.0
                                        delete net 0.0.0.0: gateway 10.8.0.5
2013-11-17 15:21:01 /sbin/route delete -net 128.0.0.0 10.8.0.5 128.0.0.0
                                        delete net 128.0.0.0: gateway 10.8.0.5
2013-11-17 15:21:01 Closing TUN/TAP interface
2013-11-17 15:21:01 /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -m -w -d -f -ptADGNWradsgnw tun0 1500 1542 10.8.0.6 10.8.0.5 init
2013-11-17 15:21:01 *Tunnelblick client.down.tunnelblick.sh: Cancelled monitoring of system configuration changes
2013-11-17 15:21:01 *Tunnelblick client.down.tunnelblick.sh: DEBUG: Removing 'Setup:' DNS key
                                          No such key
2013-11-17 15:21:01 SIGTERM[hard,] received, process exiting
2013-11-17 15:21:01 MANAGEMENT: >STATE:1384698061,EXITING,SIGTERM,,
2013-11-17 15:21:01 *Tunnelblick client.down.tunnelblick.sh: Restored the DNS and SMB configurations
2013-11-17 15:21:01 *Tunnelblick client.down.tunnelblick.sh: DEBUG:
2013-11-17 15:21:01 *Tunnelblick client.down.tunnelblick.sh: DEBUG: /etc/resolve = nameserver 192.168.1.1
2013-11-17 15:21:01 *Tunnelblick client.down.tunnelblick.sh: DEBUG:
2013-11-17 15:21:01 *Tunnelblick client.down.tunnelblick.sh: DEBUG: scutil --dns = DNS configuration resolver #1 nameserver[0] : 192.168.1.1 if_index : 4 (en0) flags : Request A records reach : Reachable,Directly Reachable Address resolver #2 domain : local options : mdns timeout : 5 flags : Request A records order : 300000 resolver #3 domain : 254.169.in-addr.arpa options : mdns timeout : 5 flags : Request A records order : 300200 resolver #4 domain : 8.e.f.ip6.arpa options : mdns timeout : 5 flags : Request A records order : 300400 resolver #5 domain : 9.e.f.ip6.arpa options : mdns timeout : 5 flags : Request A records order : 300600 resolver #6 domain : a.e.f.ip6.arpa options : mdns timeout : 5 flags : Request A records order : 300800 resolver #7 domain : b.e.f.ip6.arpa options : mdns timeout : 5 flags : Request A records order : 301000 DNS configuration (for scoped queries) resolver #1 nameserver[0] : 192.168.1.1 if_index : 4 (en0) flags : Scoped, Request A records reach : Reachable,Directly Reachable Address
2013-11-17 15:21:01 *Tunnelblick client.down.tunnelblick.sh: DEBUG:
2013-11-17 15:21:01 *Tunnelblick client.down.tunnelblick.sh: Flushed the DNS Cache
2013-11-17 15:21:02 *Tunnelblick: No 'post-disconnect.sh' script to execute

Nov 17 15:19:59 mysterian Tunnelblick[381]: Warning: Preferences contain unknown preference '*-notOKToCheckThatIPAddressDidNotChangeAfterConnection'
Nov 17 15:20:02 mysterian Tunnelblick[381]: Set program update feedURL to https://www.tunnelblick.net/appcast-b.rss
Nov 17 15:20:02 mysterian Tunnelblick[381]: DEBUG: Updater: systemVersion 10.9.0 satisfies minimumSystemVersion 10.4.0
Nov 17 15:20:33 mysterian Tunnelblick[381]: Keychain item retrieved successfully for service = 'Tunnelblick-Auth-anon' account = 'privateKey'


Thanks for also considering what I wrote in my first post!

Somehow Tunnelblick thinks that "openvpn" would be my Domain name.

Why does it believe that? Does it take that from the server's certificate?
How can I configure Tunnelblick, such that it does only assign a DNS but without a search domain?

Thanks for any hints on that!

[Simon]

Does anybody have an answer to this?

[jkbull...gmail.com]

To answer your original question: no, you cannot get Tunnelblick to leave the search domain alone but process the other DNS changes. You can get Tunnelblick to leave everything (DNS, domain, search domain, WINS) alone, but then it does nothing and you still ned to deal with DNS.

Some comments and questions:

• The search domain is unlikely to be causing a problem -- Tunnelblick has been doing this for years and I've never seen it cause a problem.
  
• "ping" and many other commands in Terminal on OS X do not use the same DNS resolution as the rest of the system and applications, so you should not use them for diagnosing DNS problems.
  
• Is the problem a DNS problem, resolving other hosts on your VPN server's LAN, or is it a routing problem? That is, can you get to them via IP address, but not name? If that's the problem, are you using fully-qualified names?
  
• Can you get to other, general sites on the Internet (e.g., www.google.com, www.ibm.com, etc.? 
• If you have "Check if the apparent public IP address changed after connection" on the Advanced window checked, Tunnelblick will test DNS and general Internet connectivity for you after connecting. You will need to wait for a while until you get a popup window with an error, or a message in the Tunnelblick log indicating success.
  

If in fact it is the "search domain" setting that is causing problems and you don't want to set DNS manually after each connection to the VPN, the best way to do it might be to copy the standard Tunnelblick up and down scripts, remove the code that sets and restores the search domain, and use them as your own custom scripts (see Using Scripts). You would then set Tunnelblick's DNS/WINS setting to "Do not set nameserver". The standard Tunnelblick scripts are located in /Applications/Tunnelblick/Contents/Resources, and are named "client.up.tunnelblick.sh" and "client.down.tunnelblick.sh".

[Simon]

Hi

Thanks for your help!
here are some answers to your questions:

• Is the problem a DNS problem, resolving other hosts on your VPN server's LAN, or is it a routing problem? That is, can you get to them via IP address, but not name? If that's the problem, are you using fully-qualified names?

I can get the peers via IP address but not by name. I guess I am not using fully-qualified names. Tunnelblick log states:

" Start of output from client.up.tunnelblick.sh
                                        Retrieved from OpenVPN: name server(s) [ xxx.xxx.xxx.xxx ], search domain(s) [  ] and SMB server(s) [  ] and using default domain name [ openvpn ]"

Why would I want the default search domain and domain name to be "openvpn"?

• Can you get to other, general sites on the Internet (e.g., www.google.com, www.ibm.com, etc.? 

Yes I get those hosts with no further problems while connected to my openvpn server and not being able to resolve my openvpn hosts by name!

Moreover, I cannot make custom scripts  work. If I copy "client.up.tunnelblick.sh" and "client.down.tunnelblick.sh" to my openvpn config folder and rename them to "up.tunnelblick.sh" and "down.tunnelblick.sh" I get script terminated with exit code 1 even without a single change while I try to connect. However I cannot leave "Do not set nameserve" since the scripts seems not to be applied at all.

Could you please be little bit more specific how to disable the searchDomain feature overriding those scripts. As I already said, when I manually set the domain server after a connection everything works fine. Also when running the exact same client Openvpn config from Android I can resolve my hosts by name. So it seems to be a Tunnelblick issue.

Thanks for a reply!

Regards,

Simon

[jkbull...gmail.com]

I have just uploaded a Tunnelblick "snapshot" (pre-release version) which fixes the problem using client.up.tunnelblick.sh from within a .tblk. I will email you momentarily with a link so you can download it.

Be sure you install the snapshot -- don't just use the client.up.tunnelblick.sh script within it -- the program and the script have both been modified and must be used together.

Having thought more about the problem you have (if I understand it correctly), I think your OpenVPN server is misconfigured. I think it should "push" its domain. If it does that, Tunnelblick will not set the domain or search domains to "openvpn" (it will set them to the pushed domain).

But if I am not understanding the situation correctly, or if you can't change the server configuration, at least you will be able to use the script.

To modify the script to set the domain and search domain to "abcde"  (or whatever your domain is), change line 1133 of your copy of client.up.tunnelblick.sh from

readonly DEFAULT_DOMAIN_NAME="openvpn"

to

readonly DEFAULT_DOMAIN_NAME="abcde"

[mike....@gmail.com]

I have a similar issue here, I will collect more diagnostics and post them.

Mike

[jkbull...gmail.com]

I have just uploaded a Tunnelblick "snapshot" (pre-release version) which implements a preference that inhibits the use of the default 'openvpn' domain.

It is a per-configuration preference. You cannot change it with the GUI, but you can set it for all configurations with the following command in Terminal:

defaults write net.tunnelblick.tunnelblick "*-doNotUseDefaultDomain" -bool yes

To remove the preference, use the following command in Terminal:

defaults delete net.tunnelblick.tunnelblick "*-doNotUseDefaultDomain"

Thinking about the original poster's problem even more, I remembered that if domain "abcde" is not being "pushed" by the server, one can add a line in the OpenVPN configuration file to do the same thing:

dhcp-option DOMAIN abcde

[mike....@gmail.com]

Hi Config is below

I have

Set Nameserver (3.1).

Manually set Domain Search terms In Network preferences

Pre connection I see my local router as DNS and everything works.

$ cat /etc/resolv.conf 

search XXXX.lc XXXX.lc

nameserver 192.168.1.254

On Connection I get 

nameserver 10.32.16.200

And expected new routes in my route table, to the remote 10. subnets

$ netstat -rnf inet

Routing tables

Internet:

Destination        Gateway            Flags        Refs      Use   Netif Expire

default            192.168.1.254      UGSc           32        0     en0

10.32.13/24        link#9             UC              3        0    tap0

10.32.13.1         link#9             UHLWIi          2        0    tap0

10.32.13.255       ff:ff:ff:ff:ff:ff  UHLWbI          0       19    tap0

10.32.16/22        10.32.13.1         UGSc            0        0    tap0

10.33/16           10.32.13.1         UGSc            0        0    tap0

127                127.0.0.1          UCS             0        0     lo0

127.0.0.1          127.0.0.1          UH              5      156     lo0

169.254            link#4             UCS             0        0     en0

192.168.1          link#4             UCS             2        0     en0

192.168.1.68       127.0.0.1          UHS             0        0     lo0

192.168.1.254      0:24:17:ae:b8:28   UHLWIir        33      116     en0   1179

192.168.1.255      ff:ff:ff:ff:ff:ff  UHLWbI          0       25     en0

I can resolve names using DIG

$ dig www.google.com

; <<>> DiG 9.8.3-P1 <<>> www.google.com

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5551

;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:

;www.google.com. IN A

;; ANSWER SECTION:

www.google.com. 205 IN A 74.125.237.212

www.google.com. 205 IN A 74.125.237.208

www.google.com. 205 IN A 74.125.237.209

www.google.com. 205 IN A 74.125.237.210

www.google.com. 205 IN A 74.125.237.211

;; Query time: 1042 msec

;; SERVER: 10.32.16.200#53(10.32.16.200)

;; WHEN: Thu Jan 16 08:18:48 2014

;; MSG SIZE  rcvd: 112

so I am getting a response packet from my remote DNS server, so connectivity is OK.

nslookup also works OK.

but Ping fails

$ ping  www.google.com

ping: cannot resolve www.google.com: Unknown host

As does browsing to https://www.google.com

ping by IP works.

If I add in a Host entry for Google, then browsing works OK.

So it seems like there is connectivity to the DNS server but something in Mavericks has changed such that all the lookups from the Cocoa environment are failing.

SCUTIL seems to have the new dns

$ scutil --dns

DNS configuration

resolver #1

  search domain[0] : XXXX.lc

  search domain[1] : XXXXX.lc

  nameserver[0] : 10.32.16.200

  if_index : 4 (en0)

  flags    : Request A records

  search domain[0] : XXXXXX.lc

  search domain[1] : XXXXX.lc

  nameserver[0] : 10.32.16.200

  if_index : 4 (en0)

  flags    : Scoped, Request A records

  reach    : Reachable

but its lookups time out as well.

$ scutil -r www.google.com

Not Reachable

$ scutil -r 10.32.16.200

Reachable

*Tunnelblick: OS X 10.9.1; Tunnelblick 3.4beta18 (build 3704); Admin user

"Sanitized" configuration file for /Library/Application Support/Tunnelblick/Shared/XXXXX-NZ.tblk:

#######################################

# Client-side OpenVPN 2.0 config file #

# for connecting to XXXXX             #

#######################################

tls-client

auth-user-pass

cipher AES-128-CBC

dev tap

proto udp

remote edge.XXXXX.co.nz

ca "cacert.pem"

verb 1

pull

================================================================================

Configuration preferences:

useDNS = 2

-runMtuTest = 1

-keychainHasUsernameAndPassword = 1

-notOKToCheckThatIPAddressDidNotChangeAfterConnection = 0

-lastConnectionSucceeded = 1

-tunnelDownSoundName = Speak

================================================================================

Wildcard preferences:

-notOKToCheckThatIPAddressDidNotChangeAfterConnection = 0

================================================================================

Program preferences:

skipWarningThatIPAddressDidNotChangeAfterConnection = 1

skipWarningAboutInvalidSignature = 1

notOKToCheckThatIPAddressDidNotChangeAfterConnection = 0

askedUserIfOKToCheckThatIPAddressDidNotChangeAfterConnection = 1

tunnelblickVersionHistory = (

    "3.4beta18 (build 3704)"

)

showConnectedDurations = 1

connectionWindowDisplayCriteria = showWhenChanges

maxLogDisplaySize = 1048576

lastConnectedDisplayName = ATL-NZ

keyboardShortcutIndex = 1

updateCheckAutomatically = 1

updateSendProfileInfo = 0

NSWindow Frame SettingsSheetWindow = 424 400 829 424 0 0 1440 878 

NSWindow Frame ConnectingWindow = 502 518 389 187 0 0 1440 878 

detailsWindowFrameVersion = 3704

detailsWindowFrame = {{319, 307}, {760, 468}}

detailsWindowLeftFrame = {{0, 0}, {135, 350}}

leftNavSelectedDisplayName = XXXXX-NZ

haveDealtWithSparkle1dot5b6 = 1

haveDealtWithOldTunTapPreferences = 1

SUEnableAutomaticChecks = 1

SUFeedURL = https://www.tunnelblick.net/appcast-b.rss

SUSendProfileInfo = 0

SULastCheckTime = 2014-01-15 19:06:43 +0000

SUHasLaunchedBefore = 1

WebKitDefaultFontSize = 16

WebKitStandardFont = Times

================================================================================

Tunnelblick Log:

2014-01-16 08:14:49 *Tunnelblick: openvpnstart starting OpenVPN

2014-01-16 08:14:50 OpenVPN 2.2.1 i386-apple-darwin10.8.0 [SSL] [LZO2] [PKCS11] [eurephia] built on Oct 25 2013

2014-01-16 08:14:50 *Tunnelblick: Established communication with OpenVPN

2014-01-16 08:14:50 *Tunnelblick: Obtained VPN username and password from the Keychain

2014-01-16 08:14:50 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port.

2014-01-16 08:14:50 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.

2014-01-16 08:14:50 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2014-01-16 08:14:50 UDPv4 link local (bound): [undef]:1194

2014-01-16 08:14:50 UDPv4 link remote: XX.XX.XX.70:1194

2014-01-16 08:14:50 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this

2014-01-16 08:14:51 [XXXXXXSystem] Peer Connection Initiated with XX.XX.XX.70:1194

2014-01-16 08:14:53 NOTE: Beginning empirical MTU test -- results should be available in 3 to 4 minutes.

2014-01-16 08:14:53 TUN/TAP device /dev/tap0 opened

2014-01-16 08:14:53 /sbin/ifconfig tap0 delete

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

2014-01-16 08:14:53 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure

2014-01-16 08:14:53 /sbin/ifconfig tap0 10.32.13.46 netmask 255.255.255.0 mtu 1500 up

2014-01-16 08:14:53 /Applications/Tunnelblick.app/Contents/Resources/client.1.up.tunnelblick.sh -m -w -d -a -f -ptADGNWradsgnw tap0 1500 1589 10.32.13.46 255.255.255.0 init

                                        add net 10.32.16.0: gateway 10.32.13.1

                                        add net 10.33.0.0: gateway 10.32.13.1

2014-01-16 08:14:54 Initialization Sequence Completed

2014-01-16 08:14:54 *Tunnelblick: No 'connected.sh' script to execute

2014-01-16 08:14:59 *Tunnelblick: This computer's apparent public IP address (XXX.XX.XX.55) was unchanged after the connection was made

2014-01-16 08:18:03 NOTE: Empirical MTU test completed [Tried,Actual] local->remote=[1589,1589] remote->local=[1589,1589]

2014-01-16 08:41:09 *Tunnelblick: Disconnecting; 'disconnect' button pressed

2014-01-16 08:41:09 *Tunnelblick: Disconnecting using 'killall'

2014-01-16 08:41:09 event_wait : Interrupted system call (code=4)

                                        delete net 10.33.0.0: gateway 10.32.13.1

                                        delete net 10.32.16.0: gateway 10.32.13.1

2014-01-16 08:41:09 /Applications/Tunnelblick.app/Contents/Resources/client.1.down.tunnelblick.sh -m -w -d -a -f -ptADGNWradsgnw tap0 1500 1589 10.32.13.46 255.255.255.0 init

2014-01-16 08:41:09 SIGTERM[hard,] received, process exiting

2014-01-16 08:41:09 *Tunnelblick: No 'post-disconnect.sh' script to execute

2014-01-16 08:41:09 *Tunnelblick: Expected disconnection occurred.

================================================================================

Console Log:

t

2014-01-16 08:03:44 Tunnelblick[316] setShutdownVariables: invoked, but have already set them

2014-01-16 08:03:44 Tunnelblick[316] applicationShouldTerminate: termination because of restart; delayed until 'shutdownTunnelblick' finishes

2014-01-16 08:03:44 Tunnelblick[316] Finished shutting down Tunnelblick; allowing termination

2014-01-16 08:04:18 Tunnelblick[285] Set program update feedURL to https://www.tunnelblick.net/appcast-b.rss

2014-01-16 08:04:20 Tunnelblick[285] DEBUG: Updater: systemVersion 10.9.1 satisfies minimumSystemVersion 10.4.0

2014-01-16 08:04:20 Tunnelblick[285] DEBUG: Updater: systemVersion 10.9.1 satisfies minimumSystemVersion 10.4.0

2014-01-16 08:06:14 Tunnelblick[285] setShutdownVariables: invoked, but have already set them

2014-01-16 08:06:14 Tunnelblick[285] applicationShouldTerminate: termination because of restart; delayed until 'shutdownTunnelblick' finishes

2014-01-16 08:06:14 Tunnelblick[285] Finished shutting down Tunnelblick; allowing termination

2014-01-16 08:06:43 Tunnelblick[286] Set program update feedURL to https://www.tunnelblick.net/appcast-b.rss

2014-01-16 08:06:45 Tunnelblick[286] DEBUG: Updater: systemVersion 10.9.1 satisfies minimumSystemVersion 10.4.0

2014-01-16 08:06:45 Tunnelblick[286] DEBUG: Updater: systemVersion 10.9.1 satisfies minimumSystemVersion 10.4.0

2014-01-16 08:14:50 Tunnelblick[286] Keychain item retrieved successfully for service = 'Tunnelblick-Auth-XXX-NZ' account = 'username'

2014-01-16 08:14:50 Tunnelblick[286] Keychain item retrieved successfully for service = 'Tunnelblick-Auth-XXXX-NZ' account = 'password'

[jkbull...gmail.com]

1. Note this comment at the start of  /etc/resolv.conf:

# This file is not used by the host name and address resolution

# or the DNS query routing mechanisms used by most processes on

# this Mac OS X system.

Many command line utilities (ping, dig, etc.) use a completely different name resolution than the rest of OS X.

2. Please try the default "Set nameserver" and post the diagnostic info for that.

[Michael Savory]

Hi

Yes, that is correct, resolv.con is automatically set by the System Configuration Framework, and I also captured the fact that scutil shows the same timeouts.

I can see the DNS information in the Network pane of the System Preferences as well.

Using the default "Set nameserver", I do NOT get any DNS set by Tunnelblick at all and get the following log message.

2014-01-17 09:40:48 Initialization Sequence Completed
                                        Sleeping for 0 seconds to wait for DHCP to finish setup.
                                        Sleeping for 1 seconds to wait for DHCP to finish setup.
                                        Sleeping for 2 seconds to wait for DHCP to finish setup.
                                        Sleeping for 3 seconds to wait for DHCP to finish setup.
                                        Sleeping for 4 seconds to wait for DHCP to finish setup.
                                        DEBUG: Finished waiting for DHCP lease: test_domain_name = '', test_name_server = ''
                                        DEBUG: About to 'ipconfig getpacket tap0'
                                        DEBUG: Completed 'ipconfig getpacket tap0'; sGetPacketOutput = 
                                        DEBUG: About to 'ipconfig getoption tap0 domain_name'
                                        DEBUG: Completed 'ipconfig getoption tap0 domain_name'
                                        DEBUG: About to 'ipconfig getoption tap0 domain_name_server'
                                        DEBUG: Completed 'ipconfig getoption tap0 domain_name_server'
                                        WARNING: No DNS information received from OpenVPN (DHCP), so no network/DNS configuration changes need to be made.
                                        Will NOT monitor for other network configuration changes.

Hope that helps

Regards

Mike

[mike...@gmail.com]

Found this thread, which seems to have stalled.  I'm in the same situation; OpenVPN Access Server 2.0.10, Tunnelblick 3.4.1 build 4054, OSX Mavericks.

I'm setting a DNS server and DNS domain from OpenVPN; under regular conditions, that works just fine, other than replacing the existing DNS configuration (and I am not taking over the routes in the OpenVPN config).  My desire is to have the OpenVPN-supplied DNS information "prepended" to the existing one, so I edited the client.up.tunnelblick.sh to accomplish that -- at least, from scutil and System Preferences Network's perspective.  It basically takes the OpenVPN-provided DNS config and turns that into a Search Domain, and prepends the DNS server IP to the existing ones (keeping the total count to no more than three just in case there was a problem with having more than three, which doesn't seem to be the case).

ping fails, host works.

If I wait long enough (5 minutes? 15 minutes?  an hour?), everything works as far as DNS lookups go.

If I wait even longer, DNS lookups start to fail (may be related to DNS TTL of the DNS server in the VPN'd location, not sure).

I'm probably going to go to Yosemite soon, not that that's any attempt to resolve (ha, ha) this.  Curious if there's an actual solution though.

Thanks.

Michael

On Saturday, November 16, 2013 3:19:45 PM UTC-5, Simon wrote:

[jkbull...gmail.com]

(I'm sorry that the moderation of your post was delayed -- for some reason Google thought it was spam so I didn't see it until it showed up in my weekly spam report.)

I'm not sure what you mean by "the same situation" -- the two other posters described two very different problems that don't seem to be related to yours -- but "prepending a nameserver to the list of nameservers" does not do what you think it does.

It looks like you want to have "split DNS" -- you want to use one nameserver ("A") to look up some names, and a different nameserver ("B") for all other lookups.

Here is the situation as I understand it:

• Under Windows, if you specify a list of two nameservers "A, B", all queries go to both servers. Windows uses the answer provided by the first server to answer with an address.
  
  
• Under OS X, it works differently. If you specify a list of two nameservers, "A, B", all queries go to A. If A does not reply (with either an address or a "not known") within some timeout period (30 seconds, I think), then OS X starts using B instead of A and will use B until B stops replying, at which point it will go back to using A (or will use C if a third nameserver is specified).
  

So under Windows it works the way you want -- the address comes from the nameserver that knows the name. But under OS X, it does not work the way you want. Instead, it tries whichever nameserver you listed first, and only after it fails to answer does it start using the other nameserver(s). Waiting for that failure can mean long lags -- tens of seconds or minutes.

What you want can done on the server side by having a single nameserver that is set up to respond to all queries.

There is supposed to be a way to do it on the client side, but I don't know what it is, so I can't implement it. As I understand it, along with specifying a nameserver B for general use, you specify certain domain names for which nameserver A should be used. So queries for *.example.com go to A, but queries for everything else go to B.

I would be happy to incorporate this into Tunnelblick's standard "Set nameserver" script if someone can tell me how using scutil. Please don't suggest anything to do with /etc/resolv.conf because it is not used by most of OS X -- see my earlier comment.

That's why this discussion has stalled -- nobody has the answer.

(Again, I apologize for the delay in approving your post.)

[Michael Matthews]

Thanks for the reply; no worries on the spam delay.

"The same situation" as in DNS isn't behaving as desired.  True, the other details are a bit different.

To clarify, yes, I want split DNS, but I'm trying treat this just like any other setup where you have more than one DNS server with more than one search domain.

DHCP settings obtained from office network are domain A.com, DNS servers D1, D2, D3.

Connect to OpenVPN appliance via Tunnelblick out of the box, you get domain B.C.com, DNS server V1.  Routes work everywhere, just can't resolve hosts from A.com any more (and, since V1 is an internal lab, it has no idea about anything but its own private address space).

According to all the tools I know about to query DNS config, the custom script based on the default one sets:

domain still A.com

searchdomain A.com, B.C.com

DNS servers V1,D1,D2

So I would expect attempts to look up, say, X.B.C.com would have some random timeouts (depending on actual DNS server lookup order) but then work.  Same for anything in A.com or anywhere else.  This does work for tools that don't use OSX resolver routines.  But OSX itself seems to not like this.

Understood there's no solution, just throwing my name in the list of folks who are curious if/when one becomes available.

Michael

Sent from my iPad

[strobe33333]

I have the same problem as the OP where I can nslookup/dig successfully but ping/curl/etc fail.  I'm using set nameserver.  /etc/resolv.conf and the dns servers are correctly set in network settings by tunnelblick. 

Anyone ever figure out what was causing this? 

Thanks 

[jkbull...gmail.com]

Perhaps it is a failure to flush the DNS cache.

Tunnelblick's standard 'Set nameserver' setting does this upon connection and disconnection. However, certain settings could inhibit this. Another possibility is that, because connecting to a TAP with DHCP is (by default) an asynchronous process, perhaps Tunnelblick is flushing the DNS cache and then later getting and caching DNS info, and then even later, when DHCP info is received, setting DNS but not flushing the cache again. This is just speculation – examine the standard Tunnelblick scripts that implement 'Set nameserver' to see if this is correct.

These are some Tunnelblick options that could be involved: -doNotFlushCache, -useRouteUpInsteadOfUp, and -waitForDHCPInfoIfTap –see Preferences 3.3 & 3.4.

[bgwal...@gmail.com]

I just thought I'd add some additional clarity for anyone who may be having an issue with being unable to ping their local hostname-only devices (e.g. Your-NAS, Your-MBP, etc.) on their network when connected over VPN, you can add the command below to your OpenVPN server config which should resolve the issue.

push "dhcp-option DOMAIN local"

I'm running OpenVPN on my Tomato-enabled router, so I simply added the above line to the Custom Configuration field which is located under VPN Tunneling > OpenVPN Server > Server # > Advanced tab.

It's noteworthy to mention this isn't absolutely necessary to perform this action as you can always ping using the FQDN (e.g. Your-NAS.local, Your-MBP.local), but it makes things easier and more uniform with how things already work when you're not connected over VPN.  Hope this helps.

Best regards,

Brad

[jkbull...gmail.com]

Thank you for sharing your solution!

I believe that instead of adding

     push "dhcp-option DOMAIN local"

to the server configuration, you could add

     dhcp-option DOMAIN local

to the client configuration.

[cracker...@gmail.com]

you can also use the following line if you're not using FQDN and don't want a search domain...

dhcp-option DOMAIN .