Udostępnij za pośrednictwem

Using an F5 Load Balancer as an NLS server for DirectAccess

  • Artykuł

I was working on a deployment of DirectAccess for a company and of course how to deploy NLS came up.  Obviously it is important that the NLS servers always be available, so the plan was to create two virtual IIS servers and put them behind their internal F5 load balancers.  This would allow them to take down one of the NLS servers for patching while the other stayed up, and provided the high-availability that they needed.

However, this got me thinking about what a waste it was to have to provision and operate these two servers that basically did nothing but respond to HTTPS requests once in a while for DA.  We considered using other servers that were already in place but we were concerned that overloading them with NLS functionality was risky, especially if the web team needed to do major upgrades on the apps on those servers and took a full outage.

Then it struck me that the ultimate solution would be to have the F5 load balancers themselves provide the NLS service.  This had many advantages:

  • The F5s were already in a high-availability pair
  • As networking gear, there were monitored very closely
  • There was almost no situation where both load balancers would need to be taken down at the same time
  • They have the ability to terminate SSL sessions

Having worked for a while on the Xbox Live team, I called one of my buddies on the networking team and explained the situation and what I was trying to do.  He suggested that it would be easy with an irule.  An irule is a bit of customization that you can apply to a VIP on an F5.  I'm sure that irules can do many different things, but one of the things they can do is respond to HTTP or HTTPS requests.  I believe this is primarily used to allow the F5s to redirect users to a maintenance page with the servers behind them are down for maintenance.  Whatever irules were intended to do, I was pretty sure that they would be able to do what I needed them to, so it was just a matter of getting the configuration right and testing it.

I grabbed an evaluation copy of the F5 virtual load balancer and went to work.  At the time, the hardest part was getting the certificate deployed onto the load balancer, but after a little wrangling I got it to work.  (BTW, I believe that this has gotten a lot easier in new version of the software.)  After that, I set up the VIP, configured it to use the certificate and terminate SSL on the load balancers, whipped up an irule that responded with a tiny bit of HTML and a 200 response code and applied the irule to the VIP.

To test things, I first hit the VIP with a request from IE and viola! it responded just as expected.  Hooray!  So then, feeling cocky, I updated my HOSTS file to use the new VIP as my NLS server on my DA client and of course it didn't work.  I was very puzzled since IE thought it was great but DA didn't.  After a little back and forth with one of the DA gurus at Microsoft, we got to the bottom of the problem: the content type tag in my HTTP response was not exactly correct.  I had not put in a hyphen between Content and Type.  Apparently, the DA client used a much less forgiving HTTP library than IE, so while IE would ignore this problem and assume the proper content type, the DA client was choking on what it saw as a malformed HTTP response.  Anyway, we fixed the irule by changing a space to a hyphen and it all started working.

For those of you wondering, here is the irule in all its glory:

when HTTP_REQUEST {

 log local0. "Request for NLS service"
 HTTP::respond 200 content "<html><head><title>Network Locator Service</title></head><body><h2>You are connected to the intranet.</h2></body></html>" "Content-Type" "text/html"
}

Anyway, this arrangement met the needs of the client, saved them two Windows license (sorry, Microsoft!) and left them with two less servers to worry about.  In the end I'd say it was a win!