The user was trying to connect to his VPN at our remote site. He uses Windows 7 and a split-tunneling VPN and has connected with no problems many times before. He connected successfully but no DNS. I try rebooting the computer, renewing the IP addresses (w ipconfig /renew, ipconfig /release), flushing the dns, nothing. I get out the Wireshark, don't see anything unusual, although I'm wondering if I failed to capture one of the DNS failures.
I am unable to 100% verify that the problem is on our end, but the user goes home, boots up, everything works. Comes back and everything works again. So, my question has 2 parts:
What is the likely cause?
What do I do if it happens again?
For the likely cause, my suspects are Comcast DNS and my Sonicwall TZ210 firewall, in that order. My Sonicwall isn't going to mess with his VPN, but wondering if it could be misdirecting his DNS requests to the VPN. Comcast could be doing the same thing, and that seems more likely to me. There's a small chance the error was with the VPN client at the user's office, but it seems unlikely to me.
On what to do if it happens again, here's my thoughts so far: run him briefly outside the firewall to see if that clears things up. Use another DNS provider (I think Google is like 8.8.8.8). Rebuild his TCP/IP stack with netsh (is this really a good idea?).
Any suggestions, or just validations, would be welcome.
Best Answer
I've seen problems with split-tunnelling due to DNS servers that don't send errors when they can't resolve an address.
My understanding of the split tunnel is that the VPN driver directs DNS queries to one side of the tunnel first. If the query fails then it switches to the other side of the tunnel and tries again.
The problem I've seen happens when the VPN driver tries the local side of the tunnel first, and the user's DNS server doesn't return an error code properly. This happens more these days because many ISP are trying to provide a friendly DNS service where, instead of returning a DNS error if the query can't be resolved, they return a search page. This is nice in a browser, but breaks split-tunnel VPN. The VPN driver assumes the response means that the resource the user is looking for is on the local side of the tunnel, so it never gets to check the VPN side.
One solution is to change to Google's DNS, which does report errors correctly.
Another solution is to switch the order of the look-up in VPN driver. Presumably you control the DNS on the VPN side of the tunnel, and can ensure it behaves properly. If the VPN driver can't get a DNS resolution on the VPN side of the tunnel, then it will switch back to the local side.