Remote Desktop to a user connected using DirectAccess?

Answered Remote Desktop to a user connected using DirectAccess?

  • Friday, September 21, 2012 9:58 PM
     
     

    Testing using Windows Server 2012 RTM

    I have been testing DirectAccess using Windows Server 2012 in a lab environment, with Windows 7 client and am very impressed with it so far. 

    The lab environment is IPv4, so the Win 2012 Server is acting as a IPv6 to IPv4 NAT device.

    What I need to try and get working is the ability to remote desktop the client device for technical support, either using RDP or another program we use (DameWare MRC).   This is something we have been able to do for many years with our current traditional VPN solution.

    In order to test using RDP, I have tried creating client firewall rules in Group Policy to allow incoming RDP Port 3389 traffic to the client with 'Allow edge traversal' enabled.    From the DirectAccess server itself I can now Ping and RDP to a client that is connected on DirectAccess via the Internet, but our Helpdesk will need this and to be able to connect from their own desktops internally (on an IPv4 network...).

    I have also tried testing using Windows Remote Assistance but this fails to connect.

    can this be done ?


    Andy

All Replies

  • Saturday, September 22, 2012 9:39 AM
     
     Answered

    Hi,

    To be able to do "manage out" (ie, reach a client connected through DirectAccess) the machine that initiates the connection from the inside needs to have and IPv6 address assigned. (Normally ISATAP or native IPv6)
    This is a basic routing requirement since the client is only reachable over an IPv6 address...

    One way you can do if you do not want your internal clients to have an IPv6 address is to setup a server that has ISATAP and connect from that one (via RDP to it or by publishing certain programs as RemoteApps)


    Best wishes,
    Jonas Blom


    Jonas Blom | Relevo AB | http://blog.nrpt.se

    • Proposed As Answer by Jonas Blom Saturday, September 22, 2012 6:43 PM
    • Marked As Answer by Andy Welch Monday, September 24, 2012 12:36 PM
    •  
  • Monday, September 24, 2012 8:41 AM
     
     

    thank you Jonas for your reply.

    My preference would be to limit IPv6 / ISATAP only to manage-out clients rather than blanket enabling it via DNS.

    I've also come across the following links which apply more to UAG but in theory should work in the same way with Windows Server 2012.

    http://blog.msedge.org.uk/2011/11/limiting-isatap-services-to-uag.html

    http://blogs.technet.com/b/tomshinder/archive/2010/10/01/is-isatap-required-for-uag-directaccess.aspx

    will give this a try and post findings.


    Andy

  • Monday, September 24, 2012 12:33 PM
     
     

    You are correct. The same applies with Windows Server 2012. Personally, I think the best apporach to enable Manage-Out functionality is by using a GPO for the DirectAccess Manage-Out Clients. This way you minimize the impact that ISATAP might cause.


    Boudewijn Plomp, BPMi Infrastructure & Security

  • Monday, September 24, 2012 12:40 PM
     
     

    I have tested and it works successfully.

    I followed the steps in the MSEdge blog link my earlier post to create a GPO to limit ISATAP to a test client.   In DNS I added an Alias (CNAME) record called da-isatap.domain.com pointing at the hostname of the DirectAccess server.

    Once the test manage-out client restarted the new GPO applied and in IPCONFIG /ALL the ISATAP adapter is now enabled.

    Also had to create some custom inbound firewall rules to allow incoming icmpv6, RDP, and CIFS, plus a custom one for DameWare MRC which uses TCP port 6129.

    Once this was done and a test client connected via DirectAccess, I was able to ping / RDP / dameware to the client without any problem.

    thanks for your help.


    Andy

  • Monday, September 24, 2012 12:54 PM
     
     

    Glad to hear you got everything working.

    And great job posting the followup information for future readers.


    Jonas Blom | Relevo AB | http://blog.nrpt.se