VMware vShield 4.1, not for the SMB

Last night while working with one of my favorite customers to replace a NIC on a DirectAccess server, we discovered that the internal network was configured with a “global” approach to using ISATAP. I have seen this many times over the past couple of years, anyone who has stood up a DirectAccess environment following one of the Test Lab Guides out there most likely ends up with their network in this state, with a DNS host record for the word ISATAP. This is exactly what the TLGs tell you to do, but is actually not a good practice. I believe that some of the documentation out there specifies to take this approach because it’s easy to setup, and also because back when DirectAccess was new, we really didn’t know any better.

What is ISATAP?

Let’s back up a little. The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) is an IPv6 tunneling technology. Most DirectAccess admins are familiar now with 6to4, Teredo, and IP-HTTPS. These three technologies are also IPv6 tunneling technologies, designed to take IPv6 packets and encapsulate them inside IPv4 headers, so that those packets can successfully transport across an IPv4 network. (aka the Internet for these three transition technologies). ISATAP does essentially the same thing, but for the inside of your network. I like to think of ISATAP as a “virtual IPv6 cloud” inside your corporate network. Once your internal computers/servers have set themselves up as ISATAP clients, they will receive an IPv6 address and routing information from the DirectAccess server. When this happens, because Windows prioritizes IPv6 over IPv4, whenever ISATAP host computers communicate with each other, they will do so using their ISATAP IPv6 tunnels, instead of their regular IPv4 LANtransport.

Why is this a problem?

If ISATAP is enabled globally in your environment, that means that any ISATAP capable host system will automatically become an ISATAP connected host system. Any Server 2008, Server 2012, Windows 7 or Windows 8 boxes inside your corporate network will automatically set themselves up with one of these ISATAP IPv6 addresses. When this happens, as stated above, all traffic between these hosts is now going to prefer to use that IPv6 tunnel rather than the regular IPv4 network. Well, it’s technically still using the IPv4 network, but is pushing encapsulated packets across the network now, instead of native IPv4. This means that if you are using an IDS/IPS to monitor traffic inside your network, you probably won’t be able to see this traffic. It will also make troubleshooting network issues inside the network quite a bit harder, because you’re going to notice all of these IPv6 addresses and packets flowing around, and it’ll take a lot longer to identify a connectivity problem with a systeminside the network. Finally, you only have one ISATAP router when you setup this global approach, which is the DirectAccess server. This means that your DirectAccess server is now doing all the grunt work of being an ISATAP relay (sort of a DHCP server) for all of these internal hosts, sometimes thousands of them. It also means that the DirectAccess server is now the default router for all of the internal hosts traffic! This is obviously going to put unnecessary load on the DirectAccess server and the network where it resides. In the worst cases, using global ISATAP can cause connectivity issues and even network flooding.

History of ISATAP, as it relates to DirectAccess

So if it has the potential for so many problems, why is it the default implementation path in the Test Lab Guides? This answer goes all the way back to Server 2008 R2’s release. This operating system was the first time that the word DirectAccess appeared. Most folks are familiar with UAG DirectAccess and Server 2012 DirectAccess, now that it’s becoming more and more popular. But there was another version of DirectAccess, back in Server 2008 R2’s native operating system, and it came with some hitches. The biggest requirement was that the internal network had to be IPv6. This just isn’t a reality for customers, even today, and so it would have been a complete showstopper. Cue ISATAP. In Server 2008 R2 DirectAccess, you could use ISATAP to easily spin up a virtual IPv6 environment that ran on top of your internal IPv4 network, and then you could easily make use of DirectAccess! In the newer versions of DirectAccess, both UAG and Server 2012, there are some new components called NAT64 andDNS64 that work together to ensure that you don’t have any IPv6 requirements anymore. In Server 2008 R2, to be able to get those client IPv6 packets into the network, you needed an IPv6 network inside to send them to. With NAT64 and DNS64, the DirectAccess server now has the ability to take those client IPv6 packets and spin them down into IPv4 packets, so you can simply leave your internal network all IPv4. So back in the beginning it was standard practice to enable ISATAP globally. Today, because of the known issues, it is recommended not to use ISATAP at all, unless you have a specific reason for needing it…

In what cases would I actually want ISATAP?

Now you know the history on ISATAP and the fact that we no longer implement it unless needed, but how do you know whether or not you need it? If you have IPv6 inside your network, you definitely do NOT need ISATAP. I just wanted to start by saying that. However, almost nobody has IPv6 inside their network yet. So assuming that your internal network is IPv4, as we talked about already DirectAccess will work just fine, because of the new NAT64 and DNS64 technologies. So with no ISATAP in your environment, we can absolutely get DirectAccess connected and working. However, what happens if you have the need to send packets outbound toward your DirectAccess client machines? I’m not talking about things like updates or Group Policies or anything like that, because those items are all client-side pulls, and they will work over DirectAccess with no ISATAP or any special considerations. But if you have the case where you need to do a true “manage-out” to the DirectAccess client machines, like aninternal helpdesk computer needing to RDP into a DirectAccess client computer, this requires the helpdesk computer to have an IPv6 layer of transport available with which to contact the IPv6 DirectAccess client. This is where the need for ISATAP comes in.

How to configure ISATAP

If you do determine that ISATAP could benefit the way that you use DirectAccess, DO NOT CREATE A DNS HOST RECORD CALLED ISATAP. Doing so will turn ISATAP on globally, and I direct you back to the beginning of this article. You will want to create a “Selective ISATAP” environment, where you get to determine manually which internal machines will take advantage of ISATAP and set themselves up as ISATAP hosts. This will leave the majority of your internal network on IPv4, business as usual, and will be a much, much safer way of implementing. Here are a couple of web links that will assist with your ISATAP configuration:

First, Jason Jones has a great article on setting up a Selective ISATAP environment:

And I had the opportunity recently to put an extensive step-by-step together on this topic, in one of the chapters of this book:

Jordan Krause Microsoft MVP | Enterprise Security