Load Balancing and Forefront TMG Firewall Clients
Recently I encountered an issue where TMG firewall clients were experiencing intermittent connectivity issues. Clients were sometimes able to connect to a remote RDP server, and other times they were not. Web proxy clients were working perfectly. After looking carefully at the network and TMG firewall configuration, everything appeared to be in order with no apparent issues. In this particular instance, two TMG firewalls were configured in a multi-homed, standalone array with Network Load Balancing (NLB) enabled on both the Internal and External networks. Clients connect to the array using a hostname that resolves to the virtual IP address (VIP) assigned to the Internal network.
Although this configuration works just fine for web proxy clients, it poses a particular problem for the TMG Firewall Client because the Firewall Client uses a control channel to facilitate authentication and communication with the TMG firewall. For proper operation, Firewall Clients must be configured to communicate directly with the TMG firewall’s dedicated IP address (DIP). For this reason, the use of NLB and third-party hardware load balancers is not supported for load balancing TMG Firewall Clients. The only form of load balancing that is supported for TMG Firewall Clients is DNS round-robin.
To learn more about the TMG Firewall Client and how it functions, please refer to Jim Harrison’s excellent series of articles about this topic on TechNet.
Introduction to the ISA Server Firewall Client and Forefront TMG Client
Introduction to Remote Winsock (RWS) Protocol Analysis
Observing Firewall Client Single-connection HTTP Traffic
Observing Firewall Client Single-connection DNS Traffic
We are using the same config with ISA 2006 Enterprise configuration but we didn’t encounter any problem till now. We are having also installed on all workstation Microsoft Firewall Client for ISA Server, Version 4.0. We are planning to migrate to TMG Server on NLB at application level (on TMG, using virtual IP).
The problem will persist also in this case ?
Regards,
anghelalex
Absolutely. Nothing changes in this regard with TMG. Firewall clients, if they are connecting to ISA or TMG, must communicate with the dedicated IP address of the array members in order to function correctly.
If the firewall clients will communicate with the dedicated ip of the array member, will they not lose the HA then, since they won’t be using the NLB virtual IP?
That’s correct. The only supported method of load balancing for ISA/TMG Firewall clients is DNS round robin.
Is that by design or will that be solved in a future servicepack or hotfix update?
Yes, it is a design limitation that can’t be addressed with a hotfix or service pack. It would likely involve a significant redesign of the Firewall Client control channel mechanism, and potentially the firewall core itself.
What are the symptom(s) that you see when you attempt to hit a load balanced CSS or EMS array (via Microsoft NLB) with the Firewall Client hitting the VIP?
Most often it is simply erratic client behavior and intermittent connectivity issues. It can work without issues if everything goes perfectly, but since the Firewall Client control channel is established with a single array member, if the connection moves to another array member for any reason the connection will break.
Does this also apply to an ISA Server 2004 Enterprise Edition array? The reason I ask is because we have a 4-node ISA Server 2004 Enterprise array deployed and we are NOT using DNS round robin for any of our internal clients.
Which begs the question, what has changed in behavior from ISA 2004 moving forward to later version of ISA 2006 and TMG 2010?
It certainly does. Again, the issue is that the Firewall Client establishes a control channel to a specific array member. If the data channel subsequently initiates to another member for any reason, the connection will break. If your environment is reasonably stable, it is possible that you won’t encounter issues. It is still an unsupported configuration, however.
I’m starting to notice a lot of problems when end-users are hitting websites that use AJAX heavily such as Yahoo Mail. Sometimes it will work and other times it will not work. In other words, it is intermittent, which is the worst kind of errors to troubleshoot.
During a live monitoring event via ISA Server I saw that the user was bouncing between proxy array members. Would it make a difference if the user was a web proxy client as opposed to a firewall client? In other words, we know that bouncing between array members will break a firewall client’s communication but how about a web proxy client?
Shouldn’t be a problem for Web Proxy clients since they don’t make use of a discrete control channel like the Firewall Client does.