DNS problem (DNS don't change despite "change DNS" set)
5,675 views
Skip to first unread message
Xavier Spirlet
Jan 27, 2017, 6:29:15 AM1/27/17
to tunnelblick-discuss
Hi all,
I'm having trouble connecting from my school's LAN to my VPN. It used to work but doesn't now, though no changes have been made to the VPN or LAN setups.
- LAN settings : DHCP, with a received address 10.59.16.170 (netmask 255.255.254.0 - gw 10.59.16.254). DNS are given by DHCP and are 10.59.26.111, 10.7.0.100 and 10.59.17.200). This may sound odd, but these are working settings here. Never mind.
- Tunnelblick connects then gives a warning about DNS not working and indeed, name resolving is broken. I can connect with IP addresses but no with domain names. NSlookup also states that NS are still the one DHCP had set. Bollocks.
- Debug info is below, but I'll already say that everything is checked in parameters: Change DNS/WINS is set to "Change name server" but no other choice (3.1, 3.0, alt1…) change anything. Other options (check network parameters, route all IPv4 traffic, deactivate IPv6, check if public IP has chnged, reset primary interface after disconnect) are checked too.
I searched this group and messed a bit with the parameters, but I'm stuck, here.
Please, please help !!!
Thanks in advance.
Debug info :
*Tunnelblick: OS X 10.12.3; Tunnelblick 3.6.10 (build 4760); prior version 3.6.9 (build 4685); Admin usergit commit 9f798839bcb9c9aaaa46591e672280e6bee491a4
Configuration petitpoisson-openvpn
"Sanitized" condensed configuration file for /Users/xs/Library/Application Support/Tunnelblick/Configurations/petitpoisson-openvpn.tblk:
dev tuntls-clientremote petitpoisson.myds.me 8080pullproto tcp-clientscript-security 2ca ca.crtcomp-lzoreneg-sec 0auth-user-pass
================================================================================
Non-Apple kexts that are loaded:
Index Refs Address Size Wired Name (Version) UUID <Linked Against> 131 0 0xffffff7f80a22000 0x34000 0x34000 com.paragon-software.filesystems.ntfs (318.3.14) F6A7BB1D-5A30-3EAA-9644-77F98E29F1AE <7 5 4 1> 137 0 0xffffff7f80c47000 0x7000 0x7000 com.avira.kext.FileAccessControl (1.2.5) FB07160A-508D-3739-8548-4E1197D1DF37 <5 4 3 1> 152 0 0xffffff7f84705000 0x9000 0x9000 com.asix.driver.ax88179-178a (1.8.0) 18E125DD-F66C-31C1-8C66-552F9CE8F501 <51 39 7 5 4 3 1>
================================================================================
There are no unusual files in petitpoisson-openvpn.tblk
================================================================================
Configuration preferences:
useDNS = 1-resetPrimaryInterfaceAfterDisconnect = 1-routeAllTrafficThroughVpn = 1-useRouteUpInsteadOfUp = 1-keychainHasUsernameAndPassword = 1-openvpnVersion = -lastConnectionSucceeded = 1
================================================================================
Wildcard preferences:
================================================================================
Program preferences:
launchAtNextLogin = 1notOKToCheckThatIPAddressDidNotChangeAfterConnection = 0askedUserIfOKToCheckThatIPAddressDidNotChangeAfterConnection = 1tunnelblickVersionHistory = ( "3.6.10 (build 4760)", "3.6.9 (build 4685)")lastLaunchTime = 507196862.722834doNotShowNotificationWindowOnMouseover = 1doNotShowDisconnectedNotificationWindows = 1lastLanguageAtLaunchWasRTL = 0connectionWindowDisplayCriteria = showWhenConnectingmaxLogDisplaySize = 102400lastConnectedDisplayName = petitpoisson-openvpnkeyboardShortcutIndex = 0updateCheckAutomatically = 1updateSendProfileInfo = 1NSWindow Frame ConnectingWindow = 765 755 389 187 0 0 1920 1177 detailsWindowFrameVersion = 4760detailsWindowFrame = {{445, 148}, {920, 902}}detailsWindowLeftFrame = {{0, 0}, {165, 784}}detailsWindowViewIndex = 0detailsWindowConfigurationsTabIdentifier = settingsleftNavSelectedDisplayName = petitpoisson-openvpnAdvancedWindowTabIdentifier = connectingAndDisconnectinghaveDealtWithSparkle1dot5b6 = 1haveDealtWithOldTunTapPreferences = 1haveDealtWithOldLoginItem = 1SUEnableAutomaticChecks = 1SUFeedURL = https://www.tunnelblick.net/appcast-s.rssSUScheduledCheckInterval = 86400SUSendProfileInfo = 1SULastCheckTime = 2017-01-27 08:01:02 +0000SULastProfileSubmissionDate = 2017-01-23 10:42:42 +0000SUHasLaunchedBefore = 1WebKitDefaultFontSize = 16WebKitStandardFont = Times
================================================================================
Tunnelblick Log:
*Tunnelblick: OS X 10.12.3; Tunnelblick 3.6.10 (build 4760); prior version 3.6.9 (build 4685)2017-01-27 12:15:14 *Tunnelblick: Attempting connection with petitpoisson-openvpn using shadow copy; Set nameserver = 769; monitoring connection2017-01-27 12:15:14 *Tunnelblick: openvpnstart start petitpoisson-openvpn.tblk 1337 769 0 1 0 1099568 -ptADGNWradsgnw 2.3.14-openssl-1.0.2j2017-01-27 12:15:14 *Tunnelblick: openvpnstart log: OpenVPN started successfully. Command used to start OpenVPN (one argument per displayed line): /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.14-openssl-1.0.2j/openvpn --daemon --log /Library/Application Support/Tunnelblick/Logs/-SUsers-Sxs-SLibrary-SApplication Support-STunnelblick-SConfigurations-Spetitpoisson--openvpn.tblk-SContents-SResources-Sconfig.ovpn.769_0_1_0_1099568.1337.openvpn.log --cd /Library/Application Support/Tunnelblick/Users/xs/petitpoisson-openvpn.tblk/Contents/Resources --verb 3 --config /Library/Application Support/Tunnelblick/Users/xs/petitpoisson-openvpn.tblk/Contents/Resources/config.ovpn --verb 3 --cd /Library/Application Support/Tunnelblick/Users/xs/petitpoisson-openvpn.tblk/Contents/Resources --management 127.0.0.1 1337 --management-query-passwords --management-hold --redirect-gateway def1 --script-security 2 --route-up /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -9 -d -f -m -r -w -ptADGNWradsgnw --down /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -9 -d -f -m -r -w -ptADGNWradsgnw
End of output from client.down.tunnelblick.sh **********************************************2017-01-27 12:15:14 *Tunnelblick: Established communication with OpenVPN2017-01-27 12:15:14 *Tunnelblick: Obtained VPN username and password from the Keychain2017-01-27 12:15:14 OpenVPN 2.3.14 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [PKCS11] [MH] [IPv6] built on Jan 14 20172017-01-27 12:15:14 library versions: OpenSSL 1.0.2j 26 Sep 2016, LZO 2.092017-01-27 12:15:14 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:13372017-01-27 12:15:14 Need hold release from management interface, waiting...2017-01-27 12:15:14 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:13372017-01-27 12:15:14 MANAGEMENT: CMD 'pid'2017-01-27 12:15:14 MANAGEMENT: CMD 'state on'2017-01-27 12:15:14 MANAGEMENT: CMD 'state'2017-01-27 12:15:14 MANAGEMENT: CMD 'bytecount 1'2017-01-27 12:15:14 MANAGEMENT: CMD 'hold release'2017-01-27 12:15:14 MANAGEMENT: CMD 'username "Auth" "poissonvpn"'2017-01-27 12:15:14 MANAGEMENT: CMD 'password [...]'2017-01-27 12:15:14 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.2017-01-27 12:15:14 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts2017-01-27 12:15:14 Socket Buffers: R=[131072->131072] S=[131072->131072]2017-01-27 12:15:14 MANAGEMENT: >STATE:1485515714,RESOLVE,,,2017-01-27 12:15:14 Attempting to establish TCP connection with [AF_INET]62.197.112.214:8080 [nonblock]2017-01-27 12:15:14 MANAGEMENT: >STATE:1485515714,TCP_CONNECT,,,2017-01-27 12:15:14 *Tunnelblick: openvpnstart starting OpenVPN2017-01-27 12:15:15 TCP connection established with [AF_INET]62.197.112.214:80802017-01-27 12:15:15 TCPv4_CLIENT link local: [undef]2017-01-27 12:15:15 TCPv4_CLIENT link remote: [AF_INET]62.197.112.214:80802017-01-27 12:15:15 MANAGEMENT: >STATE:1485515715,WAIT,,,2017-01-27 12:15:15 MANAGEMENT: >STATE:1485515715,AUTH,,,2017-01-27 12:15:15 TLS: Initial packet from [AF_INET]62.197.112.214:8080, sid=3124b984 cfc866192017-01-27 12:15:15 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this2017-01-27 12:15:15 VERIFY OK: depth=1, C=TW, ST=Taiwan, L=Taipei, O=Synology Inc., OU=Certificate Authority, CN=Synology Inc. CA, emailAddress=pro...@synology.com2017-01-27 12:15:15 VERIFY OK: depth=0, C=TW, ST=Taiwan, L=Taipei, O=Synology Inc., OU=FTP Team, CN=synology.com, emailAddress=pro...@synology.com2017-01-27 12:15:16 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key2017-01-27 12:15:16 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).2017-01-27 12:15:16 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication2017-01-27 12:15:16 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key2017-01-27 12:15:16 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).2017-01-27 12:15:16 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication2017-01-27 12:15:16 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA2017-01-27 12:15:16 [synology.com] Peer Connection Initiated with [AF_INET]62.197.112.214:80802017-01-27 12:15:17 MANAGEMENT: >STATE:1485515717,GET_CONFIG,,,2017-01-27 12:15:18 SENT CONTROL [synology.com]: 'PUSH_REQUEST' (status=1)2017-01-27 12:15:18 PUSH: Received control message: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0,route 10.8.0.0 255.255.255.0,route 10.8.0.1,topology net30,ping 10,ping-restart 60,ifconfig 10.8.0.6 10.8.0.5'2017-01-27 12:15:18 OPTIONS IMPORT: timers and/or timeouts modified2017-01-27 12:15:18 OPTIONS IMPORT: --ifconfig/up options modified2017-01-27 12:15:18 OPTIONS IMPORT: route options modified2017-01-27 12:15:18 Opening utun (connect(AF_SYS_CONTROL)): Resource busy2017-01-27 12:15:18 Opened utun device utun12017-01-27 12:15:18 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=02017-01-27 12:15:18 MANAGEMENT: >STATE:1485515718,ASSIGN_IP,,10.8.0.6,2017-01-27 12:15:18 /sbin/ifconfig utun1 delete ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address2017-01-27 12:15:18 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure2017-01-27 12:15:18 /sbin/ifconfig utun1 10.8.0.6 10.8.0.5 mtu 1500 netmask 255.255.255.255 up2017-01-27 12:15:18 /sbin/route add -net 62.197.112.214 10.59.16.254 255.255.255.255 add net 62.197.112.214: gateway 10.59.16.2542017-01-27 12:15:18 /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.52017-01-27 12:15:18 /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.52017-01-27 12:15:18 MANAGEMENT: >STATE:1485515718,ADD_ROUTES,,,2017-01-27 12:15:18 /sbin/route add -net 192.168.1.0 10.8.0.5 255.255.255.0 add net 192.168.1.0: gateway 10.8.0.52017-01-27 12:15:18 /sbin/route add -net 10.8.0.0 10.8.0.5 255.255.255.0 add net 10.8.0.0: gateway 10.8.0.52017-01-27 12:15:18 /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 ********************************************** Start of output from client.up.tunnelblick.sh NOTE: No network configuration changes need to be made. WARNING: Will NOT monitor for other network configuration changes. WARNING: Will NOT disable IPv6 settings. DNS servers '10.59.26.111 10.7.0.100 10.59.17.200' will be used for DNS queries when the VPN is active NOTE: The DNS servers do not include any free public DNS servers known to Tunnelblick. This 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 End of output from client.up.tunnelblick.sh **********************************************2017-01-27 12:15:20 Initialization Sequence Completed2017-01-27 12:15:20 MANAGEMENT: >STATE:1485515720,CONNECTED,SUCCESS,10.8.0.6,62.197.112.2142017-01-27 12:15:21 *Tunnelblick: No 'connected.sh' script to execute2017-01-27 12:16:01 *Tunnelblick: After 30.0 seconds, gave up trying to fetch IP address information using the ipInfo host's name after connecting.2017-01-27 12:16:02 *Tunnelblick: fetched IP address information using the ipInfo host's IP address after connecting.2017-01-27 12:16:58 *Tunnelblick: Disconnecting; VPN Details… window disconnect button pressed2017-01-27 12:16:58 *Tunnelblick: No 'pre-disconnect.sh' script to execute2017-01-27 12:16:58 *Tunnelblick: Disconnecting using 'kill'2017-01-27 12:16:58 event_wait : Interrupted system call (code=4)2017-01-27 12:16:58 /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.52017-01-27 12:16:58 /sbin/route delete -net 10.8.0.0 10.8.0.5 255.255.255.0 delete net 10.8.0.0: gateway 10.8.0.52017-01-27 12:16:58 /sbin/route delete -net 192.168.1.0 10.8.0.5 255.255.255.0 delete net 192.168.1.0: gateway 10.8.0.52017-01-27 12:16:58 /sbin/route delete -net 62.197.112.214 10.59.16.254 255.255.255.255 delete net 62.197.112.214: gateway 10.59.16.2542017-01-27 12:16:58 /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.52017-01-27 12:16:58 /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.52017-01-27 12:16:58 Closing TUN/TAP interface2017-01-27 12:16:58 /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -9 -d -f -m -r -w -ptADGNWradsgnw utun1 1500 1544 10.8.0.6 10.8.0.5 init ********************************************** Start of output from client.down.tunnelblick.sh WARNING: Not restoring DNS settings because no saved Tunnelblick DNS information was found. 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 Resetting primary interface 'en8' via ifconfig en8 down/up...2017-01-27 12:17:02 SIGTERM[hard,] received, process exiting2017-01-27 12:17:02 MANAGEMENT: >STATE:1485515822,EXITING,SIGTERM,,2017-01-27 12:17:03 *Tunnelblick: No 'post-disconnect.sh' script to execute2017-01-27 12:17:03 *Tunnelblick: Expected disconnection occurred.
================================================================================
"Sanitized" full configuration file
dev tuntls-client
remote petitpoisson.myds.me 8080
# The "float" tells OpenVPN to accept authenticated packets from any address,# not only the address which was specified in the --remote option.# This is useful when you are connecting to a peer which holds a dynamic address# such as a dial-in user or DHCP client.# (Please refer to the manual of OpenVPN for more information.)
#float
# If redirect-gateway is enabled, the client will redirect it's# default network gateway through the VPN.# It means the VPN connection will firstly connect to the VPN Server# and then to the internet.# (Please refer to the manual of OpenVPN for more information.)
#redirect-gateway def1
# dhcp-option DNS: To set primary domain name server address.# Repeat this option to set secondary DNS server addresses.
#dhcp-option DNS DNS_IP_ADDRESS
pull
# If you want to connect by Server's IPv6 address, you should use# "proto udp6" in UDP mode or "proto tcp6-client" in TCP modeproto tcp-client
script-security 2
ca ca.crt
comp-lzo
reneg-sec 0
auth-user-pass
================================================================================
ifconfig output:
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP> inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 nd6 options=201<PERFORMNUD,DAD>gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280stf0: flags=0<> mtu 1280en0: flags=8823<UP,BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 1500 ether 78:4f:43:5c:b9:7c nd6 options=201<PERFORMNUD,DAD> media: autoselect (<unknown type>) status: inactiveen1: flags=963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX> mtu 1500 options=60<TSO4,TSO6> ether 62:00:e5:39:f6:00 media: autoselect <full-duplex> status: inactiveen2: flags=963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX> mtu 1500 options=60<TSO4,TSO6> ether 62:00:e5:39:f6:04 media: autoselect <full-duplex> status: inactiveen3: flags=963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX> mtu 1500 options=60<TSO4,TSO6> ether 62:00:e5:39:f6:01 media: autoselect <full-duplex> status: inactiveen4: flags=963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX> mtu 1500 options=60<TSO4,TSO6> ether 62:00:e5:39:f6:05 media: autoselect <full-duplex> status: inactivep2p0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 2304 ether 0a:4f:43:5c:b9:7c media: autoselect status: inactiveawdl0: flags=8902<BROADCAST,PROMISC,SIMPLEX,MULTICAST> mtu 1484 ether 4e:7b:a5:4b:16:38 nd6 options=201<PERFORMNUD,DAD> media: autoselect status: inactivebridge0: flags=8822<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 1500 options=63<RXCSUM,TXCSUM,TSO4,TSO6> ether 62:00:e5:39:f6:00 Configuration: id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0 maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200 root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0 ipfilter disabled flags 0x2 member: en1 flags=3<LEARNING,DISCOVER> ifmaxaddr 0 port 5 priority 0 path cost 0 member: en2 flags=3<LEARNING,DISCOVER> ifmaxaddr 0 port 6 priority 0 path cost 0 member: en3 flags=3<LEARNING,DISCOVER> ifmaxaddr 0 port 7 priority 0 path cost 0 member: en4 flags=3<LEARNING,DISCOVER> ifmaxaddr 0 port 8 priority 0 path cost 0 media: <unknown type> status: inactiveutun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 2000 inet6 fe80::bb2d:7568:bbbb:6c84%utun0 prefixlen 64 scopeid 0xd nd6 options=201<PERFORMNUD,DAD>en7: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether ac:de:48:00:11:22 inet6 fe80::aede:48ff:fe00:1122%en7 prefixlen 64 scopeid 0xc nd6 options=281<PERFORMNUD,INSECURE,DAD> media: autoselect status: activeen8: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 options=b<RXCSUM,TXCSUM,VLAN_HWTAGGING> ether 00:0e:c6:c7:d0:b7 nd6 options=201<PERFORMNUD,DAD> media: autoselect (<unknown type>) status: inactive
================================================================================
Console Log:
2017-01-27 09:01:00 Tunnelblick[593] Tunnelblick: OS X 10.12.3; Tunnelblick 3.6.10 (build 4760)2017-01-27 09:01:01 Tunnelblick[593] Warning: preferences contain unknown preference 'NSWindow Frame SUUpdateAlert'2017-01-27 09:01:01 Tunnelblick[593] Warning: preferences contain unknown preference 'NSStatusItem Preferred Position Item-0'2017-01-27 09:01:01 Tunnelblick[593] Set program update feedURL to https://www.tunnelblick.net/appcast-s.rss2017-01-27 12:15:14 Tunnelblick[593] Keychain item retrieved successfully for service = 'Tunnelblick-Auth-petitpoisson-openvpn' account = 'username'2017-01-27 12:15:14 Tunnelblick[593] Keychain item retrieved successfully for service = 'Tunnelblick-Auth-petitpoisson-openvpn' account = 'password'2017-01-27 12:16:01 Tunnelblick[593] currentIPInfo(Name): IP address info could not be fetched within 35.6 seconds; the error was 'Error Domain=NSURLErrorDomain Code=-1001 "La requête a expiré." UserInfo={NSUnderlyingError=0x618000258d50 {Error Domain=kCFErrorDomainCFNetwork Code=-1001 "La requête a expiré." UserInfo={NSErrorFailingURLStringKey=https://www.tunnelblick.net/ipinfo, NSErrorFailingURLKey=https://www.tunnelblick.net/ipinfo, _kCFStreamErrorCodeKey=-2102, _kCFStreamErrorDomainKey=4, NSLocalizedDescription=La requête a expiré.}}, NSErrorFailingURLStringKey=https://www.tunnelblick.net/ipinfo, NSErrorFailingURLKey=https://www.tunnelblick.net/ipinfo, _kCFStreamErrorDomainKey=4, _kCFStreamErrorCodeKey=-2102, NSLocalizedDescription=La requête a expiré.}'; the response was '(null)'
Tunnelblick developer
Jan 27, 2017, 7:10:19 AM1/27/17
to tunnelblick-discuss
It looks like everything is routed through the VPN but that the nameserver is not changed. That can be a problem; here is what happens:
- You have a DNS server from your school's LAN (set up via DHCP).
- You connect to a VPN and route all traffic through the VPN.
- Your computer does a DNS query.
- The query goes through the VPN.
- To the school's DNS server, the query seems to originate from the VPN server.
- The VPN server is not part of the school's network, so the nameserver ignores the query.
There's a quick way to see if this is what is happening: change your nameserver to Google DNS (8.8.8.8 and 8.8.4.4) -- if you don't want to use Google, try OpenDNS or another public DNS service. If everything works, then the problem I described above was what was happening.
If it used to work and now doesn't, probably your school's nameserver used to allow queries originating outside of the school's LAN and has now stopped doing so.
The usual solution to this problem is to have a nameserver on your VPN's LAN, and set up OpenVPN to use that nameserver. That is usually done by having the VPN server push the "dhcp-option DNS a.b.c.d" OpenVPN options to the client, where "a.b.c.d" is the IP address of the DNS server.
I'm not an OpenVPN expert, but there should be lots of tutorials and how-to articles about how to set up an OpenVPN server; this DNS stuff is usually part of that.
(Also: thanks for all your help translating Tunnelblick!)
Tunnelblick developer
Jan 27, 2017, 7:19:47 AM1/27/17
to tunnelblick-discuss
Sorry, I should have clarified the "Set DNS/WINS" settings:
- "Set nameserver" tells Tunnelblick to use a script that performs nameserver changes that OpenVPN tells it to. In your situation, OpenVPN isn't telling Tunnelblick to make any changes, so Tunnelblick doesn't make any changes.
- "Do not set nameserver" tells Tunnelblick to ignore changes that OpenVPN tells it to.
- The other settings for "Set DNS/WINS" are rarely used. They change the nameserver using different mechanisms because old versions of OS X used different ways of doing it. They are sometimes used for very old VPN setups that don't work with the standard "Set nameserver" setting.
And I should have said that you can put the "dhcp-option DNS a.b.c.d" line in the configuration file on your client computer, instead of having it pushed from the VPN server.
Xavier Spirlet
Jan 27, 2017, 8:15:08 AM1/27/17
to tunnelbli...@googlegroups.com
Quite clear, indeed :-)
I just added dhcp-options DNS 8.8.8.8 (I don’t mind Google) to OpenVPN config file on my client, and yepee it works!
Many thanks :-)
Maybe it could be useful to have a configuration option in the VPN Details window to override that setting? I may be wrong but it seems like that kind of problem could happen often and it’d be nice to have a graphical interface rather that having to modify a text file?
Thanks again.
++
. . . . . . . . . . . . . . . . . .
. Xavier Spirlet
. Petitpoisson
. Design graphique - Création web - Informatique
. TVA BE 0886 981 955
. OpenPGP public key : http://www.petitpoisson.be/xavier-pubkey.asc
.
Tunnelblick developer
Jan 27, 2017, 8:36:07 AM1/27/17
to tunnelblick-discuss
This problem is somewhat unusual because it is really just a misconfiguration of OpenVPN.
Most OpenVPN setups "push" an internal nameserver that is on the VPN server's LAN (and, for security reasons, should be the same IP address as the OpenVPN server's LAN IP address). That's usually the "right" way to solve the problem and it allows access to the LAN's servers by name, which is helpful when connecting TO a corporate or university network.
But it's an interesting idea.
I could add a "Use DNS from" drop-down button that has a list of public DNS servers from the list that Tunnelblick uses for other purposes:
Level3 209.244.0.3 209.244.0.4Google 8.8.8.8 8.8.4.4DNS.WATCH 84.200.69.80 84.200.70.40Comodo Secure DNS 8.26.56.26 8.20.247.20OpenDNS Home 208.67.222.222 208.67.220.220DNS Advantage 156.154.70.1 156.154.71.1Norton ConnectSafe 199.85.126.10 199.85.127.10GreenTeamDNS 81.218.119.11 209.88.198.133SafeDNS 195.46.39.39 195.46.39.40OpenNIC 107.150.40.234 50.116.23.211SmartViper 208.76.50.50 208.76.51.51Dyn 216.146.35.35 216.146.36.36FreeDNS 37.235.1.174 37.235.1.177Hurricane Electric 74.82.42.42puntCAT 109.69.8.51Yandex 77.88.8.8 77.88.8.1
I'll have to think about how that would work; there are several questions: one is how to describe it, another is what a good default would be, and a third is whether it should override the nameserver requested by OpenVPN if there is one.
It deserves more thought -- thanks very much for the suggestion!
Xavier Spirlet
Jan 27, 2017, 12:33:11 PM1/27/17
to tunnelbli...@googlegroups.com
I had not understood it as a VPN server config issue. The server here has very little settings (it’s the VPN server package on a Synology box) but I can set the DNS in DSM itself. I’ll be trying different settings next week, it’s an interesting issue actually.
And I’m very glad this issue raised interesting questions for you too :-)
All the best,
--
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/vq9tn_aLqyA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tunnelblick-dis...@googlegroups.com.
Visit this group at https://groups.google.com/group/tunnelblick-discuss.
For more options, visit https://groups.google.com/d/optout.
Tunnelblick developer
Jan 27, 2017, 12:45:18 PM1/27/17
to tunnelblick-discuss
It's a VPN configuration issue, really, not a server configuration issue.
The VPN configuration is really a collaboration between the server and the client, so attributing it to the server isn't really fair, I suppose.
But in general I consider it to be the VPN server's responsibility to send appropriate configuration information to the client so the client will work properly. That's why I think of it as a "server configuration issue".
Xavier Spirlet
Jan 27, 2017, 1:05:04 PM1/27/17
to tunnelbli...@googlegroups.com
I do agree, but in this case, it seems to me that as the VPN server acts a bit like a DHCP server, sending network config info necessary to establish the tunnel. So it seems fair to assume that it should also send DNS information… I know DHCP servers do not always send DNS information (it is actually optional in the DHCPACK message), but in general they do, and they certainly should. My understanding is that VPN servers should too…
--
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/vq9tn_aLqyA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tunnelblick-dis...@googlegroups.com.
Visit this group at https://groups.google.com/group/tunnelblick-discuss.
For more options, visit https://groups.google.com/d/optout.
Xavier Spirlet
Feb 9, 2017, 6:41:57 AM2/9/17
to tunnelbli...@googlegroups.com
OK, I’m still having problems.
After connexion, I get a DNS malfunction warning and DNS resolving does actually not work.
I do have this line in OpenVPN config :
dhcp-option DNS 8.8.8.8
But I see this in Tunnelblick log :
Start of output from client.up.tunnelblick.sh
Disabled IPv6 for 'Minix Gigabit'Disabled IPv6 for 'Wi-Fi'Retrieved from OpenVPN: name server(s) [ 8.8.8.8 ], search domain(s) [ ] and SMB server(s) [ ] and using default domain name [ openvpn ]WARNING: Ignoring ServerAddresses '8.8.8.8' because ServerAddresses was set manuallySetting 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
Thing is, my network connection settings (on the Mac) include manually set DNS. But I don’t have DHCP here, so I cannont rely on this, these DNS need to be manually set!
Changing DNS change method in settings does not change anything.
Is there a way to force DNS changing ?
Any idea ?
Thanks ;-)
Tunnelblick developer
Feb 9, 2017, 7:35:33 AM2/9/17
to tunnelblick-discuss
There is no way to get the standard Tunnelblick "Set nameserver" script to override a manual DNS setting.
There have been several discussions over the years about an option to change this behavior, but it has always been decided that someone using manual settings probably knows what they are doing and can deal with the complications such as this.
There is a workaround: you could copy the standard script (/Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh) and modify it to allow overwriting a manually-set DNS servers entry, and then include the modified script in your .tblk (see Using Scripts) so it will be used instead of the standard script.
Modifying the script looks pretty easy: around line 330, change
if [ "${MAN_DNS_SA}" != "" ] ; then
logMessage "WARNING: Ignoring ServerAddresses '$DYN_DNS_SA' because ServerAddresses was set manually"
readonly FIN_DNS_SA="${CUR_DNS_SA}"
else
to
if [1 = 0 ] ; then
logMessage "WARNING: Ignoring ServerAddresses '$DYN_DNS_SA' because ServerAddresses was set manually"
readonly FIN_DNS_SA="${CUR_DNS_SA}"
else
You might need to similarly change the code for other networking options that are ignored when set manually; the code is nearby, in roughly lines 390 - 370.https://tunnelblick.net/cUsingScripts.html
Xavier Spirlet
Feb 9, 2017, 9:15:16 AM2/9/17
to tunnelbli...@googlegroups.com
Thanks for the answer.
I solved the problem otherwise : I added Google DNS in my fixed IP settings. It is not reacheable when simply connected to the network but there are 2 other DNS (from the LAN) that work in this case. Whenever I’m connected with VPN, those 2 DNS stop working but the Google DNS becomes reacheable, so that’s it.
I could have thought about that myself, sorry for the inconvenience. I’m posting this answer, though, so others can find my solution if searching for the same issue ;-)
Thanks again !
--
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/vq9tn_aLqyA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tunnelblick-dis...@googlegroups.com.
Visit this group at https://groups.google.com/group/tunnelblick-discuss.
For more options, visit https://groups.google.com/d/optout.
Tunnelblick developer
Jul 30, 2017, 3:27:57 PM7/30/17
to tunnelblick-discuss
On Thursday, February 9, 2017 at 7:35:33 AM UTC-5, Tunnelblick developer wrote:
There is no way to get the standard Tunnelblick "Set nameserver" script to override a manual DNS setting.
This is no longer true. Tunnelblick 3.7.2beta01 and later have a checkbox to "Allow changes to manually-set network settings" in the "Advanced" settings window.
Reply all
Reply to author
Forward
0 new messages