none
UAG DirectAccess secondary DNS suffix issue RRS feed

  • Question

  • Our AD domain is called xyz.com.

    We've got UAG RTM with DirectAccess up and running and our Windows 7 Enterprise clients are able to connect to the corp network. Users are able to open the intranet site at intranet.xyz.com as if they are in the office.

    All ok so far.

     

    We have one problem.

     

    In our DNS we have created a secondary forward lookup zone for 123.com. If clients are outside the office they also need to be able to open internal sites in this zone. E.g. the site "website.123.com" (hosted at a windows 2003 server)

    This does not work. The site website.123.com doesn't open when connected via DirectAccess. It does work inside the office direct at the LAN

     

     

    In DirectAccess the following name suffixes are configured

    *.xyz.com       [DNS64]

    nls.xyz.com     [Excluded] (auto added, this is our network location server address)

    *123.com        [DNS64]

    da.123.com     [Excluded] (auto added, this is the external dns name for DirectAccess)

     

    In the dns forward lookup zone an A-record for website.123.com exists.

     

    What is it that I do wrong?

    Wednesday, January 13, 2010 8:50 PM

Answers

  • Hi again,

    You must make sure that the UAG server is able to resolve intranet.123.com to an A record.
    If that works for you, then it should also work for DNS64 and it will translate it into an AAAA record automatically.

    Another thing is that for the client to work with the NRPT entry you specified (*.123.com)
    the client must use the FQDN when trying to reach the website.
    If the client is trying to reach the single label name intranet, it will automatically try to add the primary DNS suffix which is .xyz.com.
    the client must use the FQDN intranet.123.com. or you could add the DNS suffix .123.com to the DNS suffix search list of the client. (configured in group policy)

    • Marked as answer by Mister Iks Monday, January 25, 2010 4:02 PM
    Monday, January 25, 2010 10:56 AM
  • Hi,

    Please make sure the name website.123.com is resolveable from the UAG server itself. (use nslookup tool to verify this).
    Also from the DirectAccess client, you must use the fully qualified name website.123.com, so it would match the NRPT entry you entered.

    Can you please send the exact output of netsh names show pol on the DirectAccess client?
    I see you're missing a "." (dot) between the * and 123.com, and I want to make sure this type isn't actually in the client policy
    • Marked as answer by Erez Benari Thursday, January 21, 2010 6:46 PM
    Thursday, January 21, 2010 3:59 PM

All replies

  • Hi Mr Iks,

    I don't see the NLS server name in the exceptions list for your NRPT.

    Thanks!
    Tom
    MS ISDUA Anywhere Access Team
    Thursday, January 21, 2010 2:26 PM
    Moderator
  • Hi,

    Please make sure the name website.123.com is resolveable from the UAG server itself. (use nslookup tool to verify this).
    Also from the DirectAccess client, you must use the fully qualified name website.123.com, so it would match the NRPT entry you entered.

    Can you please send the exact output of netsh names show pol on the DirectAccess client?
    I see you're missing a "." (dot) between the * and 123.com, and I want to make sure this type isn't actually in the client policy
    • Marked as answer by Erez Benari Thursday, January 21, 2010 6:46 PM
    Thursday, January 21, 2010 3:59 PM
  • After further investigation the problem is (a bit) different.

     

    The problem is not DNS suffix related, but an issue in the IP-HTTPS tunnel configuration.

     

     

    After a boot of a laptop that is behind a NAT device the DirectAccess connection is active. But since it is behind NAT I would expect that the Teredo tunnel would be the active tunnel. This is not the case. It is the IP-HTTPS tunnel that is active.

     

    If I then disable the wireless adapter and enable it again after that the DirectAccess connection is again active, but this time it is the Teredo tunnel that is active.

     

    Why is the Teredo tunnel not immediately active after the cold boot?

     

     

    When the IP-HTTPS tunnel is active I also have a other problem. I can ping windows 2008 hosts in the corporate network, but I can't ping windows 2003 hosts. IPv6 is enabled on the windows 2003 hosts.

    If I try to ping a Windows 2003 host the IPv6 gets resolved but I get a “request time out” response.

     

    If I do a tracert of the IPv6 of the Windows 2003 host The first hop replies but after that is times out. The IP of the first hop is the ip of the Tunnel adapter IPHTTPSInterface on the UAG/DirectAccess server.

     

    When the DirectAccess connection is active via Teredo I can ping the Windows 2003 host.
    So this problem is caused by the IP-HTTPS tunnel.

    Any thoughts on how to troubleshoot this any further?

    Friday, January 22, 2010 11:04 AM
  • Hi Mister Iks,

    First of all, IP-HTTPS comes up if Teredo was unable to provide corporate connectivity within 10 seconds.
    It is possible that because your machine was still starting up, the 10 seconds passed before there was actually a DirectAccess IPsec tunnel established.
    So IP-HTTPS came up and provided connectivity instead.
    IP-HTTPS is fully able to provide connectivity over NAT, so you shouldn't be worried about that.

    Second of all, Windows 2003 hosts aren't IPv6 capable. You can install an IPv6 stack, but the OS's built-in services don't support it and won't reply to IPv6 requests. Which IP address do you have on these machines? Is this a native IPv6 address or ISATAP?
    The recommended configuration is to disable the IPv6 stack on windows 2003 servers and to use the built-in NAT64 in order to communicate with these servers over DirectAccess.

    About the issue where it works over teredo and not over IP-HTTPS -
    the UAG server doesn't care if a teredo or IP-HTTPS client had sent the packets, it simply forwards these packets to the back-end server.
    You should check using a packet capture utility whether the Echo Requests reach the Windows 2003 hosts from the IP-HTTPS client.
    If it does, you should check your IPv6 routing in your corporate network.
    Perhaps you have a route back for the Teredo prefix (2001::/32) but not for your IP-HTTPS prefix.
    You must make sure that all internet IPv6 traffic is routeable back to the UAG server.
    Sunday, January 24, 2010 12:09 PM
  • Hi Yaniv,

    Thanks for your help so far.

    I uninstalled the IPv6 stack on one of the 2003 hosts and rebooted it. But then I got my first issue back with the secondary DNS suffix.
    The 2003 host is member of the domain and an entry for it exists in the forward lookup zone for the primary dns suffix. (which is the domain name)

    This 2003 server hosts our sharepoint site. The sharepoint site reachable via a different domain suffix. For this a secondary zone is created at our DNS server. This second suffix is also added to UAG's list of domain suffixes.


    *.xyz.com       [DNS64]  (name of the AD domain)

    nls.xyz.com     [Excluded] (auto added, this is our network location server address)

    *.123.com        [DNS64] (Secondary DNS zone)

    da.123.com     [Excluded] (auto added, this is the external dns name for DirectAccess)

    I can ping the host/netbios name of the 2003 server eg 2003server.xyz.com.  In DNS I also created an A-record in the secondary zone. intranet.123.com that points to the ipv4 address of the 2003 host.

    In my understanding DNS64 at UAG would query the DNS zone 123.com for and A and AAAA record for intranet.123.com. It only finds the A record and NAT64 should do the rest. But this doesn't seem to work.

    But I  found a workaround. If I ping the 2003 host with its primary suffix (host.xyz.com) I get a IPv6 address back. I added an AAAA-record for intranet.123.com in the forward lookup zone of the secondary domain suffix and after an flushdns on UAG and the win 7 client I do get a reply back from the box and are able to browse the intranet site.


    Then about the IP-HTTPS tunnel. I know doesn't care, but I noticed in the ping replies that the latancy over IP-HTTPS is 10 times higher then via Teredo. Because of that I prefer Teredo.

     

     

    Sunday, January 24, 2010 8:59 PM
  • Hi again,

    You must make sure that the UAG server is able to resolve intranet.123.com to an A record.
    If that works for you, then it should also work for DNS64 and it will translate it into an AAAA record automatically.

    Another thing is that for the client to work with the NRPT entry you specified (*.123.com)
    the client must use the FQDN when trying to reach the website.
    If the client is trying to reach the single label name intranet, it will automatically try to add the primary DNS suffix which is .xyz.com.
    the client must use the FQDN intranet.123.com. or you could add the DNS suffix .123.com to the DNS suffix search list of the client. (configured in group policy)

    • Marked as answer by Mister Iks Monday, January 25, 2010 4:02 PM
    Monday, January 25, 2010 10:56 AM
  • I did not used the single label name "intranet" That was not the issue

    But as you said the UAG server should be able to resolve intranet.123.com and that was not the case.
    I checked the DNS servers that were configured for the extarnal interface and it had the external DNS servers of our ISP. I changed it to the internal DNS servers.
    The secondary forward lookup zone now only has the IPv4 addresses and it still works,  so all ok now! :D

    Thanks for your help.
    Monday, January 25, 2010 4:02 PM
  • I was glad to help :)

    Monday, January 25, 2010 4:50 PM