With Windows Server 2012, Microsoft no longer consider ISATAP as a requirement for DirectAccess deployment. With DirectAccess infrastructure based on Unified Access Gateway 2010, DNS64 return AAAA record if exists. With Windows Server 2012, this is no longer the default behavior. This change have no effect on default DirectAccess scenarios. It only impact Modified End-to-Edge scenario for Witch IPv6 connectivity is required. In my case, I was sure that my server have an IPv6 Address registered in DNS
I’ve also checked ISATAP interface configuration on my server. I was sure it was enabled.
After some research (Always perform an Update-Help command on your freshly installed Windows Server 2012, this help a lot ), I found why with a Get-NetDNSTransitionConfiguration command.
The “OnlySendAQuery” parameter manage how DNS64 respond to client. By default, It always return DNS64 generated addresses, never ISATAP /Natives addresses. To Change this behavior, just run change the value of this parameter to False with the following command : Set-NetDNSTransitionConfiguration –OnlySendAQuery $True”
Why is it so important to have AAAA DNs records response? if you have a look at the “DirectAccessPolicy-ClientToAppServer” Connection Security rule (only present in Modified End-to-Edge scenario), you will find that each server included in the filtering group is identifier with it’s ISATAP addresses.
No need to restart your DirectAccess server. Behavior change is available to DirectAccess clients immediately unless DNS64 already present in cache. I can start working on Modified End-to-Edge scenario.
BenoîtS – Simple and Secure by Design but Business compliant
Les derniers articles par Benoit (tout voir)
- Gestion de la sauvegarde de vos VM Azure avec des tags. - 18 juillet 2019
- Azure BluePrint Import/Export - 18 juin 2019
- Automatiser Azure Update Management avec Azure Policy - 16 juin 2019