Introduction
The Firewall Client has been around for many years, dating back to the days of Microsoft Proxy Server when it was referred to as the Winsock Proxy Client. It is a software component that provides the ability to proxy any application that uses Winsock, regardless if the application itself is proxy aware. In my discussions with ISA and TMG firewall administrators, I am consistently amazed at how few understand the power, flexibility and control that is provided by this wonderful utility.
What is the TMG Firewall Client?
The TMG Firewall Client is an application that can be installed on most Windows desktop and server operating systems (it is limited only to Windows – there is no support for non-Microsoft operating systems such as Mac or Linux). The TMG Firewall Client is backwards compatible with ISA Server 2006 and 2004, and the older ISA Firewall Clients (2006 and 2004) still interoperate with Forefront Threat Management Gateway (TMG) 2010. A complete compatibility matrix is documented here.
The TMG Firewall Client is a Layered Service Provider (LSP). When installed, the TMG Firewall Client hooks in to the Winsock API and listens for requests that are destined for any remote network. When a request is made for a remote resource, the communication is intercepted and forwarded to the TMG firewall to be proxied to the remote destination. If the request is for a resource on the client’s local network, the TMG Firewall Client simply ignores the request and communication proceeds normally. For a comprehensive look at TMG Firewall Client operation, see Introduction to the TMG Firewall Client document on TechNet.
Preparing TMG to Support TMG Firewall Clients
When the TMG Firewall Client is installed, by default it will automatically configure Internet Explorer proxy settings on the client. The TMG Firewall Client will not configure third-party browsers unless they rely on IE’s web proxy settings.
Before installing the TMG Firewall Client, it is recommended that you review and/or change these configuration settings. Open the TMG management console, highlight the Networking node in the navigation tree, then select the Networks tab. Right-click the Internal network and choose properties. Next, select the option to Enable Forefront TMG Client support for this network.
Figure 1
As you can see, the default settings are less than ideal because both automatic configuration and manual configuration are enabled by default. I recommend selecting one or the other, preferably automatic configuration if your environment supports it. Hostnames are defined as single label, but it is a good idea to use fully qualified domain names when possible. In a deployment scenario where Web Proxy Auto Discovery (WPAD) is configured, an ideal configuration should look like this:
Figure 2
If you plan to use WPAD for automatic client configuration, be sure to enable the option to Publish automatic discovery information for this network on the Auto Discovery tab of the Internal network properties dialog box.
Figure 3
If WPAD is not configured in your environment, you can specify that the client use the TMG firewall’s automatic configuration script using either the default URL or a custom one. Alternatively you can define a proxy server directly.
Installing the TMG Firewall Client
Installing the TMG Firewall Client is simple and straightforward. The client can be found in the \Client folder on the TMG installation media, or it can be downloaded here. Double-click the executable then select Next. Accept the license terms and the default installation folder, and then select the method with which to connect to the TMG firewall. Choose Connect to this Forefront TMG computer: if you want to manually connect to a specific TMG firewall, or choose Automatically detect the appropriate Forefront TMG computer to use WPAD. Since my test lab has WPAD enabled, I’ll select the option to automatically detect.
Figure 4
Once installed, the TMG Firewall Client icon will appear in the system tray and indicate its connectivity status.
Enabled and connected.
Figure 5
Enabled, connected, and authenticated.
Figure 6
Disabled.
Figure 7
Unable to connect.
Figure 8
TMG Firewall Client service (fwcagent.exe) is not running.
Figure 9
You can right-click the TMG Firewall Client icon in the system tray to access TMG Firewall Client configuration settings.
Benefits Provided by the TMG Firewall Client
The beauty of the TMG Firewall Client is that it is completely transparent to applications. You can proxy any application that uses Winsock for TCP and UDP communication (e.g. SSH, Telnet, RDP, ICA, STMP, etc.). The application is completely unaware that its communication is being handled by a proxy server.
Unlike SecureNAT clients, all TMG Firewall Client communication is authenticated. With the TMG Firewall Client installed you can now enforce strong user and group-based authentication on all TCP and UDP communication. Try doing that with your so-called ‘hardware’ firewall!
The TMG Firewall Client can also support complex protocols that require secondary connections, without requiring an application filter. In addition, the TMG Firewall Client can resolve some common connectivity issues. There are many web-based applications that have issues with authenticating proxies. Most common are streaming media and Java-based applications. Although they may use HTTP, some applications do not gracefully handle the HTTP 407 (authentication required) response from the proxy and fail to connect. By leveraging the capabilities of the TMG Firewall Client and its always authenticated communication, these problems can easily be resolved.
To accomplish this, simply install the TMG Firewall Client on the workstation. Next, open the TMG management console and include the destination the problem application is connecting to in the Directly access these servers or domains: list located on the Web Browser tab of the Internal network properties.
Figure 10
Note:
The above will only work if your clients are configured to use automatic configuration. If your clients are configured manually you will need to add the destinations to be bypassed by checking the Bypass proxy server for local addresses and adding the destination manually in the web browser configuration settings. If your clients are configured to use a static PAC file, the PAC file will need to be updated to bypass the proxy server for these destinations.
Once configured, the client will no longer attempt to send this communication directly to the web proxy server. Instead it will attempt to communicate directly, allowing the TMG Firewall Client to process the traffic.
Automated Deployment
The fact that the TMG Firewall Client is an application that must be installed on each workstation is a common barrier to wide-scale deployment in many organizations, especially larger ones. However, the TMG Firewall Client is an MSI package which lends itself quite well to being deployed using automated software deployment mechanisms, including Active Directory Group Policy, Systems Center Configuration Manager (SCCM), and more.
Command Line Configuration
When installed, the TMG Firewall Client can be managed via the command line, if necessary. FwcTool.exe is a command line utility found in the \Program Files (x86)\Forefront TMG Client folder for x64 machines (yes, you read that correctly!) and the \Program Files\Forefront TMG Client folder on x86 machines. This utility allows the administrator to enable and disable the client, gather information, set the detection method (manual or automatic), test connectivity, and more.
Another useful command-line utility included with the TMG Firewall Client is FwcCreds.exe. This tool allows you to specify alternate credentials on a per-application basis. By default, the TMG Firewall Client will use the credentials of the current logged-on user when authenticating to the TMG firewall. There are instances where this may not be desired, however. An example would be a service or other non-interactive process that communicates remotely and requires the assistance of the TMG Firewall Client. In this case you can use FwcCreds.exe to specify a username and password for the TMG Firewall Client to use when it processes traffic from that application.
Load Balancing TMG Firewall Clients
When configuring the TMG Firewall Client to communicate with a TMG Firewall, it must use the dedicated IP address of the firewall (or a hostname that resolves to the dedicated IP address). For Enterprise arrays, configuring the TMG Firewall Client to use the virtual IP address (or a hostname the resolves to the virtual IP address) is not supported. Using third-party load balancing solutions is also not supported. The only form of load balancing for TMG Firewall Clients is DNS round robin.
Additional Features
The TMG Firewall Client can be used to notify users when they visit an SSL-protected web site and HTTPS inspection is configured and enabled on the TMG firewall. The TMG firewall and the client workstation must be members of a domain for this feature to work.
Figure 11
The TMG Firewall Client also logs additional information for communication that it handles. This includes username information (regardless if the access rule requires authentication) and the application (executable name) that initiated the request.
Caveats
Ideally the TMG firewall and the clients where the TMG Firewall Client are installed should be members of a domain. Alternatively you can use mirrored accounts on the TMG firewall if your firewall or clients are not members of a domain. Also, clients must have a route to any remote destination they need to communicate with. This is counterintuitive; in theory the TMG Firewall Client should intercept any request for a remote resource and forward that to the proxy, making a route to the remote destination unnecessary. However, beginning with Windows Vista, the DNS client behaves differently, causing some unintended side effects. With Vista and later, the operating system will ignore hostnames that resolve to an IP address that it does not have a route to, effectively behaving as if it is unable to resolve the name at all. In the past it was possible to configure clients a default gateway and leverage the Firewall Client to control all remote communication. With these changes, configuring the TMG Firewall Client machine without a default gateway is no longer feasible.
Conclusion
In this article I provided a high-level description of the TMG Firewall Client and reviewed its installation and configuration. I highlighted some of the benefits it provides, such as providing proxy services for non-proxy aware applications, authenticating all TCP and UDP communication, and logging usernames and application detail. I also outlined some of the command-line troubleshooting tools and discussed additional features such as HTTPS inspection notification. When deployed, the TMG Firewall Client can resolve issues that some applications have when communicating through authenticating proxies. If you have not yet deployed the TMG Firewall Client in your organization, I would strongly encourage you to leverage this powerful tool today.
