Direct Access Clients intermittently failing to connect to certain servers with IPv6 DNS records in internal DNS
Wednesday, January 30, 2013 1:25 PM
We're having an odd issue with Direct Access lately. Some (but not all) clients are having an issue accessing some (but not all) servers. Specifically, servers to which we have drives mapped, though the issue affects all means of access - UNC, RDP, web, etc.
We've traced the issue to our internal DNS - The servers that the affected clients can't reach have both an IPv4 and IPv6 address listed (which in and of itself is expected and should not be a problem). However, if we delete the IPv6 record, then the affected clients can then reach that server.
That should be the end of it, at least as far as the work-around is concerned, except that the IPv6 records keep coming back. I've disabled IPv6 (or at least unchecked it - have not yet gone so far as to completely uninstall v6.) on the problem servers, and also unchecked the "register this connection's addresses in DNS" option on the servers. But the IPv6 addresses keep re-appearing in our internal DNS, and when they do, the affected clients stop being able to reach that server over DA.
Anyone have any ideas?
Wednesday, January 30, 2013 1:56 PM
To disable IPv6 completely on the servers in question, set the following registry value to 0xffffffff as per http://support.microsoft.com/kb/929852.
Your issue comes from IPv6 routing problems I would say.
Hth, Anders Janson Enfo Zipper
Friday, February 01, 2013 6:46 PM
We currently have a work-around in place that did not require disabling v6(Static DNS aliases for the problem servers. Map the drives to the alias rather than the server name.) But since that is just a work around, anyone have any ideas as to toubleshooting the actual DA issue?
Monday, April 15, 2013 4:23 PM
I am currently seeing same kind of issue for one of the server when the client is getting connected to Array Member over Direct access. We dont have any mapped drive. We have enabled ISATAP.
Any help would be greatly appreciated.
Monday, April 15, 2013 7:34 PM
To address the original question, if the IPv6 addresses that keep showing up in DNS are "real" IPv6 addresses (not ISATAP), then you need to figure out where they are coming from. In a DirectAccess environment, if there is an IPv6 record in DNS, that is the record that will be attempted to contact from a DirectAccess client. If that is a native IPv6 address, then the DirectAccess server needs to have an interface in that IPv6 network and you will need to re-run through the DA config. If those are ISATAP addresses, take a look at your ISATAP environment and see if anything is wrong.
When you remove the IPv6 address from DNS, the DirectAccess server then falls onto using DNS64/NAT64 to use "fake" IPv6 addresses for the DirectAccess machines, and communicates on the internal network with the IPv4 address. If it works this way and not with the IPv6 addresses, then it sounds like there is a routing problem between the DirectAccess server and those endpoints when using IPv6.
And if it is ISATAP, it could mean that there is a firewall (on the internal network or on the endpoint server) that is blocking Protocol 41. Or that the IP Helper service is having a problem on the endpoint server so that ISATAP is not functioning properly on it.
Ashishvaidya - If you have enabled ISATAP wholesale, you should rethink that strategy. Or do you mean you enabled it just on this server?
Monday, April 15, 2013 7:47 PM
Thanks for the reply.
Everything else is working fine except just one particular server.
Monday, April 15, 2013 7:56 PMSo you do have ISATAP enabled for the whole internal network?
Monday, April 15, 2013 7:59 PM
Yes it has been enable for whole internal network, and all the server works except one.
Monday, April 15, 2013 8:03 PM
Is there a reason you did it for the whole network? It is typically better to be selective about how you use ISATAP, for only those servers that actually need it.
But that aside, it is probably some reason that ISATAP packets aren't getting to this machine. I would try restarting the IP Helper service, or restarting the server when you can, or check any firewalls on that server and make sure it isn't blocking Protocol 41. I have seen some antivirus programs do this as well (Symantec's Network Threat Protection)
Otherwise if you don't actually need ISATAP on this server, spoof its HOSTS file to point ISATAP at a nonexistant address and see if you can get it out of the ISATAP environment, let it run over IPv4.