Friday, 22 August 2014

Direct Access: High Availability

Back to Direct Access main menu

DirectAccess has become a vital resource in many enterprise environments. We implement High Availability for technologies like SQL and Exchange so why should DirectAccess be any different? The good news is that it's easy to do so.

We've previously deployed a single server DirectAccess solution (lets call this server RAS1). Then we moved the NLS to a remote web server. Now we will implement HA for the solution. The following are the basic steps.

  1. Add NLB feature to RAS1
  2. Build new Windows 2012R2 Server RAS2
  3. Add Remote Access role and NLB feature to RAS2 
  4. Export IPHTTPS listener certificate from RAS1 and import to RAS2
  5. Enable MAC spoofing on virtual NICs
  6. Enable Load Balancing
  7. Add second server to Load Balanced cluster

1. Add NLB feature to RAS1

3. Add Remote Access role and NLB feature to RAS2 

4. Export IPHTTPS listener certificate from RAS1 and import to RAS2 

Export certificate from RAS1

 Import to RAS1

5. Virtual NICs

Enable MAC spoofing

Enable MAC spoofing on the virtual NICs of RAS1 and RAS2 

Second NIC

You can implement this solution with a single NIC per server. However it is better practice to use two. The second NIC, for NLB communication, should be configured in separate subnet with no default gateway.

6. Enable Load Balancing

Launch the Remote Access Management console on RAS1.. Open the configuration.

On the bottom right of the window select "Enable Load Balancing".

The "Enable Load Balancing" wizard is launched. Click Next.

Choose NLB as the cluster method (note that you can configure the solution to use an external load balancer).

Enter an available IP address. The wizard is quite smart here. It knows that DirectAccess is already working with a single server solution (RAS1). DNS records and firewall rules have been created and we don't want to have to amend these. Therefore the wizard swaps the IP addresses.

The working dedicated IP address of RAS1 (DIP) becomes the Virtual IP address of the NLB cluster (VIP).
The new available IP address becomes the IP address of RAS1. Pretty clever.....

Verify the settings and "Commit".

Review progress.

Click Close to return to the wizard.

Verify success and close the wizard.

See what has happened. A load balanced cluster has been created with a single node (RAS1).

Note that the IP address of RAS1 has changed.

7. Add second server to cluster

Now, on the bottom right of the Remote Access Management configuration window, choose "Add or Remove Servers".

Select "Add Server".

Browse to choose RAS2.

Ensure that the correct NIC is selected.

Verify the settings and click Add.

Close the wizard.

"Commit" the changes.

Verify progress.

Close the "Adding or Removing Servers" wizard.

See that the second node has been added to the load balanced cluster.

Verify that the nodes are operating correctly.

Issues Encountered
I encountered a couple of issues during this configuration.
Firstly the wizard did not seem to add both nodes to the NLB cluster. When I opened the Network Load BaIancing Manager I noticed that only one node was present. I had to add the second node manually.

Also, my DirectAccess solution broke after I introduced NLB. I found that this was due to the fact that my customer had a series of firewalls with some kind of one-to-one NATing throughout. This played havoc with the NLB traffic. This was solved by introducing Dynamic NAT rules.


1 comment:

  1. Hi.
    I've encountered similar problem with NLB. Could You describe how exactly You have managed to overcome NLB havoc?