Planning for a single or multiple Forefront UAG DirectAccess servers

This topic describes the planning requirements for deploying a single Forefront Unified Access Gateway (UAG) DirectAccess server, or an array of DirectAccess servers.

1. Overview

2. Requirements

3. Limitations

4. Planning steps

Overview

Forefront UAG can be deployed as a DirectAccess server, providing seamless access to internal resources for DirectAccess clients, and as a publishing server, providing access to internal applications via web sites and portals. You can deploy a single Forefront UAG DirectAccess server, or an array of multiple Forefront UAG DirectAccess servers. Traffic to the array can be load balanced. When planning for deployment of Forefront UAG DirectAccess servers, you must consider the following:

• Number of DirectAccess servers required—You can deploy a single Forefront UAG DirectAccess server, or expand your Forefront UAG DirectAccess capacity by deploying a load-balanced array of servers that provide high availability and scalability. Your decision to deploy a single Forefront UAG DirectAccess server, or an array of servers, depends on a number of factors, including scalability, fault tolerance, and failover requirements.

• Array requirements—If you are deploying an array of Forefront UAG DirectAccess servers, consider your array deployment requirements.

• Network topology requirements—Determine where you Forefront UAG DirectAccess servers will be located in your organization.

• Firewall configuration requirements—If the Forefront UAG DirectAccess servers are configured behind or between firewalls, verify which protocols and ports must be opened for DirectAccess traffic.

Requirements

This section summarizes the requirements for single or multiple server deployment.

Number of servers

Consider the following when deciding how many Forefront UAG DirectAccess servers you need to deploy:

• DirectAccess client requirements—Clients requirements are determined by the number of concurrent users using DirectAccess, and the Forefront UAG DirectAccess configuration. For example, deploying Forefront UAG DirectAccess with two-factor authentication, NAP, or extra infrastructure servers will all reduce the number of concurrent users that can connect to a DirectAccess server. To help you determine your client and server requirements, read Capacity planning for Forefront UAG DirectAccess with SP1.

• Scalability requirements─By grouping multiple DirectAccess servers into an array, you increase capacity for throughout and number of users. Client requests are serviced by all the array servers.

• Fault tolerance requirements─A single Forefront UAG DirectAccess server does not provide fault tolerance. If the server is unavailable, DirectAccess clients cannot connect to the DirectAccess server. If fault tolerance is required, you should consider the deployment of a load balanced array. In an array configuration, each array member has the same configuration, and provides the same service to DirectAccess clients. If one array member fails, the remaining array members are still available and client connections can continue.

• Failover requirements─To provide high availability for remote endpoints, you can load balance traffic in an array. If load balancing is enabled for the array, failover is automatic, as DirectAccess client requests can be handled by any available array member.

Array requirements

Planning for deployment of a Forefront UAG DirectAccess array requires the following:

• Each server must meet software and hardware requirements for Forefront UAG installation. For more information, see System requirements for Forefront UAG servers.

• Each server must meet general DirectAccess prerequisites. For more information, see System requirements for Forefront UAG DirectAccess.

• In an array deployment, one of the array members acts as the array manager and holds the configuration for all array members. For communications between the array manager and array members, plan for the following credentials.

  • An account used by array members connecting to the array manager server. These credentials are used when initially joining the array, and subsequently each time the array member connects to the array.

  • An account used by the array manager server when connecting to array members.

  Domain accounts must be used, from the domain in which the Forefront UAG array servers are installed. You can use the same account for both sets of credentials. The account must have local administrator permissions on the array manager, and on all array members. We recommend that you use accounts with long expiry periods.

• You can load balance array traffic using a hardware load balancer or Windows network load balancing (NLB) integrated into Forefront UAG. Requirements for integrated NLB are as follows:

  • Prefix requirements—Since Forefront UAG can be deployed as a DirectAccess server and as a publishing server, Forefront UAG enables load balancing of both SSL-based traffic and DirectAccess traffic. To load balance all IPv6 based DirectAccess traffic, the integrated NLB mechanism must examine the IPv4 tunneling for all transition technologies. Because IP-HTTPS traffic is encrypted, examining the content of the IPv4 tunnel is not possible. To enable IP-HTTPS traffic to be load balanced, you must allocate a wide enough IPv6 prefix so that Forefront UAG can to assign a different IPv6 /64 prefix to each of the nodes. For example, 2 array members require a /63 prefix (which enables Forefront UAG to define a /64 address for each array member); 8 array members require a /61 prefix (which enables Forefront UAG to define a /64 address for each array member). This prefix must be routable to the Forefront UAG DirectAccess array, and is configured during the Forefront UAG DirectAccess configuration.

  • VIP and DIP requirements—If you want to deploy an array with NLB, plan for the following dedicated IP addresses (DIPs) and virtual IP addresses (VIPs). These will be configured during array deployment, on the array manager server.

    • An Internet-facing static IPv4 address (DIP)

    • An internal network facing static IPv6 address (DIP)

    • An internal network facing static IPv4 address (DIP)

    • Two Internet-facing consecutive public IPv4 addresses (VIPs)

    • An internal network facing IPv6 address (VIP)

    • An internal network facing IPv4 address (VIP)

  • If you want to use a hardware load balancer, ensure that it is set up before array deployment.

  To learn more about array implementation in Forefront UAG, see the section About arrays in Introduction to array design.

Network topology requirements

When determining where your Forefront UAG DirectAccess servers will be located in your corporate network, consider the following:

• **Do you want to place DirectAccess servers behind a frontend firewall?**─In this configuration, the Forefront UAG DirectAccess server is placed in the internal network, behind a frontend firewall at the corporate edge. The Forefront UAG server has one network adapter that routes to the frontend firewall, and the other is in the internal network. The advantages and disadvantages are as follows:

  1. It is the simplest firewall solution, requiring the least amount of hardware and configuration.

  2. It provides a single point of data, as the Forefront UAG DirectAccess servers, management servers, and infrastructure servers, are all located within the internal network.

  3. The main disadvantage of this design is that the corporate internal network is separated from the Internet by a single firewall. Note that the Forefront UAG server itself is protected by Forefront TMG running as a firewall on the Forefront UAG server. Forefront TMG is installed by default during Forefront UAG setup.

• **Do you want to place DirectAccess servers between a frontend firewall and a backend firewall?**─In this configuration, the Forefront UAG DirectAccess server is placed in a perimeter network, between a frontend firewall protecting the edge, and a backend firewall protecting the internal network. With this configuration note the following:

  • Management servers can be isolated in the perimeter network and separated from corporate content that is intended for intranet access only.

  • If content in the perimeter network is compromised or corrupted as a result of Internet access, the integrity of the content in the corporate network is retained.

  • If Forefront UAG DirectAccess is located in the perimeter network, and published servers or infrastructure servers are located in the internal network, the backend firewall must be configured to let the required protocols and ports through the firewall, so that Forefront UAG DirectAccess servers can operate as expected.

Limitations

• All array members must belong to the same domain.

• Using an external hardware load balancer, you can deploy up to 50 servers in an array. Using integrated NLB, deployment of up to eight array members is recommended.

• If Forefront UAG DirectAccess servers are located behind a firewall or between an Internet edge firewall and a backend firewall, a public IPv4 address is required, and therefore the server should not be located behind a NAT (Network Address Translation) device.

Planning steps

1. Plan how many Forefront UAG DirectAccess servers you require for your deployment, and that each server meets the necessary system requirements.

2. If you are deploying an array do the following:

   • If you are using a hardware load balancer, plan to deployment the load balancer before beginning your array configuration.

   • Create the accounts required for array deployment.

   • If you are using integrated NLB, plan the required VIPs and DIPs

3. If you are placing your Forefront UAG DirectAccess servers behind or between firewalls, plan accordingly.

Allowing DirectAccess traffic through firewalls

Firewall requirements are summarized in the following table.

Configuring firewalls for Teredo connectivity

The Teredo transition technology is used by DirectAccess clients behind NAT devices. Firewalls must be configured specifically to allow Teredo traffic, otherwise clients behind NAT devices cannot be managed remotely, or connect to intranet resources over Teredo. Configure the following:

• Allow inbound ICMPv6 Echo Requests on all intranet computers—To ensure that a destination is reachable, Teredo clients send an ICMPv6 Echo Request message, and wait for an ICMPv6 Echo Reply message. For a Teredo-based DirectAccess client to communicate with an intranet resource, that resource must accept inbound ICMPv6 Echo Request messages.

• Enable edge traversal on inbound management traffic—If you are using Windows Firewall with Advanced Security to block unsolicited inbound traffic, you already have a set of inbound rules that allow the traffic from your management servers. Because DirectAccess clients located behind NAT devices will use Teredo for IPv6 connectivity to the Forefront UAG DirectAccess server, you must enable edge traversal on this set of inbound rules.

• Enable inbound ICMPv6 Echo Requests for management traffic— For a managed DirectAccess client computer to be reachable over Teredo, ensure that the computer has an inbound rule for ICMPv6 Echo Request messages, with edge traversal enabled. The Netsh.exe command for this rule is as follows:

  • netsh advfirewall firewall add rule name="Inbound ICMPv6 Echo Request with Edge traversal" protocol=icmpv6:128,any dir=in action=allow edge=yes profile=public,private

Configuring firewalls for management servers

To configure firewalls for management servers, you must do the following:

• Configure inbound firewall rules to allow management of DirectAccess clients on the Internet—To allow remote management of DirectAccess clients, do one of the following:

  • If you already have an existing set of inbound firewall rules for management traffic on your intranet, configure these rules so that they also apply to the public and private profiles, and have edge traversal enabled. Although easier to configure, this option is not recommended because the inbound rules might allow greater exposure than intended.

  • Alternatively you can create a duplicate set of inbound firewall rules for your management traffic in the group policy object for DirectAccess clients so that they:

    • Only apply to the public and private profiles

    • Have the appropriate source IPv6 addresses of management computers, or the IPv6 prefix of your intranet

    • Have edge traversal enabled

    This is the recommended option because it applies the rules only to DirectAccess clients, is scoped for your intranet IPv6 addresses or prefix, and does not affect other domain computers on the intranet or Internet.

  It is recommended that you create a separate GPO for the rules to be applied to DirectAccess clients, because when Forefront UAG DirectAccess configuration script is applied, the Windows Firewall and Advanced Security section of the DirectAccess client GPO is cleared.

  To create the connection rules below using the Netsh command-line tool, but in a GPO context, see Use Netsh to Configure GPOs (https://go.microsoft.com/fwlink/?LinkId=169485).

• Configure edge traversal— Your existing set of inbound packet filters that allow management computers to initiate connections with your intranet computers, must be modified to enable edge traversal for Teredo-based DirectAccess clients. For information about creating inbound rules, see Create an Inbound Program or Service Rule (https://go.microsoft.com/fwlink/?LinkId=178213)

  You can enable edge traversal for a Windows Firewall inbound rule in the following ways:

  • Using the Windows Firewall with Advanced Security snap-in, obtain the properties of an inbound rule, click the Advanced tab, then, in Edge traversal select Allow edge traversal.

  • Use the edge=yes option for the netsh advfirewall firewall command when adding or changing an inbound rule.

The following is an example of a Netsh.exe command that enables edge traversal for the built-in Remote Desktop (TCP-In) inbound rule:

netsh advfirewall firewall set rule name=”Remote Desktop (TCP-In)” dir=in new edge=yes

To further ensure that the Remote Desktop connection is authenticated and encrypted, use the following Netsh.exe command:

netsh advfirewall firewall set rule name=”Remote Desktop (TCP-In)” dir=in new security=authenc edge=yes

To use the security=authenc setting, ensure that there is a connection security rule that protects the connection between the remote desktop computer and the DirectAccess client.

If the computer that is managing a DirectAccess client from the intranet is running Windows Vista or Windows Server 2008, and IPsec transport mode is required between the managing computer and the DirectAccess client, both computers must have the same quick mode lifetime.