Submitted by Anonymous on Tue, 10/08/2013 - 12:23
I have spoken about Microsoft DirectAccess at events all around the world and introduced this compelling remote access solution to countless IT professionals over the last few years. When I explain how this seamless and transparent, always-on remote corporate network connectivity solution works, and especially after I demonstrate it in action, I see the light come on for many when they begin to realize just how transformative DirectAccess really is. They see the tremendous benefit in providing easy, familiar access to data and applications for remote users. They realize that DirectAccess is infinitely easier to manage than traditional VPN, and with the bi-directional connectivity that DirectAccess provides they start to grasp just how much more effectively they can manage their ever-increasing mobile workforce.
Unfortunately, DirectAccess isn’t for everyone. It is not the complete, be-all end-all remote access solution. I wish it was, believe me! But some of the requirements for the solution dictate otherwise. Supported clients are limited to Windows 8 Enterprise edition and Windows 7 Enterprise/Ultimate, and they must be domain-joined. However, for those organizations that meet these requirements, DirectAccess nirvana awaits...wth one exception: Not all applications work with DirectAccess.
I see many puzzled and disappointed faces when I bring up this fact. Under the hood, DirectAccess relies exclusively on IPv6 for transport and from a client perspective it cannot leverage IPv4 at all for DirectAccess communication. For the vast majority of applications available today, this is not an issue. Typically an application, when it requires network connectivity to a resource like a file or database server, will be configured to connect to the system via its hostname. It will leverage existing operating system Application Programming Interfaces (APIs) to query a DNS server to obtain the IP address that is mapped to this name. When this happens, DirectAccess works normally. If the resource has an IPv6 address, it will return that to the client application. If it has an IPv4 address, the DirectAccess server will convert it to an IPv6 address and again return that to the application. Problems arise, however, when an application does not use standard programming best practices. If the application attempts to make a direction connection to an IPv4 address, connectivity over DirectAccess will fail. In my experience, this is most common with in-house developed line of business applications where inexperienced developers take for granted that they’ll always have local area network connectivity. In other cases, applications that rely on protocols that embed IPv4 addresses will not work. Examples include SIP and FTP. In addition, IP protocol communication does not operate of DirectAccess. Examples would include Generic Routing Encapsulation (GRE). I realize that sounds odd, but I’ve had more than one customer inquire about accessing an internally isolated test lab using VPN protocols that require GRE.
Previously I mentioned that SIP does not work over DirectAccess, as the protocol itself includes embedded IPv4 addresses. This means that popular applications like Lync do not work over DirectAccess. In these cases it is recommended that organizations make Lync available on the Internet, then exclude this traffic from DirectAccess, forcing Lync traffic directly. Interestingly enough, Lync 2013 does support IPv6. Although Lync 2013 does now work with DirectAccess, Microsoft is maintaining their existing guidance with regard to Lync architecture and is discouraging the use of Lync 2013 over DirectAccess. The main reason for this is that voice and video communication is extremely sensitive to network latency, and the experience over DirectAccess with its IPsec encrypted tunnels may not provide the best experience for end users.
With regard to application compatibility, it is recommended that you deploy DirectAccess using an initial pilot group of users and to thoroughly test all applications prior to a full production implementation. When application incompatibilities are discovered, often they can be resolved by making client-side configuration changes, but sometimes they will require application code changes or perhaps even version upgrades. The important thing is to discover any limitations early in the process to that they can be remedied as soon as possible. Also, if you’re considering a DirectAccess implementation, be sure to check out Iron Networks’ excellent line of purpose-built DirectAccess appliances. To make the most of your efforts, consider leveraging Iron Networks’ pre-deployment services with our DirectAccess PopUp pilot. We also offer production implementation and rollout services that you can take advantage of to ensure the highest chance of success and the best experience for your remote access users. Give us a call today for more information!
Category: