RDP, Remote Tools from LAN to DA client RRS feed

  • Question

  • I can RDP from DA client to LAN, but I can't RDP from the LAN to DA client.  Or Remote tools with SCCM as my case need is.  

    It is not a client firewall issue as I can conenct to the clients when they are on the LAN just not over DA tunnels.  Is their some UAG settings that need to be made to acomidate this?  

    How in theory should this work.  Should the DA client be somehow publishing a 6to4 addess in the ADDS ?   Is their something I need to do on my LAN router to direct DA client IP's to the UAG LAN (VIP) interface



    Saturday, February 12, 2011 6:49 PM

All replies

  • Hi,

    A good thread with a similar question is:

    Regarding access on LAN vs when the client is connected through DirectAccess.
    When the client computer is on the LAN one set of firewall rules (domain profile) are activated, when the client computer is external and uses DirectAccess it has another set of rules loaded (public profile most likely)
    So the suggestion in the thread above regarding allowing all traffic through the client firewall is still a good place to start. :)

    A good checklist for verify/troubleshoot 6to4 functionality is:

    The routing question, how is your IPv6 setup? ISATAP or Native IPv6?
    Can the client access internal resources when on 6to4?
    If it can, could it be that your internal machine isn't listed as a management host so you wont be able to access it without the userbased IPSec tunnels?


    Best wishes,
    Jonas Blom

    Saturday, February 12, 2011 8:55 PM
  • THank you for the post.


    If I open up the ports on the public profile I would need to be much more restrictive in terms om limiting the source IP as well to only corp LAN clients to prevent brute attacks and repete login attempts to RDP and SQL running on the DA clients.  That said would  the source IP(s) be corp lan IPV6 isatap (my enviornment) or  corp lan IPv4 or the source hostname (single name or FQDN at that?).  

    IPv6 is isatap not native and yes clients can access corp resources on direct 6to4 model as I tested that from a remote static IP however 99% of my clients use Teredo or IP-https in the most random fashion.  I am not completly sure what you mean by "could it be that your internal machine isn't listed as a management host so you wont be able to access it without the userbased IPSec tunnels"    The internal machine I am testing with is a SCCM 2007R3 host and is a domain admin in its own right so I doubt it is a permission issue from the In to Out side of things.  Userbased ipsec tunnels???


    Saturday, February 12, 2011 11:56 PM
  • Hi again,

    Good to know you can reach stuff internally, then the routing parts should all work :)

    Use the internal IPv6 range(s) that you want access from as allowed sources.
    (I would suggest creating a new rule that only applies to the Public profile and add the ipv6 range(s) as only allowed sources)

    Regarding userbased IPSec tunnels, i was talking about the hosts that you setup during UAG DirectAccess configuration as management hosts.
    (A good url: )

    If noone is logged onto the computer when you try to initiate a RDP session to it, it will only be accessible by these servers through the infrastructure tunnels.


    Sunday, February 13, 2011 1:42 PM
  • I'm working out a similar issue right now.  I have a DirectAccess client that I am able to ping, RDP to and open file shares from but I cannot use the SCCM Remote Tool.  I am testing against the DA client while connected with 6TO4.  My guess is that I need to create firewall rules in the public profile to allow it, but I haven't tried it yet.

    Here's some details from Tom about the way DirectAccess client firewalls work.

    "The DirectAccess client will only act as a DirectAccess client when the Private or Public Profiles are enabled. ...  If you want your Domain Profile firewall rules to apply to DirectAccess clients, you will need to enable those rules on the Public Profile and Private Profile too."

    And there is the information on how to allow the Remote Tool through the firewall.

    In order to use the remote tools features of Configuration Manager 2007, you need to allow the following ports:

    • TCP port 2701
    • TCP port 2702
    • TCP port 135

    I hope that helps! 

    MrShannon | TechNuggets Blog | Concurrency Blogs
    • Proposed as answer by MrShannon Tuesday, February 15, 2011 3:19 PM
    Monday, February 14, 2011 1:23 PM
  • Also, remember to enable Edge Traversal on those rules.

    For a nice example of a "special" application that requires custom Firewall Rules on the DirectAccess client, check out:



    MS ISDUA/UAG DA Anywhere Access Team Get yourself some Test Lab Guides!
    • Proposed as answer by MrShannon Tuesday, February 15, 2011 3:19 PM
    Monday, February 14, 2011 1:26 PM
  • The firewall rule (and allowing edge traversal) did the trick for me.
    MrShannon | TechNuggets Blog | Concurrency Blogs
    Tuesday, February 15, 2011 3:19 PM
  • amazing work shannon
    Thanks and Regards Suraj Singh My blog:
    Wednesday, February 16, 2011 6:58 PM
  • Hmm,

     Firewall rules DO NOT do the trick for me  as the client previously published its IPv4 in DNS  while on LAN so when I try to RDP to the client it times out attempting to connect to the IPv4 address resolved from dns DNS I think.  (determined becouse I enabled inbound notifications on the DA clinet firewall and one was never triggered)   Matter of fact I can create and ALL, ANY, ALL, ALL rule or even turn the firewalls off all together and is does not work. More importantly its not just RDP that can;t contact to remote DA cleints its: SCCM services, WSUS, Remote Tools, WMI push, SNMP server, SQL partition replication agent publisher, webservices publisher all cant find the rascals either via hostname. 

    Question 1) When a Client connects with DA does it publish its new ipv6 address in the active directory dns server?  If so under what timeframe, or configuration variables.  e,g  iphttps, teredo or both?  if not does it publish its address in the ad dns servers does it do it somewhere else?

    Question 2) if it does publish its remote ipv6 address somewhere in the local LAN infrastructure (DNS or UAG I am guessing) does the local LAN gateway router need to be ipV6 aware and or have a ipv6 isatap or dedicated ipv6 address to "play ball". 

    Question 3) Does the local LAN gateway need a static routing rule to direct iphttps, terredo or direct 6to4 based ipv6 addresses of DA clients to the UAG ipv4/6 VIP?   If so what what would that look like?  How are local hosts on the LAN to know that remote DA clients (once resolved) are to be contacted though the UAG LAN gateway address (either ipv4 or 6) and not the main LAN gateway.

    I am out of the water on this one as I don't completly understand the UAG archtecture.  In a normal VPN enviro the gateway is typicaly the session host for VPN cients and the remote clients are often subnetted out.  Even if they use a DHCP over VPN it is a common subnet and the gateway knows how to transverse the ipsec tunnel to reach the remote client.  In this UAG/DA model it is like a second gateway within the LAN that some clients are behind (toss in this enigma of ipv6 schemas resultant from four ipv6 nomenclatures with iphttps, isatap, terredo, and 6to4/native this routing is mind numbing).  

    I can RDP from any remote DA clients to any host inside the LAN, but I can’t RDP to DA clients from inside the LAN. I am guessing that once the RDP  is figured out in terms of how a LAN host would contact a DA host my SCCM , WSUS, Remote Tools, WMI push, SNMP server, SQL partition replication agent publisher will all function because they know how to contact the remote DA host.   


    This has to be LAN routing somehow?   Bottom line is it's not firewall.


    Anyone?  Thoughts?









    Saturday, February 19, 2011 4:38 PM
  • Hi,

    Yes, the DA client should register its IPv6 address into DNS. The exact address published in DNS will depend on how the client is connecting and could be a 6to4, Teredo or IP-HTTPS formatted address.

    Your internal remote management client will need to route to this IPv6 address via UAG. Consequently, UAG needs to be your IPv6 default gateway or you need static routes for your DA client IPv6 address prefixes (for Teredo, 6to4 and IP-HTTPS) defined in your routing table on your remote management client.

    With a default UAG setup, these IPv6 prefixes will be:

    2001:0:WWXX:YYZZ::/64 (Teredo)
    2002:WWXX:YYZZ:8100::/56 (IP-HTTPS)
    2002:WWXX:YYZZ::/[16+IPv4 CIDR] (6to4)

    where WW.XX.YY.ZZ is the first UAG Public IPv4 address (converted into hex).

    If you are using ISATAP provided by UAG, then UAG should already be defined as your IPv6 default gateway. If not, you many need to add static routes using the above IPv6 prefixes and forward the traffic for these routes to UAG.

    Can you provide some ipv6/ipv4 route prints to get us started?



    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: and
    Sunday, February 20, 2011 12:30 AM
  • 1) Yes, it'll register itself as any other domain member on your network would.  Jason's got the details on what to look for in DNS, however something to consider is making sure that the NIC on your DA client is configured to register with DNS.  In particular, if your DA clients are using cellular modems or EVDO cards they generally will _not_ register with DNS unless you check the box in the adapter config to do so.

    2 & 3) The network devices on your LAN (the switches and the routers) should not need to know anything about IPv6.  If you are using ISATAP on the LAN then your internal workstations and servers that are using ISATAP will wrap their IPv6 traffic up in IPv4 packets and travel along your IPv4 infrastructure to your UAG server where it'll be unwrapped and then sent over the IPSEC tunnels to the DirectAccess client.  The only components that need to know anything about IPv6 is the internal computers that you are trying to initiate the connection from, the UAG server that is acting as the ISATAP router/gateway and the DirectAccess client you are connecting to.

    I suppose you could also count the DNS servers that need to report the AAAA records.  Do you see any of the ISATAP addresses of your internal hosts in DNS?  Once you've enabled ISATAP you should start noticing internal traffic ocurrs over the IPv6.  Trying pining a W2008 DC from a W7 client for example.

    If you find that ISATAP is not working as expected take a look at the "Internal DNS" portion of this

    Hope that helps!

    MrShannon | TechNuggets Blog | Concurrency Blogs
    Sunday, February 20, 2011 5:10 AM
  • JJ  Thank you

    Not sure what you mean by router prints, but here are a few observations I looked at in DNS and UAG connection web monitor

    1) When I go into the UAG web monitor I see a single client will often establish 6 or more connections both multiple infrastructure and multiple  Intranet tunnels.  Is this right?  Should a single DA client have multiple  tunnels?   Even among the intranet tunnels the connection type varies between IPhttps and Teredo randomly and between different nodes on the UAG cluster randomly.  

    2) Each connection has a different IPv6 address.  For example a client may have 5 intranet connections all with a different ipv6 address.   That’s got to make it difficult no?  I could see no trend with what of the many ipv6 address get published in DNS, but only one does.

    3) When I look into DNS I do see that clients are publishing ipv6 but some clients publish their infrastructure tunnel address and others publish one of several intranet tunnel address with no discernable constancy.


    1) Do protocols like WMI, Reomote Tools, RDP transverse the infrastucture tunnel or the intranet tunnel or both?   Does it matter?

    2) What determines which ipv6 is published into DNS the, infrastructure or intranet address?


    Monday, February 21, 2011 12:54 AM
  • Hi D,

    Only a single IP address should be registered in the DNS. Even when both the IP-HTTPS and Teredo interfaces seem to be active, only the IP-HTTPS interface is passing traffic.

    The intranet and infrastructure tunnels use the same IP address.

    The infrastrucutre tunnel will pass all protocols to machines defined as "management servers"

    The intranet tunnel will pass all protocols to all machines on the intranet.



    MS ISDUA/UAG DA Anywhere Access Team Get yourself some Test Lab Guides!
    Monday, February 21, 2011 2:21 PM
  • If you want to see how the remote management "manage out" feature works, check out:



    MS ISDUA/UAG DA Anywhere Access Team Get yourself some Test Lab Guides!
    Monday, February 21, 2011 2:23 PM
  •  Tom

    Relative to the UAG system not passing traffic for RDP to the remote DA clients I am at a loss.  At least clients can access resources.    One thing I noticed is that when I pull up the web monitor it says (at times) that isatap and or network security or 6to4 is "not healthy"  on various array membersWhat test is the web monitor performing to determine this?   Even when the not healthy is present the clients can still access internal resources so I am wondering if there is an underlying issue I can look for based on the web monitors testes?  Is the isatap entry in DNS supposed to be on just the internal ipv4 VIP for an array,  the DIP's or both?

    Can you recommend any top level UAG consultants no matter the cost. I have now spent over 10K on a couple junior hacks and I need someone with extensive UAG experience with UAG and arrays. My system is just not functional and I need to stay the course with the product concept and get a senior product expert to remote in a look at my config to get this thing humming along

    Tuesday, February 22, 2011 3:23 AM
  • Where are you based geographically?

    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: and
    Thursday, February 24, 2011 1:23 AM
  • Minneapolis, MN


    Saturday, February 26, 2011 1:48 AM
  • and it does not work. I did everything you suggested and nothing.

    the difference is that I'm using DA on Server 2012, but still everything works except RDP. I created the rules the way you suggested, I can ping every single server from external DA client and the opposite way around, but Manage Out - nothing happens.

    Any suggestions? 

    Tuesday, October 2, 2012 1:50 PM