I’ve always recommend that you when learning about DirectAccess that you begin your trek with the UAG DirectAccess Test Lab Guide over at http://www.microsoft.com/downloads/details.aspx?familyid=CEEBFF8D-CDF9-4AFA-8DAA-918CDC884DC0&displaylang=en
However, I know there are a lot of cowboys out there (heck, I’m one of them) and often we want to try things out on a live production network just too see how it works. Then when things don’t work, we’ll go to the Test Lab Guides to figure out what didn’t work by creating something that’s known to work. That’s what the Test Lab Guides are all about!
I was talking to one of my “cowboy” friends a couple of weeks ago and he was telling me that he was having some problems getting IP-HTTPS working. His 6to4 configuration was working fine and DirectAccess connectivity was working through both the intranet and infrastructure tunnel.
Take a look at the figure below. What he did was create a DMZ behind his firewall that used public addresses so that he could test 6to4. This will work if the DA client is located between the firewall and the UAG DA server, but wouldn’t work from the Internet. That was OK, since he wasn’t trying to make it work from the Internet yet – he just wanted to do some live testing.
Key components of the configuration:
At this point can you figure out why his IP-HTTPS adapter wasn’t firing up?
The answer is that since the DA client in the DMZ was assigned a public DNS server address, and that there is a server that is authoritative for the domain.com domain that included a host record for uag.domain.com, the DA client tried to connect to the actual internet based server with that name and not the UAG DirectAccess server that he configured as his test DirectAccess server.
So if you want to be a cowboy and not start with the Test Lab Guides, then watch out for DNS issues! Or, you can take your momma’s advice
BTW – you can always ask questions about DirectAccess and Test Lab Guides over on the TechNet forums over at http://social.technet.microsoft.com/Forums/en-us/forefrontedgeiag/threads
Tom Shinder email@example.com Microsoft ISD iX/SCD iX UAG Direct Access/Anywhere Access Group (AAG) The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx Follow me on Twitter: http://twitter.com/tshinder Facebook: http://www.facebook.com/tshinder
I'm doing the same thing, also my internal domain is domain.com.mx and the external also, so there is the same dns record A in internal dns and external dns for DA Server, so when the Da clients are on internet they think that they are in Coporate network but they obviusly not and they can not access to internal resources, the IPSEC tunnel can not establishef for the dns issue.
what can We do? We can not change the internal domain, because it is already working, How can modify the External DNS records to allow DA Clients on Internet get access to internal resources?