OpenVPN, Mac OS X and corrupted DNS?

[anklam]

Switched from legacy DSL to FTTN two weeks ago. Started using ovpn.sonic.net from Mac OS X 10.10.5 (Yosemite) last week and it works fine except when the Mac goes to sleep. When waking from sleep I get the message:

ovpn dns error.jpg (29.91 KiB) Viewed 4650 times

This happens whether or not I disconnect from ovpn.sonic.net before the Mac goes to sleep. The only way to recover is to restart the Mac. Logging out and back in does not fix it. I haven't yet tried to flush the DNS cache but one clue is that after waking from sleep the Mac seems to have lost its identity, i.e. it's hostname gets modified into a random string of characters. I have this Mac's networking setup to use a static IP and I'm pointing to the OpenDNS servers 208.67.222.222 and 208.67.220.220 rather than AT&T's DNS servers.

Anyone else see this issue?
Thanks.

UPDATE (2/26): I did a little testing:

1. I noticed that the PACE 5031NV had its DHCP server passing out IP addresses that could collide with the fixed IP's I give a number of the machines on my network. It's currently served range was far below the actual addresses I use, so I don't actually suspect there's a real collision at the moment. I changed the DHCP server range to what my previous routers had used. Unfortunately, this did not effect the OpenVPN behavior reported above.

2. I used OS X Terminal to check the hostname before and after sleep. No issue there. However, after waking from sleep and then attempting to connect to ovpn.sonic.net, the hostname is set to unknown123456789 (the number string is made up for this example). Therefore, it's the OpenVPN app that's corrupting the hostname. Note that a successful connection does not change the hostname.

FOUND THE PROBLEM:
The OpenVPN app is indeed corrupting the hostname, but it's doing so when it exits. After a reboot, the 1st connection attempt always works. But if I disconnect and attempt to reconnect, it fails repeatedly.

Will SONIC send the OpenVPN app writers a bug report? Or should I?

[dct]

We were unable to reproduce these issues on our end with a similar setup, specifically the issue illustrated in your attachment, and the subsequent connection failures after putting the device to sleep.

Do you have another Mac you can test this on?

[anklam]

Yes, I can test on another Mac running OS X 10.10.5.

I also just discovered the following behavior:

When logged into a non-admin account, OpenVPN works on the 1st connect but repeatedly fails after that when attempting to reconnect.

When logged into an admin account, OpenVPN works properly. I can repeatedly connect, disconnect, connect, etc. However, if after disconnecting in the admin account I logout, then login to a non-admin account, even the 1st attempt to connect fails.

[anklam]

I finished testing OpenVPN on a 2011 13" MacBook Pro and a 2008 MacPro. It's on the latter where I was having the problems reported earlier. Both machines are running OS X 10.10.5 (Yosemite) and are fully patched.

On the MacBook Pro I've yet to cause the problems reported previously. I can sleep the MacBook Pro while OpenVPN is connected and upon waking up, OpenVPN is still connected and functioning. I can repeatedly disconnect and reconnect, move between accounts, connect/disconnect. No issues so far.

On the MacPro, I must now report that things seem to have healed themselves. I have no idea what "magic" has occurred, but I cannot now repeat the previous problems. However, I did run into a failed reconnect with the error message shown above. This failure occurred when I attempted to connect when Sophos AntiVirus had just the second before started to download its daily definitions update. Not only did the attempt to connect fail but I lost internet connectivity completely. I had to reboot to clear the problem.

I'll continue the monitor the situation and report back if the problems "magically" return.

[Guest]

Since your MacPro is a desktop, why don't you try using a static IP address or increase your DHCP lease interval to maybe several days to see if the problem is related to DHCP? My guess you're getting different behavior because the NICs are different between your notebook and desktop and they're using different drivers.