Using Windows 2000 NLB with ISA Server Publishing Rules

Using Windows 2000 NLB with ISA Server Publishing Rules

By Thomas W Shinder M.D.

The Windows 2000 Network Load Balancing service allows you to provide fault tolerance and load balancing for NLB array members. You can use NLB with ISA Server and bind it to either the internal or external interface, but not both. You can provide a high level of availability by binding NLB to the external interfaces of an array of ISA Servers. The ISA Server NLB array can be used to publish services on the internal network using Server Publishing Rules.

If you read my “basics of NLB” series, you should have a good idea of how the Windows 2000 NLB services works. The figure below shows how NLB improves accessibility for published sites. Incoming connections are load balanced among the NLB array members so that no ISA Server is overloaded by incoming connections. If one of the ISA Servers becomes unavailable, the array goes through convergence and reassigns incoming connections to other array members. As long as at least one array member is online, incoming requests to your published servers will be served.

In the rest of this article we’ll go over the following subjects:

Server Publishing Rules perform a reverse NAT that allows the external network client to access resources on the internal network. This type of port mapping is very common with NAT servers of all kinds. When an incoming packet destined for a particular IP address and port reaches the external interface of the NAT server, the NAT server changes the header information in the packet, places information about the packet in its state table, and forwards the packet to the internal network server.

The destination IP address always has to be changed in order for the packet to reach the published server on the internal network. The source IP address can be either the original source IP address (sometimes called “half NAT”) or the IP address of the internal interface of the NAT server (full NAT). Both of these implementations allow the incoming packet to be forwarded to the internal network server and also allow the internal network server to respond to the Internet host that made the request.

The figure below shows the difference between Half NAT and Full NAT. The ISA Server on the left uses the default Server Publishing configuration and preserves the source IP address of the client making the incoming request. The published server “sees” the IP address of the external client and is able to respond to the external network client’s request by forwarding the response to its default gateway. The ISA Server on the right is configured to perform Full NAT, and the client’s IP address has been replaced with the IP address of the internal interface of the ISA Server. The published server is able respond to the client by sending its response to the IP address of the internal interface of the ISA Server.

Server Publishing Rules use Half NAT by default. This typically doesn’t pose any problems. You just configure the published server as a SecureNAT client. Note that the default gateway doesn’t have to be the internal interface of the ISA Server, the Internet bound packets just need to be routed to the ISA Server’s internal interface. If the SecureNAT client isn’t on the same network ID as the internal interface of the ISA Server, then the routing infrastructure must be configured to support the SecureNAT client.

The reason why the SecureNAT client is dependent on the default gateway configuration is that your network doesn’t have specific routes for all possible Internet network IDs. The SecureNAT client needs to know how to route packets to Internet addresses because the source IP address in the incoming packet is a public address and that’s the address the SecureNAT client needs to respond to.

While half NAT usually doesn’t create any problems, it can cause you a lot of heartache if you try to publish servers behind an ISA Server NLB array (where NLB is configured on the ISA Servers external interfaces). What do you think happens when you have two ISA Servers in an array and the inbound connection is accepted by the ISA Server that was not configured as the published server’s default gateway? The sequence of events appears in the figure below.

1. The external client sends a request to the virtual IP address used to publish the internal network server.
   
2. All frames are sent to all members of the array. The NLB algorithm determines which server should handle the request. The packets are dropped by the other NLB array members.
   
3. The NLB array member accepting the packets forwards the packets to the published server.
   
4. The published server returns the response to its default gateway. The problem is this ISA Server isn’t aware of the fact that this is a legitimate response to a legitimate inbound request. As far as this ISA Sever is concerned, the published server is sending a SYN-ACK for a connection that it has no record of. Since this ISA Server’s state table doesn’t have any record of the original SYN (no pun intended), the packet is dropped and the connection fails.

To get a better idea of what’s going on, check out the following screen shots. In the first shot, you see the external client with an IP address of 192.168.1.3 attempting to connect to the VIP of the ISA Server NLB array at 172.16.0.1, using a source port of TCP 1041 and a destination port of 25 (SMTP).

The figure below shows the trace taken on the external interface of the ISA Server that handled in incoming SMTP request.

The figure below shows a netstat –na on the ISA Server array member that handled the request for the incoming SMTP connection. Note the TIME_WAIT status indicates the client sent a FIN before disconnecting. By default, Windows 2000 keeps the socket pair open for 240 seconds after an active closing of the sessions (via the FIN).

The figure below shows a trace taken on the internal interface on the ISA Server array member that did not accept the incoming request. This ISA Server is configured as the published server’s default gateway. The published server tries to respond to the external client by sending its responses to its default gateway. The problem is that this ISA Server isn’t expecting these replies. A dynamic packet filter wasn’t created to allow the published server to send what you might call an “unsolicited outbound response”. The published server is responding to the appropriate address and port number, but it receives no responses because the ISA Server is blocking the response.

The figure below shows a netstat –na demonstrating that no connection was established on the external interface of the ISA Server that the published server was sending its responses to. Again, because this ISA Server never saw the incoming request and because the NLB array members do not share information about connection state, this ISA Server drops the responses from the published server.

It should be clear that the combination of half NAT and NLB on the external interface can cause problems. The published server is a SecureNAT client and it can only have a single default gateway. If the SecureNAT client is configured with a default gateway address that is different from the server that accepted the incoming request, that packet will be dropped. There no way you can fix this problem from the SecureNAT client end, but there is something you can do on the ISA Server to fix this problem.

The solution to the half NAT problem is to configure the ISA Servers to perform full NAT for Server Publishing Rules. When the ISA Servers perform a full NAT, the source IP address on the forwarded packet will change to the IP address on the internal interface of the ISA Server that accepted the packet. The published server has no problems sending its response because it only needs to be able to send the request directly to the internal IP address of the ISA Server; it doesn’t depend on its default gateway configuration or the gateway of last resort used by any of the routers on the network.

1. The external client sends a request to the virtual IP address used to publish the internal network server.
   
2. All frames are sent to all members of the array. The NLB algorithm determines which server should handle the request. The packets are dropped by the other NLB array members.
   
3. The NLB array member accepting the packets forwards the packets to the published server.
   
4. The published server has a default gateway address of 10.0.0.2. However, the default gateway address doesn’t matter in this case, because the source IP address of the packet sent to the server is 10.0.0.1 because the ISA Server performed a full NAT on the packet. The published server sends its response to 10.0.0.1 and the ISA Server forwards the response to the external client.
   
   
   

    

Full NAT solves the problem of asymmetric routing of inbound requests. You can configure the ISA Server to perform full NAT by performing the following steps:

1. Go to the Services node in the ISA Management console and stop the Firewall service.
   
2. Click Start an the click the Run command.
   
3. In the Open text box, type regedit
   
4. Navigate to:
   

5. Add the following REG_DWORD Value:
    

6. After you add the value, restart the Firewall service. I prefer to restart the entire ISA Server machine.

Although Full NAT solves the asymmetric routing problem, it introduces a problem seen with Web Publishing Rules. Since the source IP address in the forwarded packet is changed to the address of the internal interface of the ISA Server, the log files on the published servers no longer contain useful information regarding the requesting clients.

Recall that you can configure NLB to use either unicast or multicast mode. We need the single external interface to be able to support both a unique dedicated address and one or more NLB addresses. We would also like that single interface to be able to communicate with the other NLB interfaces in the array. We’ll have to use multicast mode to meet these requirements. If you have a Cisco router upstream from the array, you should enter the appropriate static ARP table entries in the router; what we don’t want to have to do is install a second external interface to support the dedicated IP address.

In this example we’ll assign each of the two ISA/VPN Server array members a single dedicated IP address and a single NLB address. The dedicated IP address is different on each server and the array address is the same on each machine. Perform the following steps on the first member of the array:

1. Right click My Network Places and click the Properties command. In the Network and Dial-up Connections window, right click on the external interface and click the Properties command.
   
2. In the Internet Protocol (TCP/IP) Properties dialog box, click the Advanced button.
   
3. The machine already has a unique IP address assigned to it. Now you need to enter the NLB address. Click the Add button in the IP addresses frame. In the TCP/IP Address dialog box, type in the NLB address and subnet mask. Remember that this must be a valid IP address on the network directly attached to the external interface of the ISA Server. Click Add, then click OK. Click OK one more time to complete the IP addressing configuration on the first member of the NLB array.

4. If you don’t see any error messages, then you’re ready for the next step. On the first member of the array, right click on the external interface and click Properties. Put a checkmark in the Network Load Balancing checkbox and click the Properties button.

5. The Cluster Parameters tab is the first one you see. In the Primary IP address text box, type in the IP address you want the entire cluster to use. Note that this is the cluster primary IP address, not the ISA/VPN Server’s primary IP address. Recall the differences between the two, as I went over in the NLB review articles. Type in the appropriate subnet mask in the Subnet mask text box. The Full Internet name must resolve to the DNS entry you have for the Primary IP address you entered in this dialog box. Put a checkmark in the enabled checkbox so that Multicast support is enabled. If you want to remotely manage the cluster, put in a password and confirm the passwords, then put a checkmark in the Remote control checkbox.

6. Click on the Host Parameters tab. On the first array member, put a 1 in the Priority (Unique host ID) text box. Each array member must have a different host ID. Put a checkmark in the active checkbox so that the NLB service will start automatically with the server. In the Dedicated IP address text box, type in the dedicated IP address; this is also the ISA/VPN Server’s primary IP address (which is the IP address on the top of the list of IP addresses in the Advanced TCP/IP Properties dialog box). Enter the appropriate subnet mask.

7. Click on the Port Rules tab. Microsoft recommends that you use the default Port Rule that has already been created for you. This allows all incoming TCP and UDP connections to be load balanced using single affinity. Single affinity “pins” an external client IP address to a specific ISA/VPN server for the duration of the connection. There are a number of reasons for this; make sure to review the NLB over articles if you’re not clear on the different affinity modes and what they mean. Set the Load Weight to equal unless there is a big difference in terms of the hardware configurations among the servers. Keep in mind that the NLB algorithm does not take into account CPU or memory utilization, so if you anticipating major differences in these factors between the servers, you should manually assign a Load Weight.

8. Click OK and then click OK again. Open the Event Viewer. In the System Log you’ll see two entries for WLBS. These entries confirm that the first member of your ISA/VPN Server array has converged with itself. When we’re done, the second member of the array will converge with the first.

Now perform the following steps on the second member of the ISA/VPN Server Array:

1. Right click on My Network Places and click Properties. Right click on your external interface and click Properties. This time we’re going to configure the NLB properties before we add the virtual IP address to the list of addresses. The reason for this is that the server won’t like the duplicate IP address if it doesn’t know in advance that it’s an NLB address. Put a checkmark in the Network Load Balancing checkbox and click the Properties button.
   
2. On the Cluster Parameters tab, enter the exact information that you entered on the Cluster Parameters tab. On the first ISA/VPN array member. Remember that the array will go into convergence if the settings for the cluster are not the same for all members.

3. Click on the Host Parameters tab. Assign a new Priority value to this host. Since this is the secondary member of the array, I’ll assign it a value of 2. Put a checkmark in the Initial cluster state checkbox and enter the primary IP address bound to the external interface of the ISA/VPN server in the Dedicated IP address text box. Enter the appropriate subnet mask in the Subnet mask text box. You don’t need to add any new Port Rules so you can click OK.

4. Click on the Internet Protocol (TCP/IP) entry and click the Properties button. In the Internet Protocol (TCP/IP) Properties dialog box, click the Advanced button.
   
5. On the IP Settings tab, click the Add button. We need to add the virtual IP address. Enter the virtual IP address in the TCP/IP Address dialog box and enter the subnet mask. Click Add. The list of IP addresses should show the ISA/VPN server’s primary IP address on the top of the list, and the virtual IP address under the ISA/VPN server’s primary IP address. Click OK. Click OK again, and click OK one more time.
   
6. You don’t need to make any changes to the Port Rules, so you can click OK. Click OK one more time. Open the Event Viewer and check the status of the array. If everything is working correctly, you should see that members 1 and 2 of the array have converged.

You can confirm that you’re in multicast mode by pinging the dedicated IP address of the other array member. Remember that in unicast mode, you would have to add a second NIC to support the dedicated IP address.

Now install ISA Server and create your Server Publishing Rules. There are no special configuration requirements specific to the NLB Server Publishing configuration; just create the Server Publishing Rules using the Server Publishing Wizard. The only difference is that you’ll use one of the VIPs on the external interface of the ISA Server instead of a dedicated IP address. Remember to make the Registry change to enable full NAT after you have installed the ISA Server.

In this article we looked at some of the issues involved with using NLB for inbound connections used for Server Publishing Rules. You saw how ISA Server handles NAT’ing incoming connections and how you can control how this process is carried out. We went over configuration details of the NLB interfaces. Using the methods described in this article, you should have no problems publishing simple protocols that do not require secondary connections.

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=6;t=001566 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom