Revisiting NLB Bidirectional Affinity on ISA Server 2004 Standard Edition

Revisiting NLB Bidirectional Affinity on ISA Server 2004 Standard Edition

by Thomas W Shinder, MD MVP
and friends

Got Questions? Go to:
http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=26;t=000258 and ask!

Many of you have read the article I did on how to enable NLB bidirectional affinity in ISA Server 2004 Standard Edition at http://isaserver.org/articles/2004bidirnlb.html. In that article I tried to make it clear that NLB BDA is not officially supported on ISA Server 2004 Standard Edition. However, it is fully supported in ISA Server 2004 Enterprise Edition and I highly recommend that if you require full NLB functionality for your ISA firewall deployments, then you should use the Enterprise Edition of the product.

Get the New Book!

Given that NLB is a popular feature, I think its important to provide you more information on this subject so that you can make a more informed decision on whether you should attempt using the limited NLB support included with ISA Server 2004 Standard Edition, or if your deployment requires the robust support for NLB bidirectional affinity that only ISA Server 2004 Enterprise Edition can provide. The following information was provided to me from a very reliable source and you should pay close attention to the details.

First off, the ISA firewall is a stateful firewall. In most cases, when the ISA firewall forwards a request from client C to Server S, the response from Server S must go through the same ISA firewall NLB array member from which the request was received, or else it would be denied.

When using NLB, NLB decides which ISA firewall NLB array member handles the traffic, a decision that is made on a per packet basis (remember that packets are layer 3 entities, and the layer 3 header contains the source IP address).

We need to make sure NLB makes the same decision for incoming packets from both the server and client, so same ISA firewall NLB array member handles this connection on both directions. This is where BDA comes into play.

Normally, NLB uses packet source address to make the load balancing decision. To enforce the same decision on the opposite (response) direction, NLB should use the packet destination address. This is called “Reverse hash”.

The most obvious example is seen with Server Publishing Rules where the original client IP address is preserved:

External client C connects to the ISA firewall array member on the virtual IP address (VIP) used in the listener for the Server Publishing Rule. The ISA firewall NLB array member then forwards the connection to the internal server S.

  • Incoming traffic (to the firewall) on the client side will have src=C, dst=VIPe.
  • Incoming traffic (to the firewall) on the server side will have src=S, dst=C.

To have the same decision taken by NLB, it should use the same input for its decision algorithm:

  • Src address (C) for incoming traffic from the client ( Reverse hash = false )
  • Dst address (C) for incoming traffic from the server ( Reverse hash = true )

Few things to note:

  • We must have complementary relation between the networks
    Meaning:
    For traffic between networks A and B, if A has RevHash=False, then B should have RevHash=True
  • Choice of RevHash should be such that we have a common source of decision in both “sides”
    Meaning: In the Server Publishing example,
    if we use the opposite RevHash value on both sides, BDA would not have functioned as expected: On the client side, NLB would use VIPe as decision source (and one member would always pick this traffic – a different problem on its own), yet on the server side, NLB would use S as decision source (again – only one array member would pick this traffic, though there is no guarantee it would be same array member used on the client side).

The configuration specified in the previous the article on NLB BDA support on ISA Server 2004 SE is compatible with this Server Publishing Rule scenario. However, there are other scenarios where different BDA parameters should be chosen.

BDA limitations

  • BDA is limited in a sense that it may be only defined to whole networks (NICs actually, since NICs are the “root” of ISA firewall Networks). This may impose a real handicap in the multi-network environment ISA 2004 firewall allows:
    If you have networks A, B and C, there is no way to define RevHash on each, such that all three pairs (A,B; B,C; A,C) have complementary relations.
  • BDA will not help in VPN scenarios. Since NLB evaluates packets at the network level (layer 3), it sees tunnel endpoints on one side vs. encapsulated traffic on the other, this results in no common ground to base a decision.
    Site to site VPN connections represent the most problematic
    VPN scenario. On the other hand, there may be some VPN scenarios where BDA is not needed (simple remote access).
  • Will work only with Single/Class C affinity
  • Will work only with single port rule.
  • Only supported on Windows Server 2003 (even through ISA 2004 is also supported on Windows 2000).

Additional recommendations:

  • The Master cluster is recommended to be on the most protected network.

Get the New Book!

Configuring BDA

Instead of directly manipulating the registry, it is much better to use WMI scripts. This way you can also use the VIP as a pointer to the configured cluster (and avoid searching GUIDs, etc.) The WMI scripts should be run after the NIC has NLB enabled, and other parameters (VIP, DIP etc.) already set.

Here is a BDA configuration sample WMI script – for a cluster with a  VIP = 55.55.55.55

‘*************************************************

vip = “55.55.55.55”

Set ClusterSet = GetObject(“winmgmts:{impersonationLevel=impersonate,(LoadDriver)}//./root/MicrosoftNLB”).InstancesOf (“MicrosoftNLB_ClusterSetting”)

for each Cluster in ClusterSet

   if Cluster.ClusterIPAddress = vip then

      Cluster.RemoteControlEnabled=False ‘Always recommended

      Cluster.BDATeamActive = True

      Cluster.BDATeamId = “{12345678-9012-3456-7890-1234546890ab}” ‘ any GUID – should be shared by all clusters

      Cluster.BDATeamMaster = True ‘ only one cluster may be Master

      Cluster.BDAReverseHash = True

      Cluster.put_ Save settings (to registry)

      Cluster.LoadAllSettings equivalent to wlbs reload (for this cluster)

   end if

next

‘*************************************************

I hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything I discussed in this article, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=26;t=000258 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom

If you would like us to email you when Tom Shinder releases another article on ISAserver.org, subscribe to our ‘Real-Time Article Update’ by clicking here. Please note that we do NOT sell or rent the email addresses belonging to our subscribers; we respect your privacy

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top