Configuring Web Proxy Clients for Direct Access
by Thomas W Shinder, M.D.
Updated – December 13, 2002
If you frequent the ISAServer.org message boards you’ll notice I often recommend that ISA Server admins configure a particular site or domain for Direct Access. The problems usually relate to Web Browsers looping back through the ISA Server to access Web sites on the internal network, or sites that don’t support the Web Proxy service.
For example, suppose you have Web site on the internal network that has the name www.domain.com. This Web site is also available to Internet users via the same name, www.domain.com. This can cause a problem if the internal and external network users both use the same DNS server to access the site, as this would require the internal network users to access the server by looping back through the external interface of the ISA Server.
You can correct this problem by creating a split DNS infrastructure. Once you configure a split DNS infrastructure, the internal network clients will get the internal IP address of the Web server and connect to that IP address. However, the request will still be processed by the Web Proxy service if the Web Proxy client isn’t instructed to use Direct Access to connect to the site.
Another situation where Direct Access helps is when you need to completely bypass the Web Proxy service. For example, suppose you want to use Outlook Express to access your HotMail account. You’ll find that if you configure your computer as a Web Proxy client, any attempt to connect to the Hotmail account will fail. The problem has to do with authentication issues and the Web Proxy service. The solution to the problem is for connections to the HotMail site to bypass the Web Proxy service.
Even when authentication isn’t an issue, some applications just don’t seem to work well with the ISA Server Web Proxy service. A good example is the download of the Macromedia Flash plug-in. If you try to access the plug-in with a Web Proxy client, the download will fail. You need to bypass the Web Proxy service if you want to access the player.
Configuring the HTTP Redirector
The first thing you need to do is reconfigure the HTTP Redirector Filter. The default setting on the HTTP Redirector is to forward all HTTP requests from SecureNAT and Firewall clients to the Web Proxy service. This default configuration won’t work for us because our goal is to keep communications away from the Web Proxy service for Direct Access to specific sites.
In the ISA Management console, expand your server name and then expand the Extensions node. Double click on the HTTP Redirector entry in the right pane of the console and click on the Options tab. Select the Send to requested Web server option, click Apply and then click OK.
This configuration allows SecureNAT and Firewall clients to send HTTP requests directly to the Web server, rather than having the requests redirected to the Web Proxy service.
Configuring Sites for Direct Access
The next step is to configure the sites that need to bypass the We<
Click on the Direct Access tab. You’ll see what appears in the figure below.
On the Direct Access tab you configure the IP addresses and/or domain names to which you want the Web Proxy Clients to directly connect without going through the ISA Server’s Web Proxy Service.
That is what Direct Access means. Since Direct Access means that the Web Proxy client will not use the Web Proxy service, the browser will need some other method to connect to the resource configured for Direct Access. If the machine you want to connect to is on the internal network, the browser will be able to directly connect to the server. There’s no need for the computer to go through the ISA Server. No address translation or firewall policy needs to be applied when connecting to local (LAT based) resources.
Now consider the example provided in the above figure. There are two entries in the Directly access these servers or domains list. The hotmail.com and the msn.com domains are not on my internal network. So how do I directly access these domains? It should be obvious that I can’t actually directly access these domains because I must go through the ISA Server to get to them. But what I can do is bypass the Web Proxy service and use either the SecureNAT or Firewall client configuration to connect to the Internet. The browser can use the SecureNAT or Firewall client configuration to connect to the ISA Server and allow access to the Internet. The only thing that’s different for the Direct Access sites is that the Web Browser will not use the Web Proxy service to access them.
The Bypass proxy for local servers option tells the browser to not use the Web Proxy service to access “dotless” resources. That is to say, if the server you connect to contains a single label in its name, the Web Browser will not use the Web Proxy service to make the connection.
For example, with the Bypass proxy for local servers option enabled, http://shinder is treated as local, but http://shinder.tacteam.net is treated as remote, in spite of the fact that both of these URLs point to same machine on the internal network. The Web browser connection will go directly to the http://shinder and will not go through the Web Proxy service . The connection request to http://shinder.tacteam.net will go through the Web Proxy service on the ISA Server because it has “dots” in it.
=================
ISA Server Alert
You have to be careful with single label names. The DNS client software does not send single label names for DNS name resolution. The DNS client attempts to qualify the name before sending the request to the DNS server for name resolution. So in this example, when you access http://shinder, the DNS client software attempts to resolve the request by appending a domain name, which typically is the primary domain name of the computer sending the request. If the computer making the request belongs to the tacteam.net domain, the name to be resolved is shinder.tacteam.net. So, the request for http://shinder and http://shinder.tacteam.net end up resolving to the same IP address! The only difference is that when you configure the browser to Bypass proxy for local servers, the browser will bypass the Web Proxy service to access http://shinder, while the browser will use the Web Proxy service to access http://shinder.tacteam.net
=================
The Directly access computers specified in the Local Domain Table (LDT) option allows Direct Access to machines located in domains contained in the LDT. Entries in the Local Domain Table (LDT) are resolved by the client, not by the ISA Server. Web Proxy clients usually allow the ISA Server to resolve names for them. The Web Proxy client computer will have to resolve the name itself if it tries to access Web sites included in the LDT. Since these LDT entries are for internal network domains, your internal network DNS servers will have the appropriate internal address for these servers. The Web Proxy clients are then able to resolve the names of the internal network servers to their internal, private addresses, and then access them without having to go through the ISA Server’s Web Proxy service.
Remember that the Web Proxy client must be configured as a SecureNAT and/or Firewall client in order to make this work. You can configure the same machine to be a Web Proxy, Firewall and SecureNAT client if you like as the clinet configuration is not mutually exclusive.
Implications of Bypassing the Web Proxy Service
What are the implications of allowing SecureNAT and Firewall clients to bypass the Web Proxy service? This is what happens when you configure the HTTP Redirector Filter to pass requests directly to the Web Server. First, you won’t be able to force clients to use the Web Proxy service. Second, if you wish to force user/group access control, you’ll have to configure the clients as Firewall clients, because SecureNAT clients cannot send credentials to the ISA Server.
In actual practice, this configuration should not cause much of a problem. You should always configure Windows operating systems as both Web Proxy and Firewall clients. The Web browser and these computers will always send requests directly to the Web Proxy service unless the request is for a site on the Direct Access list. In that case, the Firewall client will take over and send the request to the Firewall service. Just make sure that you limit access to the HTTP protocol to the appropriate users/groups and the Firewall client will send user credentials to to the Firewall service. This prevents anonymous access through the ISA Server.
SecureNAT clients are problematic because the client isn’t running a Windows operating system and the browser probably isn’t able to accommodate the Autoconfiguration script. Since they cannot use the Autoconfiguration script, they will not be aware of the Direct Access List. How the request is subsequently handled depends on the type of browser and the operating system used.
Note:
If you don’t have a good level of DNS experience or expertice, and you only want to bypass the Web Proxy service and you don’t care if you put extra load on the ISA Server when accessing internal resources, you can use Web Routing Rules to obtain Direct Access. Web Routing Rules for Direct Access are somewhat more simple, but may be the ideal method for small shops. I’ll cover the procedure for using Web Routing Rules for Direct Access in a future article.
Conclusion
Configuring sites for Direct Access allows you to access resources on Web sites that are not compatible with the ISA Server’s Web Proxy service. Direct Access configuration also allows your Web Proxy clients to bypass the ISA Server when connecting to Web servers on your internal network. The Direct Access configuration requires that your browsers are configured to use the Autoconfiguration script; Web Proxy clients not configured to use the Autoconfiguration script will not be aware of the Direct Access list. Finally, the client needs to be configured as a SecureNAT and/or Firewall client so that it can bypass the Web Proxy service when accessing resources on the Internet. Keep in mind the implications of configuring the HTTP Redirector filter to send requests directly to the Internet servers.
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=10;t=000377 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom
