locked
DirectAccess w/ UAG DNS Registration ("Manage-Out") RRS feed

  • Question

  • Hello,

    I've been testing DirectAccess using UAG with great success, but one thing that has been giving me a hard time is "managing out" by using DNS names. Management servers and my IT laptop can remote control the system if I use the IPv6 address, but it looks like the IPv6 DA IP isn't being passed on to DNS.

    The client should be registering its DNS with the internal DNS servers, no?

    Does anyone have any hints as to what I should be looking for (errors or settings)?

    I've ensured that "Register this ocnnection's addresses in DNS" is checked.

     

    Thanks

    Matt

     

    Edit: I should mention that I can connect to the client by using the IPv6 address - ping, rdp, remote assistance, etc, all work, just not if I use the computer name. I tried deleting the client's entry in DNS and restarting the client, but no luck.

    • Edited by MattCrossley Thursday, June 3, 2010 9:28 PM additional info
    Thursday, June 3, 2010 9:02 PM

Answers

  • Oh wait, I thought you were seeing ESP packets on the DNS/DC itself. (Which is a rare issue where the internal network is accidentally categorized as public profile and IPsec rules are applied on internal traffic)

    You are supposed to see ESP & AuthIP packets on the UAG box itself coming from the clients. This is actually the IPsec tunnels traffic, and they're content is encrypted.

    If you filter on the internal adapter of the UAG box only, you should see the traffic after it has been decrypted and see all of the "real" packets.

    • Marked as answer by Erez Benari Wednesday, June 16, 2010 11:56 PM
    Wednesday, June 9, 2010 8:26 AM

All replies

  • Hi Matt,

    Yes, the clients should register their IPv6 address in the internal DNS. Do you have a DNS server that supports registering IPv6 addresses?

    You can download Microsoft Network Monitor and try to capture the traffic from the client to the DNS server/DNS64 and filter the DNS protocol. In the packet exchange you should see the client trying to register the addresses and the response of the DNS server.

    Thanks,

    Yaniv

    Sunday, June 6, 2010 4:37 PM
  • I beleive you need at least a Windows 2008 DNS Server to support this...

    For testing, you can also force registration using ipconfig /registerdns


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Monday, June 7, 2010 2:48 PM
  • Thanks for the replies!

     

    Yaniv: The Internal DNS Servers are set up with IPv6 ISATAP addresses, and when the client is on the LAN, it registers its IPv6 address fine.

    Thanks for hte info re: network monitor. I'll give it a try n the next few minutes.

    Thanks!

    Matt

    Monday, June 7, 2010 4:02 PM
  • Hi again,

     

    I had a look with Network Monitor, and all I can really see are two things:

     

    ICMPv6 and ESP packets.

    Is there a way to see within the encrypted payload?

    Otherwise, ipconfig /registerdns doesn't generate any traffic.

     

    Thanks

    Matt

     

    Monday, June 7, 2010 4:29 PM
  • I see.

    are the ESP packets coming from a source IP of the client or of the UAG server?

    Can you please restart the UAG server and test this again (I just want to eliminate one of my worries)

    Monday, June 7, 2010 6:39 PM
  • Hi Yaniv,

     

    The ESP Packets are coming from the source IP (v4) of the client...

     

    I'll restart the UAG server right now.

     

    Monday, June 7, 2010 8:21 PM
  • Hi again,

     

    I've restarted the UAG server and the workstatoin and I can now resolve the address!

    I'll test it further on more clients, but what do you think the issue was?

     

    FYI, I still see mostly ESP, AuthIP (and now some ssl) packets, no DNS.

     

    Also, how can I tell which interface my system is using? teredo and iphttps seem to be running...

    Monday, June 7, 2010 8:40 PM
  • Oh wait, I thought you were seeing ESP packets on the DNS/DC itself. (Which is a rare issue where the internal network is accidentally categorized as public profile and IPsec rules are applied on internal traffic)

    You are supposed to see ESP & AuthIP packets on the UAG box itself coming from the clients. This is actually the IPsec tunnels traffic, and they're content is encrypted.

    If you filter on the internal adapter of the UAG box only, you should see the traffic after it has been decrypted and see all of the "real" packets.

    • Marked as answer by Erez Benari Wednesday, June 16, 2010 11:56 PM
    Wednesday, June 9, 2010 8:26 AM