DirectAccess is a feature of Windows that allows connectivity to organization network resources without the need for traditional Virtual Private Network (VPN) connections. With DirectAccess, client computers are always connected to your organization – there is no need for remote users to start and stop connections as is required with traditional VPN connections. From a user’s perspective DirectAccess is a completely automatic VPN connection that simplifies accessing corporate LAN services from wherever they are located.

DirectAccess is part of the Remote Access server role. The info below details the key components that must be available for DirectAccess to work.
These are the components that are made highly available using the load balancer:

1. DirectAccess Server: This is the server(s) that clients establish a tunnel with in order to access the corporate network. Client and server settings are configured via Group Policy to enable the IPsec tunnels to be established.
2.  Network Location Server: The network location server is used to detect whether computers configured as DirectAccess clients are located in the corporate network. When clients are on the corporate network, DirectAccess is not used to reach internal resources. Instead, clients connect to these resources directly.
   If the client cannot reach the network location server, the client is considered to be outside the corporate network and a connection is established via the DirectAccess server.
3. Connectivity Verifier (Web Probe): This is part of the network Connectivity Assistant. It is used by clients to verify connectivity to the internal network.

DirectAccess clients communicate with the corporate network using Internet Protocol version 6 (IPv6) and IPsec. To enable this to work over the IPv4 based Internet, IPv4 transition technologies (6to4, Teredo, or IP-HTTPS) are used to encapsulate the IPv6 packets in IPv4 packets. 6to4 and Terado have various pre-requisites that can make deployment more complex.
IP-HTTPS is much simpler to deploy and is the only protocol that can be used when the DirectAccess server is deployed behind a NAT firewall, and this is the case we are going to base our Netscaler configuration on.
Network Location Server is used by the client to determine when it’s outside the corporate LAN and automatically activates the connection when it is. DirectAccess uses the Name Resolution Policy Table (NRPT) to identify which hosts should be accessed via the  DirectAccess tunnel (i.e. internal servers) and those which should be accessed directly (i.e. Internet based servers).

Windows 2012 and above supports the following transition protocols for client to DirectAccess server Communication:

1. 6to4: – Uses protocol 41 to encapsulate IPv6 packets in IPv4 packets – Does NOT work when the client or the server are behind a NAT device – Both client and server must be assigned public IPv4 addresses
2. Terado: – Uses UDP on port 3544 to encapsulate IPv6 packets in IPv4 packets – Supports client behind a NAT device but not server behind NAT – Server must be configured with 2 consecutive public IPv4 addresses
3. IP-HTTPS: IP-HTTPS is the transition protocol: – Uses standard port and protocol – Earlier clients / servers caused double encryption (IPsec & SSL/TLS) – Windows 8 and later use null encryption to solve the double encryption

Load Balancing Overview

To provide resilience and high availability for your DirectAccess infrastructure, multiple DirectAccess servers should be deployed with a load balancer, in this case, we are going to use a “Netscaler” to achieve that. This helps ensure that users can always connect to the corporate network by constantly checking the health of the DirectAccess servers and only forwarding connections to functional end servers.  The following diagram shows a typical load balanced DirectAccess deployment.

Network Location Server (NLS) is a critical component of DirectAccess and is used by clients to determine if they are inside or outside the corporate LAN. The NLS should only be resolvable/reachable internally, and NOT externally. It is possible to use the DirectAccess server as the location server but this is strongly discouraged by Microsoft. Instead, alternative servers should be selected. These servers require that IIS is installed with HTTPS bindings configured with a certificate that has the FQDN of the network location server. In this post, we are going to use: directaccess-nls.envokeit.com.

Load Balanced Ports & Services
For IP-HTTPS, the following ports / protocols must be load balanced:
Port: 443
Protocol: TCP/IP-HTTPS

Server Health Checking
To constantly check and verify the health of the DirectAccess servers, the load balancer is configured to perform an HTTPS negotiate check. This check verifies that each server responds with 200 OK. The heath check for the Network Location Servers and Connectivity Verifier (web probe) servers uses a TCP port connect to verify server Health.

Load Balanced DNS Requirements
Internal: The following resources must be resolvable internally:
1) The load balanced network location servers
2) The load balanced web probe server

External: The following resources must be resolvable externally:
1) The load balanced DirectAccess servers
2) The load balanced connectivity web probe server

Note: The Network Location Server should NOT be resolvable/reachable from outside the corporate network.

SSL Offloading is not a loadbalancing option for us, due when IP-HTTPS is used double encryption occurs (IPsec & SSL/TLS). This is mitigated with Win8/Win2012 by using a NULL cipher which solves the performance issue. Windows 7 clients are unable to use the NULL cipher so the double encryption performance issue remains. It’s not possible to enable SSL offload on the load balancer in this case because the load balancer would need to emulate Windows 8, 8.1 and 10 DirectAccess client behaviour which is not currently possible. So SSL-Bridge is our only option.

The picture below illustrates the task we have in front of us. As you may see, we have three Direct access servers and a Netscaler loadbalancer VIP in front.

DA_Server1 (Direct Access Server 1) with IP 192.168.16.110
DA_Server2 (Direct Access Server 1) with IP 192.168.16.111
DA_Server3 (Direct Access Server 1) with IP 192.168.16.112
VS_DA_IP-HTTPS_443 (loadbalancing vServer to NAT the external traffic to) with IP 192.168.16.100

Configuration on Netscaler:

enable ns mode L3 MBF
add server DA_Server1 192.168.16.110
add server DA_Server2 192.168.16.111
add server DA_Server3 192.168.16.112
add serviceGroup SVC_DA_IP-HTTPS_443 SSL_BRIDGE -maxClient 0 -maxReq 0 -cip DISABLED -usip NO -useproxyport YES -cltTimeout 180 -svrTimeout 360 -CKA NO -TCPB NO -CMP NO -appflowLog DISABLED
add lb vserver VS_DA_IP-HTTPS_443 SSL_BRIDGE 192.168.16.100 443 -persistenceType SSLSESSION -cltTimeout 180 -appflowLog DISABLED
bind lb vserver VS_DA_IP-HTTPS_443 SVC_DA_IP-HTTPS_443
add lb monitor DA_Monitor TCP -LRTM ENABLED -destPort 443
bind serviceGroup SVC_DA_IP-HTTPS_443 DA_Server1 443
bind serviceGroup SVC_DA_IP-HTTPS_443 DA_Server2 443
bind serviceGroup SVC_DA_IP-HTTPS_443 DA_Server3 443
bind serviceGroup SVC_DA_IP-HTTPS_443 -monitorName DA_Monitor

That’s it 🙂