In this article by Jordan Krause, the author of the book Microsoft DirectAccess Best Practices and Troubleshooting, we will have a look at how Manage Out is configured to DirectAccess clients. DirectAccess is obviously a wonderful technology from the user's perspective. There is literally nothing that they have to do to connect to company resources; it just happens automatically whenever they have Internet access. What isn't talked about nearly as often is the fact that DirectAccess is possibly of even greater benefit to the IT department. Because DirectAccess is so seamless and automatic, your Group Policy settings, patches, scripts, and everything that you want to use to manage and manipulate those client machines is always able to run. You no longer have to wait for the user to launch a VPN or come into the office for their computer to be secured with the latest policies. You no longer have to worry about laptops being off the network for weeks at a time, and coming back into the network after having been connected to dozens of public hotspots while someone was on a vacation with it. While many of these management functions work right out of the box with a standard DirectAccess configuration, there are some functions that will need a couple of extra steps to get them working properly. That is our topic of discussion for this article.
We are going to cover the following topics:
- Pulls versus pushes
- What does Manage Out have to do with IPv6
- Creating a selective ISATAP environment
- Setting up client-side firewall rules
- RDP to a DirectAccess client
- No ISATAP with multisite DirectAccess
(For more resources related to this topic, see here.)
Pulls versus pushes
Often when thinking about management functions, we think of them as the software or settings that are being pushed out to the client computers. This is actually not true in many cases. A lot of management tools are initiated on the client side, and so their method of distributing these settings and patches are actually client pulls. A pull is a request that has been initiated by the client, and in this case, the server is simply responding to that request. In the DirectAccess world, this kind of request is handled very differently than an actual push, which would be any case where the internal server or resource is creating the initial outbound communication with the client, a true outbound initiation of packets. Pulls typically work just fine over DirectAccess right away. For example, Group Policy processing is initiated by the client. When a laptop decides that it's time for a Group Policy refresh, it reaches out to Active Directory and says "Hey AD, give me my latest stuff". The Domain Controllers then simply reply to that request, and the settings are pulled down successfully. This works all day, every day over DirectAccess. Pushes, on the other hand, require some special considerations. This scenario is what we commonly refer to as DirectAccess Manage Out, and this does not work by default in a stock DirectAccess implementation.
What does Manage Out have to do with IPv6?
IPv6 is essentially the reason why Manage Out does not work until we make some additions to your network. "But DirectAccess in Server 2012 handles all of my IPv6 to IPv4 translations so that my internal network can be all IPv4, right?" The answer to that question is yes, but those translations only work in one direction. For example, in our previous Group Policy processing scenario, the client computer calls out for Active Directory, and those packets traverse the DirectAccess tunnels using IPv6. When the packets get to the DirectAccess server, it sees that the Domain Controller is IPv4, so it translates those IPv6 packets into IPv4 and sends them on their merry way. Domain Controller receives the said IPv4 packets, and responds in kind back to the DirectAccess server. Since there is now an active thread and translation running on the DirectAccess server for that communication, it knows that it has to take those IPv4 packets coming back (as a response) from the Domain Controller and spin them back into IPv6 before sending across the IPsec tunnels back to the client. This all works wonderfully and there is absolutely no configuration that you need to do to accomplish this behavior.
However, what if you wanted to send packets out to a DirectAccess client computer from inside the network? One of the best examples of this is a Helpdesk computer trying to RDP into a DirectAccess-connected computer. To accomplish this, the Helpdesk computer needs to have IPv6 routability to the DirectAccess client computer. Let's walk through the flow of packets to see why this is necessary. First of all, if you have been using DirectAccess for any duration of time, you might have realized by now that the client computers register themselves in DNS with their DirectAccess IP addresses when they connect. This is a normal behavior, but what may not look "normal" to you is that those records they are registering are AAAA (IPv6) records. Remember, all DirectAccess traffic across the internet is IPv6, using one of these three transition technologies to carry the packets: 6to4, Teredo, or IP-HTTPS. Therefore, when the clients connect, whatever transition tunnel is established has an IPv6 address on the adapter (you can see it inside ipconfig /all on the client), and those addresses will register themselves in DNS, assuming your DNS is configured to allow it.
When the Helpdesk personnel types CLIENT1 in their RDP client software and clicks on connect, it is going to reach out to DNS and ask, "What is the IP address of CLIENT1?" One of two things is going to happen. If that Helpdesk computer is connected to an IPv4-only network, it is obviously only capable of transmitting IPv4 packets, and DNS will hand them the DirectAccess client computer's A (IPv4) record, from the last time the client was connected inside the office. Routing will fail, of course, because CLIENT1 is no longer sitting on the physical network. The following screenshot is an example of pinging a DirectAccess connected client computer from an IPv4 network:
How to resolve this behavior? We need to give that Helpdesk computer some form of IPv6 connectivity on the network. If you have a real, native IPv6 network running already, you can simply tap into it. Each of your internal machines that need this outbound routing, as well as the DirectAccess server or servers, all need to be connected to this network for it to work. However, I find out in the field that almost nobody is running any kind of IPv6 on their internal networks, and they really aren't interested in starting now. This is where the Intra-Site Automatic Tunnel Addressing Protocol, more commonly referred to as ISATAP, comes into play. You can think of ISATAP as a virtual IPv6 cloud that runs on top of your existing IPv4 network. It enables computers inside your network, like that Helpdesk machine, to be able to establish an IPv6 connection with an ISATAP router. When this happens, that Helpdesk machine will get a new network adapter, visible via ipconfig / all, named ISATAP, and it will have an IPv6 address. Yes, this does mean that the Helpdesk computer, or any machine that needs outbound communications to the DirectAccess clients, has to be capable of talking IPv6, so this typically means that those machines must be Windows 7, Windows 8, Server 2008, or Server 2012. What if your switches and routers are not capable of IPv6? No problem. Similar to the way that 6to4, Teredo, and IP-HTTPS take IPv6 packets and wrap them inside IPv4 so they can make their way across the IPv4 internet, ISATAP also takes IPv6 packets and encapsulates them inside IPv4 before sending them across the physical network. This means that you can establish this ISATAP IPv6 network on top of your IPv4 network, without needing to make any infrastructure changes at all.
So, now I need to go purchase an ISATAP router to make this happen? No, this is the best part. Your DirectAccess server is already an ISATAP router; you simply need to point those internal machines at it.
Creating a selective ISATAP environment
All of the Windows operating systems over the past few years have ISATAP client functionality built right in. This has been the case since Vista, I believe, but I have yet to encounter anyone using Vista in a corporate environment, so for the sake of our discussion, we are generally talking about Windows 7, Windows 8, Server 2008, and Server 2012. For any of these operating systems, out of the box all you have to do is give it somewhere to resolve the name ISATAP, and it will go ahead and set itself up with a connection to that ISATAP router. So, if you wanted to immediately enable all of your internal machines that were ISATAP capable to suddenly be ISATAP connected, all you would have to do is create a single host record in DNS named ISATAP and point it at the internal IP address of your DirectAccess server. To get that to work properly, you would also have to tweak DNS so that ISATAP was no longer part of the global query block list, but I'm not even going to detail that process because my emphasis here is that you should not set up your environment this way.
Unfortunately, some of the step-by-step guides that are available on the web for setting up DirectAccess include this step. Even more unfortunately, if you have ever worked with UAG DirectAccess, you'll remember on the IP address configuration screen that the GUI actually told you to go ahead and set ISATAP up this way.
Please do not create a DNS host record named ISATAP! If you have already done so, please consider this article to be a guide on your way out of danger.
The primary reason why you should stay away from doing this is because Windows prefers IPv6 over IPv4. Once a computer is setup with connection to an ISATAP router, it receives an IPv6 address which registers itself in DNS, and from that point onward whenever two ISATAP machines communicate with each other, they are using IPv6 over the ISATAP tunnel. This is potentially problematic for a couple of reasons. First, all ISATAP traffic default routes through the ISATAP router for which it is configured, so your DirectAccess server is now essentially the default gateway for all of these internal computers. This can cause performance problems and even network flooding. The second reason is that because these packets are now IPv6, even though they are wrapped up inside IPv4, the tools you have inside the network that you might be using to monitor internal traffic are not going to be able to see this traffic, at least not in the same capacity as it would do for normal IPv4 traffic.
It is in your best interests that you do not follow this global approach for implementing ISATAP, and instead take the slightly longer road and create what I call a "Selective ISATAP environment", where you have complete control over which machines are connected to the ISATAP network, and which ones are not.
Many DirectAccess installs don't require ISATAP at all. Remember, this is only used for those instances where you need true outbound reach to the DirectAccess clients. I recommend installing DirectAccess without ISATAP first, and test all of your management tools. If they work without ISATAP, great! If they don't, then you can create your selective ISATAP environment.
To set ourselves up for success, we need to create a simple Active Directory security group, and a GPO. The combination of these things is going to allow us to decisively grant or deny access to the ISATAP routing features on the DirectAccess server.
Creating a security group and DNS record
First, let's create a new security group in Active Directory. This is just a normal group like any other, typically a global or universal, whichever you prefer. This group is going to contain the computer accounts of the internal computers to which we want to give that outbound reaching capability. So, typically the computer accounts that we will eventually add into this group are Helpdesk computers, SCCM servers, maybe a management "jump box" terminal server, that kind of thing. To keep things intuitive, let's name the group DirectAccess – ISATAP computers or something similar. We will also need a DNS host record created. For obvious reasons we don't want to call this ISATAP, but perhaps something such as Contoso_ISATAP, swapping your name in, of course. This is just a regular DNS A record, and you want to point it at the internal IPv4 address of the DirectAccess server.
If you are running a clustered array of DirectAccess servers that are configured for load balancing, then you will need multiple DNS records. All of the records have the same name,Contoso_ISATAP, and you point them at each internal IP address being used by the cluster. So, one gets pointed at the internal Virtual IP (VIP), and one gets pointed at each of the internal Dedicated IPs (DIP). In a two-node cluster, you will have three DNS records for Contoso_ISATAP.
Creating the GPO
Now go ahead and follow these steps to create a new GPO that is going to contain the ISATAP connection settings:
- Create a new GPO, name it something such as DirectAccess – ISATAP settings.
- Place the GPO wherever it makes sense to you, keeping in mind that these settings should only apply to the ISATAP group that we created.
- One way to manage the distribution of these settings is a strategically placed link.
- Probably the better way to handle distribution of these settings is to reflect the same approach that the DirectAccess GPOs themselves take. This would mean linking this new GPO at a high level, like the top of the domain, and then using security filtering inside the GPO settings so that it only applies to the group that we just created. This way you ensure that in the end the only computers to receive these settings are the ones that you add to your ISATAP group.
I typically take the Security Filtering approach, because it closely reflects what DirectAccess itself does with GPO filtering. So, create and link the GPO at a high level, and then inside the GPO properties, go ahead and add the group (and only the group, remove everything else) to the Security Filtering section, like what is shown in the following screenshot:
Then move over to the Details tab and set the GPO Status to User configuration settings disabled.
Configuring the GPO
Now that we have a GPO which is being applied only to our special ISATAP group that we created, let's give it some settings to apply. What we are doing with this GPO is configuring those computers which we want to be ISATAP-connected with the ISATAP server address with which they need to communicate , which is the DNS name that we created for ISATAP.
First, edit the GPO and set the ISATAP Router Name by configuring the following setting:
Computer Configuration | Policies | Administrative Templates | Network | TCPIP Settings | IPv6 Transition Technologies | ISATAP Router Name = Enabled (and populate your DNS record).
Second, in the same location within the GPO, we want to enable your ISATAP state with the following configuration:
Computer Configuration | Policies | Administrative Templates | Network | TCPIP Settings | IPv6 Transition Technologies | ISATAP State = Enabled State.
Adding machines to the group
All of our settings are now squared away, time to test! Start by taking a single computer account of a computer inside your network from which you want to be able to reach out to DirectAccess client computers, and add the computer account to the group that we created. Perhaps pause for a few minutes to ensure Active Directory has a chance to replicate, and then simply restart that computer. The next time it boots, it'll grab those settings from the GPO, and reach out to the DirectAccess server acting as the ISATAP router, and have an ISATAP IPv6 connection. If you generate an ipconfig /all on that internal machine, you will see the ISATAP adapter and address now listed as shown in the following screenshot:
And now if you try to ping the name of a client computer that is connected via DirectAccess, you will see that it now resolves to the IPv6 record. Perfect! But wait, why are my pings timing out? Let's explore that next.
Setting up client-side firewall rules
Your internal ISATAP machine now has the ability to route packets out to the DirectAccess client computers through the ISATAP tunnel, but why on earth would the Windows Firewall that is running on those DirectAccess clients allow ICMP, RDP, SMB, or any traffic from this weird, IPv6-based ISATAP client that is all of a sudden trying to hit it? Our next and final step is to configure Windows Firewall with Advanced Security (WFAS) rules on the DirectAccess client computers so that they allow these communications from the internal ISATAP machines, instead of dropping those packets, like they do by default. I said it once, and I'll say it again, Group Policy is awesome, so let's use another GPO to define these WFAS rules.
It is a common mistake to modify the existing DirectAccess Client Settings GPO that DirectAccess creates and uses, and to plug these new rules into that GPO rather than create another new GPO. Please don't do this. The DA GPOs should be left alone, because they are automatically adjusted by the wizards, so your changes may get thrown out at some point. Make sure to use a separate GPO for these WFAS settings. Perhaps the same one you created for the Teredo and 6to4 best practice settings, because these are also settings that need to be applied only to the DirectAccess client computers.
Inside the GPO that you have chosen for this task, this is the section where we can add some WFAS rules using following configuration:
Computer Configuration | Policies | Windows Settings | Security Settings | Windows Firewall with Advanced Security | Windows Firewall with Advanced Security | Inbound Rules
Just like you would do from inside the firewall console were you working straight from the client machine, you simply need to right-click and choose New Rule…. Most rules are going to be Port rules, then click on Next, then specify which port you would like to allow. You can either include multiple ports in one rule, or create multiple rules, one for each port.
Choose Allow the connection, and on the screen where you define which Firewall Profiles to allow it to apply, you can choose all three if you would like, but ultimately we probably only care about applying these rules while the client is connected via DirectAccess. Anytime that a client computer is on DirectAccess, it will have either the Public or Private profile assigned, so selecting those two are the important ones. Finish out the wizard by naming the rule, and once your rule is complete, we need to right-click on the rule and head into its properties and change a couple of more advanced items.
On the Advanced tab, we need to change the Edge traversal drop-down menu to Allow edge traversal. This is important for making these rules function when the client is connected using the Teredo protocol.
Remember, you will have to create rules for each protocol that you want to be accessible when reaching out to these DA clients from the internal network. The most typical ones I see are RDP (TCP 3389), File Access (TCP 445), and ICMPv6, so that ping replies work.
At this point, the rule will work and you could move on to the next section where we test the RDP connection. However, the rule is currently allowing RDP from anywhere, and to tighten down security on that rule a little, we should really set it up so that this RDP rule is only allowing RDP connections from computers that are inside the ISATAP network. To do this, in the rule's Properties, we need to head into the Scope tab. Now, under the Remote IP address field, we want to change it to These IP addresses, and enter in the IPv6 prefix that our ISATAP environment uses. For me, the easiest way to determine that prefix is to look at the ipconfig /all that we did from the internal ISATAP connected computer (shown earlier in the article). In that screenshot, my ISATAP IPv6 address is 2002:836b:1e:1:0:5efe:10.0.0.3—you notice that the end of this is my actual IPv4 address. For the prefix to add to this WFAS rule, we want to allow RDP connection from any ISATAP host, so our prefix is going to be 2002:836b:1e:1:0:5efe:0.0.0.0/96.
Click on OK, and you should see something similar to this in your Scope.
RDP to a DirectAccess client
IPv6 routing established via ISATAP tunnels? Check. Firewall rules on the DirectAccess clients to allow this traffic? Check. Now we are really ready to test. Log onto one of your newly furnished ISATAP machines inside the network, and try to contact a DirectAccess computer by name. A common first test is ping, which is fine, though if we get down into the nitty-gritty, we would find that ICMP traffic actually moves outside of the IPsec tunnels, and so a successful ping reply doesn't necessarily mean that everything is working. It usually does though. Otherwise, the most common testing platform is an RDP connection. This, of course, implies that you have enabled the system rule on those systems to allow RDP connections in the first place and that 3389 is one of the ports you allowed in the rules we created a few minutes ago. If those things are in place, you should now be able to open up the Remote Desktop Client from your ISATAP connected machine, type in the name of a DirectAccess client computer, have that name resolve to the IPv6 address the client is using via DirectAccess, and make a successful RDP connection to that box. Nice work!
No ISATAP with multisite DirectAccess
If you remember back a few pages, we talked about Windows preferring IPv6 over IPv4 whenever v6 is available. That, combined with the fact that an internal computer's ISATAP connection essentially default-routes all IPv6 traffic to its ISATAP router (the DirectAccess server) all the time, means that ISATAP and multisite DirectAccess don't really work together. If you had multiple DirectAccess entry points, each one of them running as an ISATAP router, your internal servers or PCs that you intend to join to the ISATAP network can only point one place. So they are going to hit either Site A or Site B, not both. This means that their responses to the client machines are always going to go out whichever site they are connected to for ISATAP. If a DirectAccess client is coming in through Site A and the Helpdesk computer is ISATAP connected to Site A, that will work fine. If a DirectAccess client is coming in through Site B, however, the packets from the Helpdesk computer will be trying to flow through Site A's DirectAccess server, which doesn't have IPsec tunnels out to the DA client, and that communication will fail. There used to exist some documentation from Microsoft on setting up ISATAP in a multisite fashion, where you offloaded the ISATAP router/server role onto its own equipment (its own Windows servers) in each site. As far as I know, this documentation has now been pulled because it was quite complicated to set up, and didn't really work as intended anyway. This is no longer a supported scenario, and I recommend you stay away from it. If you need outbound management access in a DirectAccess multisite environment, you will have to do real IPv6 inside your network and tap into that.
You can successfully use ISATAP in a cluster/array of DirectAccess servers that are on the same subnet. It is only when using multiple physical sites that you lose the ability.
ISATAP is typically misunderstood, and I hope this article has given you some straight-shooting information about its use in the real world. Many IPv6 guys consider ISATAP to be the red-headed stepchild of IPv6, but the reality is that there are many more companies today and in the future who are going to be running ISATAP environments, rather than real IPv6 environments. Once you know how to make ISATAP work for you and do what you want, it's really quite a useful tool. To anyone reading this that already has DirectAccess implemented in your network, check DNS for the existence of a record named ISATAP. If it exists, please take the time to delete it and set it up right, as per the instructions in this article. You may never thank me, because doing so means you never have to deal with strange routing or resolution problems down the road like you may have had to should you continue with your global approach.
Resources for Article:
- Troubleshooting OpenVPN 2: Configurations [Article]
- Troubleshooting WebSphere Security-related Issues [Article]
- An Overview of Microsoft Sure Step [Article]