Recently I was asked to help troubleshoot a problem with ISA 2006 and Network Load Balancing (NLB).  My customer had attempted to add some additional Virtual IP Addresses (VIPs) to the NLB configuration.  Following the ISA guidelines we used the ISA Management Console to configure the NLB properties instead of making the changes directly to the Network Interface configuration.  Everything seemed to go smoothly while adding the additional addresses.  Unfortunately a problem surfaced while the NLB service attempted to converge the adapter into the NLB configuration pool.  A quick scan of the Windows Eventlog presented two relevant entries.

The first entry gave the following information:

Event Type:     Warning 
Event Source:   Microsoft Firewall 
Event Category: None 
Event ID:       21115 
Date:           10/14/2008 
Time:           9:49:56 PM 
User:           N/A 
Computer:       MyServer 
Description: 
Network adapter 'Internal Interface' is configured with several IP addresses that belong to several networks. This is an invalid configuration, and this network adapter cannot be used for Network Load Balancing.

The second entry gave pretty much the same information:

Event Type:     Error 
Event Source:   Microsoft Firewall 
Event Category: None 
Event ID:       21113 
Date:           10/14/2008 
Time:           9:49:56 PM 
User:           N/A 
Computer:       MyServer 
Description: 
There is no suitable network adapter related to network 'Internal'. Network Load Balancing cannot be configured properly, and will be stopped on this server. A suitable network adapter must have a static IP address that belongs to the network and is different than the cluster Virtual IP address.

First I started with the ISA network configuration.  Our servers are configured with a single NIC as we are only using ISA as a proxy server.  With a single NIC the ISA network configuration only allows for two separate networks:

1. localhost (127.x.x.x)
2. Internal (everything else)

In fact if you look at the network configuration it should look exactly like this:

That all checked out so I felt sure the ISA network configuration wasn’t the problem.

Next I checked if the additional VIP’s being added to the NLB configuration were of the same network.  It’s pretty easy to forget your subnet rules and accidentally add an address from a different subnet.  So a quick look at the IPCONFIG values on the ISA server produced the following output:

IP Address. . . . . . . . . . . . : 192.168.1.175 
Subnet Mask . . . . . . . . . . . : 255.255.255.128 
IP Address. . . . . . . . . . . . : 192.168.1.174 
Subnet Mask . . . . . . . . . . . : 255.255.255.128 
IP Address. . . . . . . . . . . . : 192.168.1.172 
Subnet Mask . . . . . . . . . . . : 255.255.255.128 
IP Address. . . . . . . . . . . . : 192.168.1.170 
Subnet Mask . . . . . . . . . . . : 255.255.255.128 
IP Address. . . . . . . . . . . . : 192.168.1.168 
Subnet Mask . . . . . . . . . . . : 255.255.255.128 
IP Address. . . . . . . . . . . . : 0.0.0.0 
Subnet Mask . . . . . . . . . . . : 0.0.0.0 
IP Address. . . . . . . . . . . . : 192.168.1.165 
Subnet Mask . . . . . . . . . . . : 255.255.255.128 

A quick look at the subnet mask (255.255.255.128) indicated two subnets. Our addresses were all in the second subnet so no dice.  However, I immediately noticed the 0.0.0.0 address towards the end of the address space.  That was very odd.  We were not using DHCP on any of the addresses so there shouldn’t be an open address entry.  Seems this is the most likely issue. 

Come to think of it, turns out there are actually three networks, not two, on a single homed ISA server:

1. Undefined (0.0.0.0)
2. Localhost (127.x.x.x)
3. Internal (everything else)

The 0.0.0.0 address is considered a separate network, makes sense.  You can see in the above image that we start the internal address space at 0.0.0.1 which leaves 0.0.0.0 to be considered a separate network.  So now we know the ‘how’ of the error messages in the Windows Eventlog, but we still haven’t figured out the ‘why’.

I did a little more digging in the Windows Eventlog and discovered what I suspected was causing the problem.  An entry showed up indicating an IPAddress conflict.  For some reason the subnet we were using had a rouge address assignment that hadn’t been recorded or identified.  As soon as the NLB attempted to converge on that specific address the collision occurred and the address couldn’t be used.

So the problem appears to be that we have a duplicate IPAddress conflict that is preventing the NLB service from converging.  Easy fix!