Troubleshooting TMG SecureNAT Clients (Part 1)

If you would like to read the next part in this article series please go to Troubleshooting TMG SecureNAT Clients (Part 2).

Introduction

Clients on the internal network can interact with the TMG firewall in different ways that depend on the features you require. You probably already know that the types of TMG clients include the following:

• The SecureNAT client
• The Firewall client (also referred to as the TMG client)
• The Web Proxy Client

Each of these TMG firewall client types interact with the firewall services in a different way and each of them provides its own unique advantages and disadvantages. There are also problems specific to each TMG firewall client. Thus there is no “one size fits all” solution.

In this first part of a two-part article, we’ll take a look at the function of the SecureNAT client and explore different ways to troubleshoot connectivity problems with this client. After you finish both parts of this article, you will have a good foundation for solving the common problems that you’re likely to encounter when working with the SecureNAT client.

Features of the SecureNAT Client

First, let’s take a look at what the SecureNAT client is and how it works. You know that the TMG firewall supports transparent proxying of client requests through the use of the SecureNAT client. The SecureNAT client, then, is any machine on the internal network that has been configured with a default gateway that is capable of routing Internet bound requests to the internal interface of the TMG firewall.

If the SecureNAT client is on the same network ID as the internal interface of the TMG firewall, the client machine will use the internal IP address of the TMG firewall as its default gateway. On the other hand, if the client is on a network ID that is remote from the internal interface of the TMG firewall, then the default gateway will be set to a router that can forward Internet bound requests to the internal interface of the TMG firewall.

It’s important to note that the SecureNAT client is the preferred TMG firewall client for all non-Microsoft operating systems. For example, if you have a Mac or Linux workstation or server on the internal network, you should configure them to be SecureNAT clients. This will allow them to have access to the entire range of TCP and UDP based protocols.

The SecureNAT client also makes publishing servers on the internal network much easier. When you publish a server, you make it available to users on an external network (including the Internet).

Some of the common issues you might encounter with the TMG firewall SecureNAT client include:

• Problems with complex protocols
• Problems accessing web sites
• Problems accessing all protocols
• Name Resolution Issues

While these are common issues, you’ll see that they can be resolved relatively easily. In the following sections, we’ll discuss how to do that.

Problems Using Complex Protocols

First, let’s talk about probems that arise when using complex protocols. The SecureNAT client can take advantage of a wide range of protocols. Many commonly used Internet Protocols are supported, including:

• HTTP and HTTPS
• FTP
• SMTP
• NNTP
• NTP

These protocols, with the exception of FTP, are known as “simple” protocols. What do we mean by that? Well, simple protocols do not require that back channels be established by the destination server. In contrast, the more complex protocols such as FTP require that the server establish a back channel to the TMG firewall. This connection represents a new inbound request. So what’s the effect of that? An Application Filter is required by SecureNAT clients to access complex protocols.

Application Filters

If you find that the SecureNAT client is not able to access certain protocols, it is very likely that the protocol requires a back channel. The classic example of this is found with the standard FTP PORT commands. After the control channel on TCP port 21 is established, the FTP server needs to open a new connection from its own Port 20 back to the TMG firewall. Without some additional help, the TMG firewall will treat this as a “non-ACK” inbound connection and will drop the connection as an unsolicited request.

In order to solve this problem, an Application Filter is required. In the case of FTP, the TMG firewall includes an FTP Access Application Filter. This filter will “listen in” on the conversation between the SecureNAT client and the FTP server, and will accept the new inbound connection request from the FTP server because it has been made aware of it with the help of the FTP Access Application Filter.

If your SecureNAT clients experience problems accessing certain protocols, try installing the Firewall (TMG) client software. If the machine is then able to access the protocols after you’ve installed the Firewall client, you’ll know that you are indeed working with a complex protocol. If that is the case, the best solution is to leave the Firewall client software on the machine.

Firewall Clients Manage their own connections

To avoid the problem with complex protocols, consider using the Firewall client software. Firewall clients can manage their own complex protocol connections, and they do not always require the use of an Application Filter. You can test this out yourself by creating the Protocol Rules that are required to access the complex protocol services you need to connect to and then establish a connection without using the SOCKS 4 Application Filter. It works because the Firewall client can manage its own connections and does not require the help of the SOCKS 4 filter.

Problems Accessing Web Sites

SecureNAT clients are able to access web content in two different ways: either by having their requests directly forwarded to the destination web server, or by having the requests go through the web proxy service. The advantage of having the requests go through the Web Proxy service is that the SecureNAT client will then be able to take advantage of the Web Proxy service’s Web cache. Web objects obtained by the SecureNAT client are also placed in the web cache.

However, problems with web access are often related to Authentication Requirements. Let’s take a close look at these authentication problems and what you can do about them.

Authentication Problems

SecureNAT clients suffer from a major drawback in that they are not able to send credentials to the TMG firewall. This doesn’t mean you have no way to control access. Access controls can be placed on SecureNAT clients by using IP addresses. These computer sets consist of groups of IP addresses on which access controls can be placed. However, if you require outbound access controls that are based on user or group information, the SecureNAT client will not be able to fill the bill.

In order for SecureNAT clients to access HTTP content, you’re going to either need an Access Rule that specifies a client address is allowed access, or you’ll need to have what are known as anonymous access rules in place. These anonymous access rules any request to use the particular rule.

The problem is that anonymous access rules for HTTP requests can wreck havoc with an outbound access scheme that is based on user and group credentials. Naturally, most secure environments are going to have Access Rules that require authentication. User or Group based authentication allows you to have the most flexibility in terms of outbound access control for HTTP requests.

The problem here is that since SecureNAT clients are not able to send credentials, so all requests that require authentication will be dropped. The only solution for a secure environment that requires outbound access controls for HTTP is to configure the SecureNAT clients as Web Proxy clients as well as SecureNAT clients.

Problems Accessing All Protocols

There are times when the SecureNAT client will not be able to access the Internet at all. There are a number of reasons why this might happen. Some of the scenarios include:

• The default gateway has been improperly set on the SecureNAT client
• The SecureNAT client is not configured with the Address of a DNS server
• Access Rules have been configured that allow the SecureNAT client outbound access

It is important to remember that the default configuration of the TMG firewall is to prevent all outbound access for all clients. If you discover that your SecureNAT clients are not able to access the Internet right after you install the TMG firewall, then you just need to go and create Access Rules that will enable your clients access to the protocols they require.

Default gateway problems pop up most often when the clients are on networks that are remote from the internal interface of the TMG firewall . When you encounter these types of routing problems, you should check the routing tables on the intermediate routers. Make sure that the routers do not drop requests for non-local networks, and also check to see that they are configured with default gateways that will forward requests for unknown networks to devices that will send the requests to the internal interface of the TMG firewall.

Summary

In Part 1 of this article, we examined some of the common problems you could encounter with the SecureNAT client. However, a large portion of the major problems you’ll encounter with the SecureNAT client will be related to DNS issues and authentication issues. We’ll be taking a look at DNS/name resolution issues in Part 2.