Be Careful of DNS Issues When Testing UAG DirectAccess

  • Article

I’ve always recommend that you when learning about DirectAccess that you begin your trek with the UAG DirectAccess Test Lab Guide over at https://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 https://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): https://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: https://twitter.com/tshinder
Facebook: https://www.facebook.com/tshinder