Hello guys!

I have a DirectAccess 2012 R2 (two nodes in WinNLB Cluster). It is a DA Deployment only and it is virtualized on HV 2012 R2. Everything works almost fine when we are talking about DA clients accessing internal resources (IP-HTTPS only and even Force-tunneling enabled, since this is a requirement), except that sometimes DA clients just hang in "Connecting" state; this is not main concern and I am well passed this (I've found it documented in MS VKB). For things to be even more complicated, this setup of DA is "trapped" between two hardware firewalls, external & internal.

Some issues arised when I have begun to play with Manage-out scenario limited for dedicated machines only (ISATAP not enabled globally of course).
I followed instructions in a book "Microsoft DirectAccess  Best Practises and Troubleshooting" by Jordan Krause and I am well aware of all the possible issues (ISATAP in internal IPv4 network officially unsupported, issues with NLB in this scenario and Force-tunneling etc.). I have studied almost all of possible Guides, Blogs etc, so the setup is already tweaked a lot. I Will provide additional details only if neccessary after I'll get answers to a few direct questions below. Thank you!

1. Protocol 41: Does it have to be enabled on both Firewalls?
It is now enabled only on internal firewall and only than my dedicated Manage-out machine successfully installed ISATAP adapter and obtained its own ISATAP IP Address. Therefore I think it must be enabled on external firewall as well... inbound and outbound?

2. Does the DA Client machine have to have / obtain  ISATAP IP Address in this scenario while IP-HTTPS or Teredo Address is already there?

3. Does the Manage-out session use existing Tunnel from DA Server onward? So, from beginning; this Manage-out session is initiated from Manage-out machine... 1st hop is DA Server as ISATAP Router. From there onward... does it go to existing DA Client's tunnel or it creates a new tunnel?

3.1 How safe it is if it creates new tunnel?

4. Is there any chance that DA's default Windows Firewall settings block something?

5. Is there a need that Port 3389 must be enabled on external firewall outbound even though the session should go into the tunnel? WAFS on DA Clients is already allowing 3389, 445, IMCPv4,6 of course... by the book. But ping in general is blocked on those internal and external firewalls :(

I guess that's all for now :)

Thank you very much for any possible answer(s)!

Bye

Hi,

Let's provide some answers.

IP41 is only required on the internal interface. There is no need on the external interface as ISATAP will never be used (even if interface is configured), it's only FE80 Link local.

DirectAccess clients connected on Internet does not need to have an ISATAP interface operational. From my experience, you can disable 6to4 and ISATAP on your DirectAccess clients and only enable ISATAP on selected computers located on your LAN. If IPHTTPS is the only protocol to be used by DirectAccess clients you can also disable Teredo.

The manage-out session will use the existing tunnels as endpoints enforce secure communication.

From a security point of view, I consider it's secure. If you need more security, have a look some of my blog posts :

http://danstoncloud.com/blogs/simplebydesign/archive/2014/03/12/directaccess-remote-management-from-padawan-to-jedi.aspx

http://danstoncloud.com/blogs/simplebydesign/archive/2014/03/20/directaccess-remote-management-from-jedi-knight-to-master-seating-at-the-jedi-council.aspx

With this you can create extended IPSEC transport and be sure that remote management is only performed by selected IT staff.

By default the DirectAccess firewall on client-side block any incoming protocol, except if NAT-Transversal is enabled. You will need NAT-Transversal for Remote Management as it's not the DirectAccess client that initiate communication.

At last Remote Desktop incoming rule accept both IPv4 and IPv6 network flow for TCP3389. If you want to restrict to IPv6, you can (on the public/private profile) enforce with a Link-local address FE80/8. IPv4 RDP sessions will no longer work.

BenoitS, thank you very much for the answer. I have already studied your 1st blog post, but I was not aware of the another regarding extended security. Very good, I Will take a look.

Meanwhile, I have successfully figured out (by trial-and-error) about where and in which way Protocol 41 must be enabled. Maybe I wasn't clear enough on External Firewalls setup, hence the picture attached (sorry for hand-drawn :)

1) Answer to Question 1: Protocol 41 (P41) must be enabled on any possible External Firewall - Outbound only (statefull firewall takes care for the inbound).

2) BonitS, you've already answered to Question 2: ISATAP (and 6to4 of course) on DA Client is not neccessary and may be disabled as I've seen after it started to work in my scenario.

3) Question 3 was answered by BenoitS as well and I can see it now with my own eyes, especially because ISATAP adapter on DA Client wasn't configured (obtained IP address) after P41 Outbound was enabled on both firewalls (external and internal) and Manage-out begun to work.

3.1) Answer to Question 3.1 is not neccessary since now I know it uses existing DA Client's tunnel.

4) Answer to Question 4: Obviously not when DA is on default Windows Firewall settings - which is true in my case.

5) Answer to Question 5: Obviously not (for external firewall, because from DA server onward existing DA Client's tunnel is used).

If Windows Remote Assistance is your only need for manage-out, have a look at this Other blog post of mine : http://danstoncloud.com/blogs/simplebydesign/archive/2014/07/30/windows-remote-assistance-between-directaccess-clients-made-easy-and-simple.aspx : Remote management between DirectAccess clients. No need to have ISATAP on LAN.

Another issue acknowledged during testing and troubleshooting of ManageOut over limited ISATAP. Since this is a DA WinNLB Cluster, both of DA Servers should have ISATAP IPv6 address of something like x:x:x:0:5efe:192:y:y:y (internal ISATAP IP address). In my case, only one node has got x:x:x:200:5efe:193:y:y:y (external ISATAP IP address). I don't know where from it came and when, because I didn't pay attention until I had to.

I figured out that this ISATAP adapter (with external ISATAP IP address) was bind to external NIC.

What I have done until now?

1. netsh interface ipv6 show interface
2. wmic nicconfig get description, SettingID
   1. This is how I figured out ISATAP adapter binding to external NIC
3. Device Manager, Show hidden devices
   1. Deleted both ISATAP adapters (it didn't ask me to delete drivers or not)
4. sc control iphlpsvc paramchange
5. net stop iphlpsvc
6. net start iphlpsvc
7. reboot server

After step 6 initially and 7 afterward result was the same. Scan for hardware changes in Device manager reconfigured new ISATAP adapters but both of them only with "Link-local IPv6 Addresses". Any suggestions for next step(s) pls?

Hi

In NLB / HLB scenario, ISATAP is not enabled because having a distinct ISATAP router on each node is not a solution. ISATAP clients locate ISATAP router because of ISATAP record registred in DNS (if unblocked only) or if configured manually. Having a dedicated ISATAP router is an option but require IPv6 native connectivity with DirectAccess Gateway LAN interface.

By default, ISATAP interface is enabled by host, not by interface. That's why you see an ISATAP interface on the external network interface. It's not a problem as long as there is not possibility to discover an ISATAP record in the DNS suffix configured on the external network interface. As link as you only see FE80 on the external ISATAP network interface, it's not a problem.

Hello BenoitS and thank you for you answer. I understand everything you wrote but I would still like to go further. I managed to intentionally reproduce  the issue (using Snapshot as a backup) in my "production lab" using one DA Server only.

So, to be more exact... I followed exactly the same steps reinstalling ISATAP Adapter as mentioned in my previous post and the result is the same. Only Link-local IPv6 addresses on ISATAP Adapter. This breaks up ManageOut scenario which was working flawlessly moments before, because my dedicated ManageOut Server cannot see DA server on ISATAP internal part of the network. Eventually, DA cannot route it to the DA Client outside.

There must be a way to somehow fix this... to get "real" working ISATAP IPv6 address back to DA Server's ISATAP Adapter (not just Link-local). Should I force DA Server using GPO to show him itself as a ISATAP Router using same DNS record as it is used for ManageOut Server?

Hi,

Your ISATAP router must be client of itself. Otherwize it cannot get the ISATAP prefix to used to build it's own ISATAP address. ICMPv4 and IP41 network flow must be allowed. Do you configure ISATAP manually on required hosts or by GPO?

I configured my ManageOut Server or. "required host" using GPO (one server only). This ManageOut Server successfully configures its ISATAP Address, because it finds ISATAP Router = DA Server using custom ISATAP DNS Record and this GPO.

DA Server has got its ISATAP Addresses "by itself" somehow from the begining... I guess that from when DA Role was installed. It wasn't touched or configured until now, because one DA Server is OK - it has "internal" ISATAP address, the other one had "external" and I intentionally deleted this one, hoping to fix it in the way it will re-obatin internal ISATAP address.

GPO for Custom ISATAP settings is filtered to target only my ManageOut Server - for now.

If your DirectAccess Gateway have a valid ISATAP interface (not only FE80), you should be able to perform manage-out. Next stage is to chjeck ICMPv6 In/out at multiple stages :

-Remote management Server

-DirectAccess Gateway

-DirectAccess clients

Once you have IPv6 network connectivity, just enable the required protocol (RDP, ...) and enable the NAT Transfersal feature on client-side.