DNS Problems in 4.0.1 Client (Using Win 2K/XP)

[BruceD.Brown]

I've been looking through the VPN forum for others having DNS resolution issues with VPN Client V4.0.1. I have a theory as to the problem, and was interested to see if anyone else has seen this one.

The problem occurs when I first bring up a VPN tunnel, and the DNS & WINS servers etc are all passed to the client. If I immediately try to get to a known working (non-windows) web site where DNS is needed to resolve the name, it will not resolve for about 15 minutes, then out of the blue DNS begins to resolve the names, and the web pages start working correctly.

Everything that uses WINS (email servers etc) work fine, just any sites that rely on DNS to resolve the name. We've been doing a lot of research on this, and have found a problem with the Microsoft DNS cache that they have implemented in W2K and XP. MS has identified a bug (Q286834) (Also described in Knowledge base article 286834) which causes problems when the DNS values are changed on the fly between the original DNS servers to the DNS servers that are provided to the client when the VPN tunnel comes up.

So the PC doesn’t use the newly provided DNS settings until the DNScache gets refreshed. Guess how long this refresh (or reprioritization) period is? Every 15 minutes, which goes back to my original symptoms.

We can work around this by stopping the DNScache and restarting it, which effectively does the same thing, it causes the reprioritization to occur, the new DNS servers get selected, and the DNS resolution begins to work immediately. Even though Microsoft identifies this as a problem only on W2K, we are also seeing it on XP. No other OS's have DNScache. The registry fix they provide does not resolve the problem on XP.

You can see what is in the DNScache (and see the preferred DNS server) by using the dos command:

ipconfig /displaydns

To stop and start the DNScache, you can (from the Dos prompt), do a net stop dnscache, followed by a net start dnscache. You can also stop and restart the service from the list of services page.

I would be interested to see if anyone else is having this problem, and may not realize that it is related to the DNScache. It's taken us quite a while to figure this one out. I had hoped that the VPN client could somehow stop and start this service, since it needs to have correct DNS info when the VPN tunnel comes up, but it's identified as a MS issue and that's where we are at the moment. The solution may be to stop the dnscache service, and leave it off until this gets resolved, but I'm not sure how much of a performance issue this will become. At least then I could start to deploy the V4 clients...

Thanks,

Bruce

[rragineni]

I have same problem witn my VPN clients, i have opened a ticket with TAC but they couldnt resolve my problem. Its been like this since few months, i still dont have solution.

-Ramesh

[jspeegle]

I encountered the same issue with 3.6.x clients on XP as well. It took me a while, but I finally found the same MS article you speak of. I have just had my techs disable the DNS Client service on all effected systems for now.

[cscales]

I'm seeing similar issues with the 4.0.2 client.

Once I connect and try to go to google, it takes about 30-45 seconds for resolution to take place.

Windows 2000 Professional sp4

[BruceD.Brown]

We've continued to do research on this problem, and have discovered that a fairly new parameter in the VPN concentrator did not get set when the OS was upgraded to the version that added this parameter.

It's the "Split DNS names" parameter, and you can set it in the base group, or on a specific group under "Client Config" to see if it will resolve your DNS issues as well. I added the domain names that need to come back through the tunnel (seperated by commas), and that seems to have resolved the DNS issues for us.

The nice thing about this is you can set it on a test group, and test it for a while and see if it resolves your problems. After thinking about this a while, I really don't know what the expected behavior would be if this value doesn't get set, probably lots of confusion on who is going to resolve the request, the ISP's DNS server, or the internal DNS server. So I went ahead and set it as I thought it should be, and it resolved the original problem I was having, which was having to stop and restart the DNS cache each time the tunnel came up. We not longer have to do that now that this is set.

I really hope this helps someone else...

[#6]

Hi Bruce,

I'm having a similar problem. I was wondering if you ever found a solution.

Thanks for your help.

[BruceD.Brown]

searad,

If you expand the full thread of this discussion (view all messages), you will see my comments on what fixed the problem for me. It was posted on the September 9th post, just above your recent one. Hope this helps...

Bruce