Internal network clients accessing the Internet through an ISA Server are referred to as ISA Server clients. One of the ISA Server client configurations is the Web Proxy client. A computer becomes a Web Proxy client when a browser is configured to use the ISA Server Web Proxy service. While problems with the Web Proxy client are minimal, there are areas that require an administrator’s attention.
This is the second of a three-part series on troubleshooting ISA Server clients. The first article dealt with troubleshooting the SecureNAT client. This time, I’ll go over problems that you might encounter with the Web Proxy client. Three categories of problems that occur with Web Proxy clients are:
- Protocol issues
- Name resolution issues
- Authentication issues
Let’s look at these areas in more detail.
Want to know more?
You can learn more about the different ISA Server client types here.
At first blush, you might think there wouldn’t be too many protocol issues with the Web Proxy client. The Web Proxy client configuration supports HTTP, HTTPS, HTTP-tunneled FTP, and Gopher. However, there are some protocol issues that you should be aware of.
The Web Proxy service accepts calls from Web Proxy clients that have their browsers configured to use the internal interface of the ISA Server. If the ISA Server has multiple internal interfaces, the interface used to accept requests from Web Proxy clients is the one configured as the Outgoing Web Request listener.
Calls made by Web Proxy clients are sent to port 8080, but the HTTP request forwarded by the Web Proxy service is typically sent to port 80 on the Internet Web Server. This is how it should be. However, the Web Proxy service doesn’t limit access to port 80. In fact, you can’t limit Web Proxy clients to a particular Web server port. For example, you might want to limit Web Proxy clients to access only port 80 on Internet servers. You won’t be able to do this because there is no facility in the Web Proxy service to limit which Web server port is accessible at the Internet server. As long as the request is an HTTP request, the Web Proxy service will accept and forward it.
Web Proxy clients can access FTP sites on the Internet by taking advantage of HTTP-Tunneled FTP. The actual FTP request is tunneled inside the HTTP request sent to port 8080 on the Outgoing Web Requests listener. By default, the ISA Server forwards the FTP call as a PASV mode FTP (or alternate FTP mode) request to the Internet FTP server.
However, the Web Proxy client is limited in that it can only download files. The machine configured only as a Web Proxy client can’t upload files to an FTP server. When you connect to an FTP site from a machine configured as a Web Proxy client only, you’ll see what appears in Figure A.
|Web Proxy client-only machines can’t upload to FTP servers.|
Note that Internet Explorer configured as a Web Proxy client has some smarts built into it and can take advantage of alternate methods of accessing an Internet FTP site. If the Web Proxy client machine is also configured as a SecureNAT or Firewall client, the browser will be able to allow the Web Proxy client browser to upload files to FTP servers.
SecureNAT and firewall clients aren’t mutually exclusive
You may have read in the ISA Server Help file that a machine can’t be a SecureNAT and Firewall client at the same time. This is true from a protocol perspective, because the Firewall client will take control of all TCP and UDP requests that leave the client computer for Internet-bound destinations. However, the Firewall client doesn’t intercept non-TCP/UDP requests. You might want to configure a machine as a Firewall and SecureNAT client, in addition to being a Web Proxy client, so that you have access to non-TCP/UDP protocols such as GRE (IP Protocol 47) and ICMP.
Name resolution issues
One of the conveniences of the Web Proxy client is that the ISA Server resolves Internet host names on behalf of the Web Proxy client. You don’t need to configure a DNS server address on the Web Proxy client, which is helpful for smaller shops that don’t have their own DNS servers.
Because the ISA Server resolves requests on behalf of the Web Proxy client, you must ensure that your DNS configuration on the ISA Server is configured properly. The proper DNS configuration on the ISA Server interfaces is dependent on the DNS infrastructure of your internal network.
For example, if you have an Active Directory domain, you have a DNS server installed on your network. You should configure the DNS server on your internal network to resolve Internet host names. You can accomplish this in several ways. One way is to make sure that your Active Directory domain doesn’t represent a root zone on your DNS server. This will allow the Root Hints file on the DNS server to be populated, and your internal DNS server will be able to perform recursion to resolve Internet host names. Another way you can configure your internal DNS server is to configure it to use a Forwarder. In this case, the internal network DNS server will forward queries for zones it doesn’t have authority over to the DNS Forwarder. Note that in both of these cases you’ll need to configure a DNS Query Protocol Rule on the ISA Server to allow the DNS Server to make queries to Internet DNS Servers.
When you have an internal network DNS server that can resolve Internet host names, you should configure the internalinterface of the ISA Server to use the internal DNS server. The reason for this is that the internal interface typically is on the top of the adapters list in the Advanced Settings dialog box in the Network And Dial-up Connections window. If the internal interface is not the primary adapter (that is, the adapter at the top of the list), you should fix it.
If you don’t have an internal DNS Server that can resolve Internet host names, you should configure the external interface with the IP address of your ISP’s DNS server(s). The internal interface address can remain empty. However, I recommend that you never configure the internal interface of the ISA Server with the IP address of an external DNS server because if you someday install Active Directory on the network, difficult-to-troubleshoot problems with intra-domain name resolution pop up.
Name resolution problems are the most common ISA server-related problems
You should double-check that the DNS settings are properly configured on the ISA Server. DNS configuration problems led to the most commonly asked troubleshooting questions I’ve encountered among ISA Server administrators. You can easily test name resolution on the ISA Server by using the nslookup command. When using nslookup, make sure that you test for name resolution for internal and external network clients.
The ISA Server DNS cache
You would think that the ISA Server uses the DNS client service on the ISA Server computer to take advantage of the DNS client caching features, but this assumption would be wrong. The ISA Server software maintains its own DNS cache, which is independent of the Windows 2000 DNS client service cache.
It’s not unusual for server software to maintain its own name caching services. But you need to know how the cache works in order to troubleshoot name resolution problems. The ISA Server DNS cache sets a Time To Live (TTL) on cached name resolutions to an incredible six hours. This will cause problems with name resolution for sites that have recently changed their IP address, or for sites that change their IP addresses on a frequent basis (such as dynamically registered sites).
Restarting the Web Proxy service can clear the ISA Server DNS cache. However, you’ll run into the same problem again unless you change the TTL on cached entries. To make the change, open regedt32 and navigate to the following location:
Double-click on the msFPCDnsCacheTtl entry. The value is seconds in Hex. Change the value to a shorter period (such as one hour) if you find that you’re running into frequent problems with name resolution for either Web Proxy or Firewall clients.
Improper changes made through the registry can cause the computer to fail to boot. Use the Registry Editor with extreme caution.
The Web Proxy client is the only ISA Server client type that can send authentication information to the Web Proxy service. While the Firewall client can send authentication information to the Firewall service, it can’t send user credentials to the Web Proxy service. This is the cause of many troubleshooting adventures for ISA Server administrators.
To appreciate the problems you encounter with Web Proxy client authentication, you first need to understand how the Web Proxy client interacts with the Web Proxy service. When a Web Proxy client browser sends a request to the Web Proxy service, the Web Proxy service checks to see if the request requires authentication. If the ISA Server isn’t configured with any rules that require authentication for the request, the request is treated as anonymous, and the ISA Server doesn’t ask for authentication.
However, if the ISA Server does have a rule that limits access to the request based on user or group membership, the ISA Server will send back to the Web Proxy client an HTTP error 407 that requests authentication. When the Web Proxy client receives this 407 message, it will respond by forwarding authentication information to the Web Proxy service.
The default Site and Content rule for stand-alone ISA Servers allows anonymous access to all sites and content at all times, to everyone. This rule allows anonymous requests to be passed through the Web Proxy service. Because these are anonymous requests, the Web Proxy client doesn’t forward authentication information and the Web Proxy log files won’t contain user information.
You can solve the problem of anonymous access to the Web Proxy service in several ways. The simplest way is to force authentication on the Outgoing Web Requests listener. When authentication is forced, all requests made to the Web Proxy service will be authenticated, even if there is no rule configured on the ISA Server that would require authentication.
Perform the following steps to force authentication at the Outgoing Web Requests listener:
- In the ISA Management console, right-click on your server or array name and click the Properties command.
- In the Properties dialog box, click the Outgoing Web Requests tab.
- On the Outgoing Web Requests tab, place a checkmark in the Ask Unauthenticated Users For Identification check box (Figure B). Click Apply and select the option to manually restart the Web Proxy service. Click OK, and then click OK again.
- Restart the Web Proxy service.
|Forcing authentication at the Outgoing Web Requests listener|
Solve the mysteries of the HTTP Redirector filter
One of the most useful application filters included with ISA Server is the HTTP Redirector filter (Figure C). The filter allows requests from SecureNAT and Firewall clients to be forwarded to the Web Proxy service, even when those machines aren’t configured as Web Proxy clients. This is a good deal, because this allows SecureNAT and Web Proxy clients to take advantage of the Web Proxy cache to speed up access to Web pages.
|The HTTP Redirector filter is configured to forward SecureNAT and Firewall client requests to the Web Proxy service.|
However, there’s one major limitation of the HTTP Redirector filter: It cannot forward credentials provided by Firewall clients to the Web Proxy service. This isn’t an issue with SecureNAT clients, because they can’t send credentials. However, many ISA Server administrators are left scratching their heads because they don’t understand what happened to the credentials the Firewall client sent and why the Firewall client requests for Web pages are denied.
For example, suppose you change the default Site and Content Rule on a stand-alone ISA Server so that it applies only to Domain Users. This rule will require that the Web Proxy service authenticate the user. The Firewall client dutifully sends credentials to the Firewall service, and the request is passed up to the Web Proxy service through the HTTP Redirector filter. During its transit from the Firewall to the Web Proxy service, the HTTP Redirector removes the credentials provided by the Firewall client. The request is received by the Web Proxy service as an anonymous request and is denied. You’ll see the same problem come up when the Outgoing Web Requests listener is configured to force authentication.
You should bypass the Web Proxy service to troubleshoot Web application problems. You might run into applications that don’t work properly with the Web Proxy service. Examples of such programs include RealPlayer and the proprietary software solutions by many mail transport carriers. If you find that you aren’t able to access a particular Web site, try removing the Web Proxy client configuration on the client machine. After making the machine a SecureNAT or Firewall client only, configure the HTTP Redirector to forward requests directly to the server. This will allow the requests to bypass the Web Proxy service and will often get problematic Web applications working again.
Web Proxy clients can work with Web Proxy service
While the Web Proxy client configuration tends to be the least problematic of the ISA Server client configurations, you should be ready to solve the most common Web Proxy client-related problems. If you understand the problems related to name resolution, protocol problems, and authentication issues as discussed here, you’ll be well prepared to fix the majority of Web Proxy client-related problems you’ll encounter. For more information on ISA Server and its client configurations, check out the ISA Server Web site.