Friday, 8 January 2010

The Path to DirectAccess – Part 1: Choosing the DirectAccess Platform

So, let’s begin by asking a simple question; what is DirectAccess? Well, DirectAccess is a new feature in Windows 7 and Windows Server 2008 R2 that gives users the experience of being seamlessly connected to their corporate network any time they have Internet access. With DirectAccess enabled, requests for corporate resources (such as email servers, shared folders, or intranet Web sites) are securely directed to the corporate network, without requiring users to connect to a virtual private network (VPN).

I began looking at DirectAccess while getting to grips with Windows Server 2008 R2 during its early release. Although the technology was hugely impressive, it had limited application potential for many customers as the required dependencies set the bar pretty high in terms of an expected supporting infrastructure; the killer element being the need for native Internet Protocol version 6 (IPv6).

Until more recently, my exposure to IPv6 had been relatively small and was placed in my “I really need to learn more about that…” mental R&D queue. Slightly naively, I also saw it as ‘IPv4 with longer addresses’ which I now know is very far from the truth as the protocol includes a lot of new concepts and considerations. The extent to which you need to understand these concepts and considerations is obviously very dependant on the specific application though. As DirectAccess is hugely dependent on IPv6, we have a little work to do in this area…more to follow with regard to IPv6 in a future article…

Having been exposed to this new technology path, I thought it might be useful to share my experiences and offer some guidance for those undertaking a similar journey. A working DirectAccess deployment is a joy to behold, where seamless and transparent access to intranet resources brings back a little IT sparkle for users when compared to other traditionally cumbersome remote access solutions.

I plan to provide a series of articles that cover the key elements in order to deploy DirectAccess (DA); specifically when using Forefront Unified Access Gateway (UAG) as the DA platform, as opposed to the native DirectAccess offering provided by Windows Server 2008 R2. So, why do we need to use UAG? Well, we don’t need to, but there are some very compelling reasons for doing so, and that is the whole point of this first article in the series…

From this point forwards, I will use the following terms throughout this and the upcoming articles:

  • Native DirectAccess => This term is used to imply the use of DirectAccess which is provided as part of the native Windows Server 2008 R2 feature set.
  • UAG DirectAccess => This term is used to imply the use of DirectAccess which is provided as an integrated offering of the Forefront UAG feature set.

So, back to my previous question, why do we need to use UAG? Well, this is best answered by looking at what native DA cannot do and what UAG DA provides over and above the native DA solution; time for a summary table, I think:

Feature

Native DirectAccess

UAG DirectAccess

Access to IPv6-only intranet resources

Yes

Yes

Access to Legacy IPv4-only intranet resources

No

Yes

Easy to Scale Out

No

Yes

High Availability

Basic

(needs Hyper-V failover)

Advanced

(NLB included “in the box”)

Centrally managed

No

Yes

Support for Legacy Windows clients

No

Yes, via SSL VPN

Support for non-Windows clients

No

Yes, via SSL VPN

Deployment

Complex

Simpler

Cost Included with Win2k8 Win2k8 + UAG Server + CALs
Edge Ready No Yes

If we now consider operating systems with support for IPv6, this can be summarised as shown in the following table:

Operating System

IPv6 Enabled

IPv4 Enabled

Windows Server 2008 R2

Yes

Yes

Windows Server 2008

Yes

Yes

Windows 7

Yes

Yes

Windows Vista

Yes

Yes

Windows XP

No*

Yes

Windows Server 2003

No*

Yes

Windows Server 2000

No

Yes

Legacy Application Server

No (Unlikely)

Yes

Non-Windows Server

No (Maybe)

Yes

* IPv6 is not natively enabled, but can be configured. However, hosted applications are unlikely to be IPv6 aware on this server platform.

Looking at both tables, it should be pretty easy to see that the two key areas which are likely to be the most deployment restrictive (highlighted in red) when using native DA are:

  • Access to Legacy IPv4-only Intranet Resources
  • High Availability

Obviously, if you have basic high availability requirements and already meet the requirements for an internal IPv6 deployment then the native solution may be viable. However, in my experience, the environments who can achieve this are very much in the minority.

So, why are the limitations of native DA so impacting? Well, I have yet to meet a customer who has fully deployed IPv6 on their internal networks and configured the appropriate addressing on all clients and servers. Consequently, native DA will not be able to provide access to existing IPv4 only resources like Windows Server 2003 or other IPv4 based application servers. For most environments, this will represent a considerable proportion of the existing server estate and hence represents a highly undesirable limitation.

UAG DA solves this problem using two translation technologies called NAT64 and DNS64 (pronounced NAT-6-to-4 and DNS-6-to-4).

NAT64 (as the name suggests) provides DirectAccess clients with access to IPv4-only resources. The NAT64 function in Forefront UAG allows IPv6 traffic to be initiated towards IPv4 servers and for the traffic responses to return correctly.

Please Note: NAT64 does not work in reverse; so if traffic needs to be initiated outbound to the DirectAccess-enabled clients, this capability is not available with NAT64. Consequently, in order to achieve outbound access to DA clients (usually for client management) it is necessary to configure Management Servers with native IPv6 support <hint>

DNS64 (as the name also suggests) modifies the DNS query replies, so that requests for the name of an intranet server have their IPv4 addresses converted into an appropriate IPv6 address response. This ensures that DNS queries from DirectAccess clients are resolved to the IPv6 address of the UAG server performing the inbound NAT64 translation.

A good overview of these elements is presented in the following UAG team blog article:

Deep Dive Into DirectAccess – NAT64 and DNS64 In Action

Once you begin using DA day to day, you will quickly become used to ubiquitous access to corporate resources and your expectations of remote access availability will be far greater than ever before. Consequently, when DA stops working, you will feel hugely isolated and the impact to productivity will ultimately be felt by all DA users. Therefore, high availability for the DA service soon becomes a very important consideration, even if not considered so at the beginning. Based upon the limited options available with native DA, this becomes a strong secondary driving force in the decision to use UAG DA. As expected, this was one of the key design goals for the Microsoft UAG product group, in addition to the use of critical NAT64 and DNS64 features to provide IPv6 to IPv4 translation, as discussed above.

Forefront UAG allows DirectAccess services to be placed into an array to load balance DirectAccess client requests. It its native form, DirectAccess is integrated with NLB; so if one of the servers in the array fails, it’s removed from the array and requests are sent to the remaining servers. It is interesting to note that currently, only one hardware load balancer vendor (F5 Networks) provides support for Forefront UAG when it is used with an array for DirectAccess. Therefore, NLB is pretty likely to be used for many UAG DA deployments when designing a high availability architecture.

In my opinion, these two limitations alone, are a good enough reason for UAG DA to be the only realistic entry level option for any DirectAccess deployment. In my ‘day job’ I strongly recommend that customers looking at DirectAccess move straight to using UAG DA, without even considering Native DA, where possible.

So, with our DirectAccess platform choice made, let’s get started deploying UAG DA! Well, that’s enough for Part 1, so I hope to see you back soon for the next instalment in the series titled Part2: Thinking About IPv6. For those of you who have been reading closely, you may now be thinking “Why do we need to worry about IPv6 if we are using NAT64?”; and that is a very good question I will leave with you…

For the remaining articles in the series, we will look at deploying UAG DA for an example environment and attempt to provide a real-world slant on how best to use the technology available. I hope to share some useful lessons learnt from my release candidate deployment experiences and also how to extend the solution with Network Access Protection (NAP).

5 comments:

  1. Coul be Forefront TMG + DA ?(instead of Forefront UAG + DA).
    Currently I will replace my ISA Server 2006 Std with Forefront TMG and I have been reading many articles talking about TMG + DA

    Paul

    ReplyDelete
  2. I have read through this paper (part 1) and you have done a decent job on this article.

    ReplyDelete
  3. Good stuff!! I am diving into the process of enabling DirectAccess on our IPv4 only network right now. This will prevent me using native DirectAccess with the Server 2008 only.

    ReplyDelete
  4. 1. I found in Technet that we requires 2 public IP for DA server external interface on each server in array. Do these public DIP need to be routable on internet or any non-routable public DIP will work. Because we are already using two Public routable VIP on HLB.
    2. From which IP addresses we need to allow inbound & outbound traffic and what would be the port and direction in external firewall in case we requires routable public DIP?
    3. Inside infra is IPv4. So will NAP enforcement work if we don’t have IPv6.
    4. Do management servers need to be on IPv6?
    5. Any specific methodology we need to follow for assigning IPv6 address on internal interface, Inside infra is completely IPv4

    ReplyDelete