none
Direct Access 2012 with Windows 8/8.1 clients - outbound management issues

    Question

  • Afternoon all,

    I'm having fun and games with a Server 2012 machine configured with Direct Access in DA & VPN format with a single NIC behind NAT. Basically all the clients successfully connect and can correctly browse internal resources, however outbound management for the DA clients from the internal network is not working.

    Detail:

    1) I can confirm the DA client is successfully connected. Get-DAConnectionStatus shows status as "ConnectedRemotely" and I can ping/browse internal resources

    2) Get-DNSClientNRPTPolicy seems to come back with reasonable values so I'm happy the GPOs are being correctly applied to the client.

    3) If I try to ping an externally connected DA client from the DA server it resolves the IP4 address and says (rightly so) that it can't ping it.

    4) If I *manually* create an AAAA record in the internal AD integrated DNS server domain zone for the DA client's IP-HTTPS IP6 address it then it works and I can ping/RDP/SCCMRemoteControl/etc the DA client from the DA server successfully.

    So at this point I'm leaning towards the idea that the DA clients are unable to register their IP-HTTPS entries into DNS successfully which is preventing services from working because without the IP6 AAAA record it defaults to the IP4 A record and can't see the machine.

    Checking the event viewer on the external DA client (connected via 3G card to the internet) shows that it is only trying to register its DNS entry with the DNS server allocated from the 3G ISP and not the internal AD DNS - is this normal?

    I found one article that seemed to have the same issue (http://social.technet.microsoft.com/Forums/windowsserver/en-US/420f0d90-ab97-41af-8745-62d0a2251359/direct-access-2012-client-dns-registration-problem) and they resolved by creating a GPO to ensure the DNS client forced "Secure Updates" to the DNS server - however I've implemented that policy and it has failed to resolve the issue.

    Does anyone have any ideas? Am I missing a magic rune somewhere?

    Cheers

    Joe


    • Edited by JoeGough Saturday, September 28, 2013 1:51 PM
    Saturday, September 28, 2013 1:47 PM

Answers

  • The issue at hand is quite a big more complicated than simply registering DNS records. For you to be able to initiate outbound packets to DirectAccess clients, your internal resources must be IPv6 connected on the internal network. This means that you either have to have native IPv6 in your network, or you have to enable ISATAP to make sort of an "IPv6 virtual cloud" that runs on top of your IPv4 internal network.

    Some of the Test Lab Guides show you how to setup ISATAP, but please do not take this global approach to doing it. Make sure to create a selective ISATAP environment where only the internal machines you want connected are actually connected. Jason Jones has a good explanation on how to establish selective ISATAP here: http://blog.msedge.org.uk/2011/11/limiting-isatap-services-to-uag.html (yes, this still applies to Server 2012 DA), and there is also a full chapter in this book dedicated to ISATAP and to the "DirectAccess Manage-Out" scenario: http://www.packtpub.com/microsoft-directaccess-best-practices-and-troubleshooting/book 

    I apologize if mentioning the book comes across as self-serving, since I wrote it :) but the reason I did that chapter was because this is one of most commonly misunderstood parts of DirectAccess, and the book fully explains why this is necessary and how to set it up correctly.

    • Marked as answer by JoeGough Tuesday, October 01, 2013 6:19 PM
    Tuesday, October 01, 2013 3:35 PM

All replies

  • The issue at hand is quite a big more complicated than simply registering DNS records. For you to be able to initiate outbound packets to DirectAccess clients, your internal resources must be IPv6 connected on the internal network. This means that you either have to have native IPv6 in your network, or you have to enable ISATAP to make sort of an "IPv6 virtual cloud" that runs on top of your IPv4 internal network.

    Some of the Test Lab Guides show you how to setup ISATAP, but please do not take this global approach to doing it. Make sure to create a selective ISATAP environment where only the internal machines you want connected are actually connected. Jason Jones has a good explanation on how to establish selective ISATAP here: http://blog.msedge.org.uk/2011/11/limiting-isatap-services-to-uag.html (yes, this still applies to Server 2012 DA), and there is also a full chapter in this book dedicated to ISATAP and to the "DirectAccess Manage-Out" scenario: http://www.packtpub.com/microsoft-directaccess-best-practices-and-troubleshooting/book 

    I apologize if mentioning the book comes across as self-serving, since I wrote it :) but the reason I did that chapter was because this is one of most commonly misunderstood parts of DirectAccess, and the book fully explains why this is necessary and how to set it up correctly.

    • Marked as answer by JoeGough Tuesday, October 01, 2013 6:19 PM
    Tuesday, October 01, 2013 3:35 PM
  • Thanks for the reply Jordan, I was willing to accept connectivity solely from the DA host box itself to save from additional configuration/analysis as it will only be me that ever uses the outbound management and I'm in process of rebuilding the entire network from scratch so this is just one part of my plan and time is limited at this stage.

    I should point out that one of my DA clients has managed to consistently register its IP-HTTPS AAAA address in the DNS server and outbound management works just fine for him. But I can't find anything different on that particular client or any server configuration that would indicate how it has registered it...

    I did take a look at Jason's selective ISATAP article but incorrectly concluded it wasn't what I needed, time to go back and take another read. I used to work with Jason so if I get confused I might have to hit him up for some assistance - hint, hint Jason if you are reading this you are a Gentleman and a Scholar :)

    Thanks for the book reference, I will likely pick it up :)

    I'll do some more reading and let you know how I get on.

    Regards

    Joe




    EDIT - ok, it was actually this article I read http://blogs.technet.com/b/jasonjones/archive/2013/04/02/windows-server-2012-directaccess-manage-out-using-native-ipv6.aspx and now that I have re-read it, I have no earthly idea why I discounted it... thanks for pointing me back on the correct path.
    • Edited by JoeGough Tuesday, October 01, 2013 6:19 PM
    Tuesday, October 01, 2013 5:41 PM
  • Hi Jordan, Just tried to pick up your book but seems it is not available yet on Amazon Kindle store but has a release date of yesterday? I'll try again tomorrow morning when I get to work.

    Cheers

    Tuesday, October 01, 2013 5:49 PM
  • It's my understanding that it should be available within the next week. Thanks for the interest!
    Tuesday, October 01, 2013 7:36 PM
  • Morning,

    I have had a chance to make the changes. I decided to go for J.J's ISATAP approach.

    From reading J.J's native IPv6 article I couldn't determine if I needed native IPv6 connectivity from the manage-out machine to the internal DA server, or if I needed native IPv6 connectivity from the external DA client to the internal DA server. If someone could clear that up I would appreciate it for future installs, my mind says that it would be logical for it to be internal only (with the remaining encapsulation from internal DA server to external DA client handled by the DA server) so assuming DA Server and Manage-Out client are on the same LAN and there were no IP4 only DMZ style firewalls in the way it would work? Not sure if the fact I'm using internal NAT single IP4 NIC DA installation type will affect this?

    Anyway....

    I have setup the ISATAP method and life is good. The one external (ie - outside the network and residing on the internet) DA client I have that has successfully managed to register its IPv6 address to internal DNS can now be managed from my workstation on the intranet. However all the other external DA clients have failed to register their IPv6 addresses in the internal DNS and so cannot be contacted.

    Does anyone have any ideas on why my external DA clients might not have registered their address on internal DNS or where I can look for logging data on this?

    Regards

    Joe.

    EDIT - Just realised that the machine that has registered is Windows 8.0 and the ones that have not registered are all Windows 8.1... time to build a new 8.0 test machine to eliminate that as a factor. If anyone has any thoughts in the meantime please shout.


    • Edited by JoeGough Wednesday, October 02, 2013 10:49 AM
    Wednesday, October 02, 2013 10:44 AM
  • For the native IPv6 approach, you need IPv6 on the internal part of the DirectAccess server. So you need IPv6 between the internal management computer, and the DirectAccess server. There is already IPv6 routability between the DirectAccess server and the DirectAccess clients all the time.

    I don't know if your single-NIC approach would affect that or not. To be honest, that implementation method to me is more of a proof of concept or a quick trial method of install. I always go two-leg for production. I also lay that story out (why I feel that way) in the book - I promise I'm not trying to generate interest here, just trying to shorten this post :)

    Great job on the ISATAP setup! I was thinking more about this post last night, and I came to the same conclusion that you discovered - with or without the right ISATAP infrastructure in place, you are still going to need your clients to register themselves in DNS, and if they are not, that will continue to be a problem. I have installed DA hundreds of times, and the only times I have seen where the clients do not register themselves in DNS is when there is something on the DNS side configured not to allow it to happen. This could, of course, just be the first time I have encountered a different cause to this behavior, but I would check over all of your registration settings in DNS to ensure it is allowing these registers to happen.

    Doh, I was typing this as I read your post, and I just got to the 8.1 part :) Sounds like you might be on to something. I'm afraid I don't have any definitive information for you on that, but it would be great if you could update us as to your results!

    Wednesday, October 02, 2013 1:03 PM
  • I have now tested clean builds of Windows 8.0 and Windows 8.1 - both of them register their IP4 addresses to internal DNS successfully (while connected internally ofc), but neither are able to register their IP6 addresses to internal DNS while externally connected using DA.

    I'm relieved it isn't a Windows 8.1 issue tbh, that would have been annoying. Hopefully I've just got a configuration issue somewhere then. I'm open to suggestions on where to look...

    cheers

    Wednesday, October 02, 2013 2:50 PM
  • I have an update, the clients are able to register their IP6 address into internal DNS, but only when dynamic updates are set to "Nonsecure and Secure".

    When I have it set to Secure, they do not register.

    Any idea?

    Thursday, October 03, 2013 11:03 AM
  • argh. Rookie mistake! I forgot to put the DA server in the DNSUpdateProxy group... I've added it in and now things appears to be working just fine.

    I'll monitor for the next 24 hours but in the meantime, I'll be in the corner. looking sheepish :)

    Thursday, October 03, 2013 3:03 PM
  • Great news! Glad to hear it's working now. Thanks for following up.
    Thursday, October 03, 2013 3:39 PM