Over the last few days I’ve been running into a problem with Mac OS 10.6 clients and the SonicWall SSL VPN client, NetExtender. The client computers were able to resolve DNS properly prior to installation. The problem didn’t appear until after the software was connected to a endpoint, and then disconnected. Once the connection was ended, boom, no DNS resolution.
I had already updated the endpoint device, a SRA 1200, and the NetExtender was whatever version came with SRA 1200 firmware SonicOS SSL-VPN 4.0.0.3-20sv, which was the most recent firmware available at the time of writing.
I started with a review of the release notes of the SonicWall firmware, which mention a problem with Mac OS prior to version 10.6.5 and NetExtender. I updated one of the client Macs to 10.6.5, but still no luck.
A call to SonicWall ended up with them giving me a new version of the NetExtender software for the Mac, version 5.0.680. I updated the first client and Success! I was able to connect, disconnect, and then continue to resolve DNS.
I thought my problems were over until I re-connected to test that the VPN was still working. Now on version 5.0.680 I was unable to resolve DNS on the other end of the VPN tunnel when connected. I could resolve DNS on my local subnet, and on the internet, but I was unable to resolve anything on the internal DNS servers at the main office that I was connecting to. I verified that I could telnet to port 53 across the tunnel, a NSlookup test proved that I the records I was looking for did exist.
I flushed the dns cache, I verified the /etc/resolv.conf file had the two DNS servers that the NetExtender had placed in there when I connected, and I verified with telnet that a firewall was not blocking DNS to the DNS servers.
I called SonicWall back and after much discussion they recommended that we roll back to version 5.0.679. I downloaded the file, removed the current NetExtender and then attempted to re-install the version 5.0.679. It would not allow me to re-install, stating that a more current version was already installed.
I was able to bypass this error by performing the following:
Drop to Command line and enter the following commands:
sudo rm /private/var/db/receipts/com.sonicwall.NetExtender.bom
sudo rm /private/var/db/receipts/com.sonicwall.NetExtender.plist
sudo rm /etc/ppp/sslvpn.*
I then rebooted the Mac and was able to install NetExtender version 5.0.679. Once installed I tested again. I was able to connect and resolve DNS, good. I was able to disconnect and continue to resolve DNS, even better. And Finally I was able to connect again and continue to resolve DNS still. Version 5.0.679 on Mac OS 10.6.5 was what ended up working for me.
I’ve attached version 5.0.679 for download if you’re experiencing the same problem. NetExtender.MacOSX.5.0.679
Update 1: Upon further review, it appears that NetExtender version 5.0.679 breaks the bonjour protocol on the Macs that it is installed on. To circumvent this problem we actually went back to version 5.0.680, and statically configured a hosts file for all of the major resources on the other end of the VPN tunnel. Click Here to see how to manually edit a hosts file on a Mac. You can download version 5.0.680 here: NetExtender.MacOSX.5.0.680
Update 2: Thomas (see below) pointed out that it doesn’t matter what’s in the resolv.conf file as Mac OS 10.6 and higher no longer uses this file to determine DNS servers. My writing about about double checking this file will have no impact on this particular problem. The rest of the article will still help you work around the problem though, so good luck!
NetExtender.MacOSX.5.0.679
Just wanted to say a huge thank you for posting this – the IT guys we use (PC world) kept telling me it was an issue with my router. Third time it happened I took off all my antivirus in case it was that! Now am going to try downloading the old one and changing things as per your update!!
God bless you for posting this man. Saved the day! My IT guys were a bit puzzled by this dilemma as well. I was just using 5.0.679 and getting an error log of unresolved DNS stuff every time I tried to connect. Right after I grabbed the (very hard to come by) 5.0.680 from you…success! Thank you again! 🙂
It turns out, in Mac OS X 10.6, the DNS client doesn’t use /etc/resolve.conf anymore.
If you run an nslookup or dig it will look up host names from files in the /etc/resolve.conf in order like it is supposed to, but ping and applications use mDNSResponder service for host name resolution. There is an issue where if you manually specify a DNS server in network settings mDNSResponder will ignore all DNS servers configured through DHCP (and therfore, the DNS servers that NetExtender configures).
You will be able to tell if you are experiencing this issue if you can nslookup a host name, but when you ping it you get a “host not found” error.
A workaround for this is to manually add your office’s DNS servers to network settings (again, not /etc/resolve.conf, mDNSResponder ignores these). Of course, when you disconnect you would have to remove them, which is tedious.
Thank you so much, we have been working on this for 4 months with no resolve at all. Wow!
I too had this problem but thanks to your post I was able to install an updated version of netextender (5.0.68) but upon disconnecting and rebooting I was unable to get resolve dns. I tried hard setting the DNS while connected to net extender, then disconnected and rebooted. I was able to get internet after that and removed the DNS entries on the network settings. I rebooted again and I continued to get internet. Thank you for your post!
BIG THANK YOU!! I was getting the error message:
DNS settings could not be restored (SCDynamicStoreCreate failed)
with 5.0.79. Updating to 5.0.80 solved the error!
Has anyone had to deal with the same IP subnet on the SonicWall and remote router?
Macs can’t see the servers on the other side of the VPN when they’re in the same IP range.
Ex:
Mac’s remote router IP is 10.10.10.3
Mac’s NetExterder IP is 10.10.99.20
Server behind the SonicWall 10.10.10.9
Any help is greatly appreciated.
Try adding a “Client Route” under the “NetExtender” section of your Sonic Wall router. You’re probably using a /24 subnet mask in both locations (meaning the office and the client network) so the address will be 255.255.255.0 on the one route back to the main office. The reason why this does not work is because the client wont route to the gateway the traffic that it thinks is local. The way around this is the use a more specific route to get the traffic to the gateway, try adding each server individually to the “Client Routes” section with a /32 mask, this will make the route more specific and it should rate higher in the client’s route table, thereby forcing traffic to that one IP (or collection of individual IPs each with their own /32 mask) out over the vpn tunnel. If this still does not work you can use the route command in the terminal to force the traffic over the vpn to the gateway on the other side, but it’s easier to do in the net extender’s configuration.
Thank you! I don’t understand why Sonicwall can’t provide this kind of information. I wonder what it is I am really paying for with these guys.
I have a client that complains that netextender won’t connect, or if it does that it stays connected intermittently. I wish I could post more details, but it’s the boss and she says it just doesn’t work find something else.
Anyone had any intermittent connectivity issues with netextender.