The Private Cloud Man

Private Cloud Technologies, Architecture and more!

Be Careful of DNS Issues When Testing UAG DirectAccess

Be Careful of DNS Issues When Testing UAG DirectAccess

  • Comments 1
  • Likes

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:

  • The subject name on the IP-HTTPS certificate is uag.domain.com
  • The DirectAccess client is configured to connect to the IP-HTTPS listener using the FQDN uag.domain.com
  • The DirectAccess client in the DMZ was getting IP addressing information from the firewall – which included a public DNS server address
  • There is a public DNS server that is authoritative for domain.com
  • There is a Host (A) record on the public DNS server for uag.domain.com

 

image

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 

HTH,

Tom

Tom Shinder
tomsh@microsoft.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

Comments
  • 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?

    Regards

    Thank you

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment