With the upcoming release of Unified Access Gateway 2010 (UAG) Service Pack 1, we decided it was important to discuss some important scenarios that many of our customers have asked us about. These scenarios are:
- Business Continuity
- Disaster Recovery
- Multi-Geo (Multi-site) deployment
We believe that support for each of these scenarios is important for an enterprise ready solution. Business continuity and disaster recovery needs to be part of any solution designed to provide your users seamless and transparent connectivity to resources that give your firm a competitive advantage. In addition, support for multiple, geographically dispersed sites is also considered important in an era of international business can travel and we consider support for this scenario to be central in our near term goals for UAG.
While UAG Service Pack 1 (UAG SP1) can provide you basic support for business continuity, disaster recovery and multi-geo scenarios, we want you to know that we plan to address each of these scenarios with a post-UAG SP1 update and that work is already underway.
However, until we are able to deliver this update to you, we want to provide you some guidance for supported workarounds for these scenarios.
Business Continuity and Disaster Recovery
In the area of business continuity and disaster recovery we recommend that you create a “mirrored” installation of your UAG DirectAccess server or array. This can be a hot or cold standby that is configured with the same IP addresses as the production server or array. If the production array should fail, you can bring up the standby server or array and take advantage of ISP subnet redundancy so that traffic is routed to the backup deployment. When the primary UAG DirectAccess server or array comes back up, you take down the backup and route the traffic back through the original route.
Multiple Geographic Locations and Load Balancing Multiple Entry Points
There are two primary scenarios to consider when deploying UAG SP1 DirectAccess servers or arrays in multiple locations:
- Your intranet resources are all IPv4
- Your intranet resources are a mix of IPv4 and IPv6
Intranet Resources are all IPv4
If all your intranet resources are accessible only through IPv4 addresses (IPv4-only network), then you will take advantage of the UAG SP1 NAT64/DNS64 IPv6 to IPv4 protocol translator. In this scenario the source IP address of the incoming connections from DirectAccess clients is always an internal IP address on the UAG DirectAccess server or array. Your existing IPv4 routing infrastructure will be able to route these connections from the UAG DirectAccess server or array to the destination resource and responses back to the UAG DirectAccess server or array that the DirectAccess client is connected to. In this scenario you do not need to worry about IPv6 routing on the intranet.
You would install multiple UAG DirectAccess servers or arrays and apply the DirectAccess client and server settings by using different GPOs (which are specific to the particular UAG DirectAccess server or array)and assigning those GPOs to different OUs or security groups. If you are using a pre-SP1 deployment of UAG, you can use the methods discussed in the blog post http://blogs.technet.com/b/edgeaccessblog/archive/2010/02/18/deep-dive-into-uag-directaccess-tweaking-the-gpos.aspx to deploy the settings to different OUs. If you plan to deploy this scenario with UAG SP1, you can take advantage of the new GPO deployment features included in UAG SP1 which make custom deployment of GPOs to OUs or security groups available in the UAG DirectAccess wizard.
This method enables you to assign a fixed number of clients (based on the fixed number of computer accounts that belong to an OU or security group that you configure) to each UAG DirectAccess server or array. While this method allows for a static level of load balancing (DirectAccess clients can be split relatively evenly between servers or arrays), this approach does not allow users to change which array they connect to. This change requires that an administrator move the computer account to a different security group or OU.
Intranet Resources are IPv4 and IPv6
In this scenario, you would take advantage of the same distribution of DirectAccess clients are you would with an IPv4-only intranet – by assigning clients to a specific UAG DirectAccess server or array through the use of different GPOs or security groups. What changes in this scenario is how you handle the IPv6 routing requirements in a geographically distributed environment.
In this scenario you can configure a single ISATAP cloud and deploy multiple ISATAP routers that are on-link with the UAG DirectAccess server or array at each location. To make this work, you need to do the following:
- Prevent DirectAccess clients from connecting to the UAG DirectAccess server or array using the 6to4 protocol. You can accomplish this by blocking IP Protocol 41 inbound through your edge firewalls.
- Install an ISATAP router on the same link as the internal interface of the UAG DirectAccess server or array (that is to say, on the same physical or virtual segment).
- Generate an IPv6 address space and assign both the ISATAP and UAG server or array addresses from this address space. You can find detailed instructions on how to generate an internal IPv6 address space and how to assign and use these IPv6 addresses on a UAG DirectAccess server or array in the blog post http://blogs.technet.com/b/edgeaccessblog/archive/2010/05/17/configuring-an-external-load-balanced-uag-directaccess-array-for-an-ipv4-only-network.aspx
- Allocate a /64 ISATAP prefix for your entire intranet and use the same prefix for all your ISATAP routers.
- On each of the ISATAP routers, add a specific /64 Teredo route, based on the Teredo address space that is generated by the UAG for that server’s or array’s clients.
- On each of the ISATAP routers, add a specific /64 IP-HTTPS route based on the IP-HTTPS address space that is generated by UAG for that server’s or array’s clients.
- Add a resource record for ISATAP for each ISATAP router. ISATAP hosts will receive all ISATAP resource records from the DNS server and will send router solicitation requests to each ISATAP server so that the ISATAP hosts are aware of all routes back to DirectAccess clients.
One other thing worth highlighting is the fact that the ISATAP Router needs to be configured with two IPv6 addresses:
- The ISATAP address is used by the entire organization to reach the ISATAP router
- The native IPv6 address is used on the ISATAP router to communicate with the UAG server
Figure 1 provides a high level overview of what this configuration looks like.
Figure 1 Workaround for an intranet with IPv6 ISATAP resources
Figure 1 shows that the ISATAP router in Asia is configured with routes for the Asia UAG Teredo and IP-HTTPS address space to the Asia UAG DirectAccess server. It also shows that the ISATAP router in the USA is configured with routes for the USA UAG Teredo and IP-HTTPS address space to the USA UAG DirectAccess server.
If you have some experience with IPv6 and ISATAP, the configuration should not be too difficult to accomplish. However, if you would like to see how this configuration works in a Test Lab, we plan to publish a Test Lab Guide – Test Lab Guide: Demonstrate UAG SP1 DirectAccess in a Multi-Site Configuration soon after the release of UAG SP1, which should help speed you understanding of the overall solution. For a list of current UAG Test Lab Guides, be sure to check out UAG DirectAccess Test Lab Guide Portal page at http://social.technet.microsoft.com/wiki/contents/articles/uag-directaccess-test-lab-guide-portal-page.aspx
Authors:
Ben Bernstein, Senior Program Manager, DirectAccess
Tom Shinder (tomsh@microsoft.com), Knowledge Engineer/Principal Technical Writer, Anywhere Access Group (AAG)
