Hello,
Recently signed up for VPN service and started using Viscosity 1.4.4 on Mac OS 10.8.4, on a MacBook Pro, and having an odd problem… I can connect to my VPN no problem, things are going great for anywhere from 2-6 hours. Then the system just hangs.
Applications (and the finder) ony by one, show the spinning beachball. If I can bring up the force quit dialog, applications start to show as ‘not responding’, but they can’t be forced to quit. New apps can’t be launched. I left terminal running but even that was unresponsive. The Apple->Restart menu doesn’t even work, the only way out is a hard reboot (hold down the power button).
According to its menu, Viscosity is still connected to the VPN. The frustrating thing is that I have to connect for several hours to try to duplicate the problem, and its hard to troubleshoot real time since applications don’t respond.
What you describe sounds like your DNS resolution has failed. When Mac OS X knows it has an Internet connection, but can’t reach the DNS server/s set, it tends to result in system wide hangs (every time Mac OS X or an app tries to resolve a network address it results in the system hanging for around 30 seconds until the request times out). My recommendation would be to manually set the DNS servers your VPN connection is using to Google’s public DNS servers (or OpenDNS’s servers) as detailed in the article here: http://www.sparklabs.com/support/configuring_dns_and_wins_setti/
Alternatively you can turn off DNS support altogether (under the Networking tab when editing your connection in Viscosity) to confirm it is a DNS problem. If DNS support is off your normal system DNS servers will be used while connected to the VPN connection.
James,
DNS server failure sounds like it would explain the problem. I tried your suggestion, manually setting the DNS servers in the VPN connection to Google’s public servers. In my config, Enable DSN Support was checked, but the DNS Servers field was empty, so I entered the Google servers “8.8.8.8, 8.8.4.4”. I also verified that “Send all traffic over VPN connection” was checked.
Unfortunately that hasn’t solved the problem.
Poking around the forums and found references to the terminal command “scutil --dns”. The results I get for resolver #1 are the same whether I’m connected or disconnected to the VPN, which seems odd. Resolver #1 always lists the 4 DNS servers that are configured in the Network panel of System Preferences. When the VPN is connected, shouldn’t it only show the 2 public Google servers that were manually entered into Viscosity?
The other info that may help, is that the Viscosity settings were supplied by my VPN provider (PIA), and these settings are in the Advanced tab, not sure what they do:
remote-cert-tls server
tls-client
reneg-sec 0
resolv-retry infinite
The results I get for resolver #1 are the same whether I’m connected or disconnected to the VPN, which seems odd. Resolver #1 always lists the 4 DNS servers that are configured in the Network panel of System Preferences. When the VPN is connected, shouldn’t it only show the 2 public Google servers that were manually entered into Viscosity?
It sounds like you may have the “Apply DNS settings simultaneously” option turned on (under Preferences->Advanced). If so, how do you get on turning this option off?
Here’s the output, about 5 minutes after connecting to the VPN. The 4 DNS servers are defined in system preferences, while the same 2 google servers are defined in Viscosity:
I think one of the following must be occurring in regards to your DNS settings:
The “Enable DNS support” checkbox is un-ticked for your connection (under the Networking tab when editing), or;
Your VPN Provider is pushing out the OpenDNS servers (i.e. 208.67.222.222 and 208.67.220.220). Viscosity will list DNS servers set locally first, followed by servers sent by the VPN server. So if you’ve set Google’s servers locally, and they’ve pushed out OpenDNS’s servers (not uncommon), you’ll end up with the same list. You may like to test this by setting a different DNS server instead of Google’s and see if the list changes (such as one of your ISP’s DNS servers).
Well that’s one mystery solved!
Enable DNS support IS checked in my configuration. It turns out my VPN provider and I were using the same exact DNS servers, they were pushing them out to me.
However we’re back at square 1, since I still have the problem described in my original post.
Well we’ve confirmed the DNS servers are getting set, and as they are public DNS servers they should be reachable through both your VPN connection as well as your local network connection. Because of this I think the likely explanation is that your VPN connection is dropping out, however OpenVPN (and hence Viscosity) thinks it is still active (and so Mac OS X is still trying to use it). Any DNS requests will attempt to go through the dead VPN connection, which will obviously fail and cause Mac OS X to hang until the DNS lookup times out.
Viscosity is smart and will check the reachability of the remote VPN server whenever a network change occurs, and disconnect it if it is no longer reachable. However because Viscosity isn’t disconnecting your connection it means there isn’t a network problem on your computer. The dropouts are likely being caused by your router, your ISP, or your VPN provider’s server dropping.
Now normally when a drop out occurs OpenVPN should detect it and either disconnect or initiate a reconnection attempt (depending on how it is configured). For UDP connections it does this by sending out a “ping” (normally every minute or two) to check that the connection is still alive and active (you can see the OpenVPN Man Page for more information). However if the time between the pings is too large, OpenVPN may take too long to detect the drop out, and you’ll end up with Mac OS X trying to do DNS lookups through a dead VPN connection. We’ve also seen some VPN Service Providers stop OpenVPN’s ping/ping-restart behaviour altogether, which is especially bad.
My recommendation would be to see if your VPN Service Provider has any TCP based connections for you to connect to (TCP is better for detecting dropouts), or to try with a different VPN Service Provider to see if you still have the same problem (they may have configured their ping keepalive values to something better suited).
Cheers,
James
SparkLabs Newsletter
Thank you for being interested in keeping up with the latest news from us! Please double-check your email address below and then click the Subscribe button.
