DNS resolution issues once connected to VPN

Visto 639 veces
Saltar al primer mensaje no leído

ma...@syple.com.au

no leída,
31 oct 2016, 22:06:0531/10/16
a tunnelblick-discuss
Hi all,

We have been using Tunnelblick for several years without issue, but about 12 months ago (it's taken me a while to get around to asking here!) we began to run into issues.  We can still connect to the VPN fine and the connection works and is stable.  The DNS resolution is not fine though.  Once connected, name resolution takes a long time for both public names and names on the remote network.  Names do eventually resolve but can take several attempts totalling several minutes.  Two things happened around the time the problems began - there was an update to Tunnelblick and we changed ISPs in the office where the VPN server is hosted.  I don't know if either of these triggered the fault.

Here's a summary of my situation:

Tunnelblick 3.6.8 (4625)
OSX 10.11.6 

VPN Disconnected (set via DHCP)
 DNS Server: 10.1.1.1
 Search Domains: lan

VPN Connected
 DNS Server: 10.1.3.3
 Search Domains: openvpn

I tried different "Set DNS/WINS options" values
 Set nameserver - public and remote LAN names resolve slowly 
 Set nameserver (3.1) - Get warning, public and remote LAN names resolve slowly
 Set nameserver (3.0b10) - Get warning, public names resolve immediately, remote LAN names fail immediately
 Set nameserver (alternate 1) - public and remote LAN names resolve slowly

The warning I get on some of these settings is "Tunnelblick could not fetch IP address information before connection was made"

I generated a log using the Set nameserver option:  http://pastebin.com/E66fYTqH

Any help here would be much appreciated!

Thanks,
Matt

Tunnelblick developer

no leída,
31 oct 2016, 22:46:5631/10/16
a tunnelblick-discuss,ma...@syple.com.au
Here's what I can tell you:

(A) You should be using the default "Set nameserver" setting. That is suitable for almost all setups, and it looks correct for your setup.

(B) You should try disabling IPv6 and see if that makes a difference.

(C) Unless I'm misunderstanding the ifconfig output, you are not using Wi-Fi or the built-in Ethernet, you are using something else. Or it is some machine that I am not familiar with (a Mac Pro or iMac, perhaps?). That should be OK, but it is unusual and you might want to try using the VPN using a network connection that is built into the computer.

(D) When you get the "Tunnelblick could not fetch IP address information before connection was made" warning, that means that even before a connection to the VPN was attempted, the computer's networking was having problems. In this situation, it was probably because of a bad recovery from a prior attempt to connect to the VPN using a non-default "Set nameserver" setting. Some of the other "Set nameserver xxx" settings will leave the computer's networking in a bad state. Usually it is enough to disconnect/reconnect the network connection by turning Wi-Fi off and back on, or disconnecting and then reconnecting the Ethernet cable, but sometimes it is necessary to restart the computer. Since it appears that you are not using Wi-Fi or the built-in Ethernet, you probably need to restart the computer to clear this situation.

(E) DNS on OS X (now macOS) works differently from DNS on Windows or Linux. It sends DNS queries to the first nameserver on the list, and waits until that nameserver answers. If an answer is received within 30 seconds, it returns that answer and continues normally. If a response is not received within 30 seconds, it retries the DNS request with the next nameserver on the list. If it just tried the last nameserver on the list, starts over with the first nameserver on the list.

(F) "Not receiving a response within 30 seconds" is what is happening to you. Because your VPN setup only puts a single nameserver on the list (that's not unusual for a VPN), it just tries that one nameserver over and over again. But for some reason that nameserver is not responding in a timely manner.

(G) It is possible (unlikely, though) that it is actually a problem with the nameserver itself.

Questions:
  1. Is anyone else able to use the VPN successfully on a different Mac using Tunnelblick? If so, please provide similar diagnostic info for a successful connect/disconnect cycle on that Mac.

  2. Is anyone able to use the VPN successfully on any other computer? Can you get the output of the VPN log from a successful connect/disconnect cycle?

ma...@syple.com.au

no leída,
31 oct 2016, 23:10:3031/10/16
a tunnelblick-discuss,ma...@syple.com.au
Thanks for such a quick reply.  I'll respond to each of your points.

(A) I use the Set nameserver setting normally.  I just went through the other options as a troubleshooting step.

(B) I normally have IPv6 disabled, but it makes no difference if it is enabled or disabled.

(C) I use a MacBook Pro, which does not have an ethernet port directly on it.  I have an ethernet dongle that plugs into a thunderbolt port.  This is en4 on my machine.  Just in case I unplugged the dongle and tried over WiFi.  No difference.  http://pastebin.com/BzBQgLxD

(D) OK.  I don't get the warning when connecting with the "Set nameserver" option.

(E,F,G) OK.  I did read something to that effect when I was searching in the list and on Google for similar issues.  The symptoms certainly highlight this.  The nameserver is correct (it's a Windows domain controller) and it does _eventually_ resolve.  But for some reason the requests take so long.  Not sure if it's a comms issue between me and that NS or what.  The nameserver works fine inside the remote network, e.g. I can RDP or SSH to a server by IP address, and then from that server, names resolve correctly and reliably.

1) There is one other person using the VPN and they have the same experience as me.
2) There are only two users of the VPN and both use Tunnelblick on Macs.  The log I linked to off my post included requests to a remote LAN website and a public website that timed out a couple of times and eventually succeeded.  There are no machines that can connect without this issue.

Thanks,
Matt
Responder a todos
Responder al autor
Reenviar
Se ha eliminado el mensaje
0 mensajes nuevos