When you configure a site for Direct Access, you’re telling the Web proxy client to not use it’s Web proxy client configuration to connect to the desired resource. The client then must leverage another method of communication to access the destination site, such as it’s Firewall client configuration, or if not configured as a Firewall client, it’s SecureNAT configuration.
Direct Access sites are configured in the Web browser configuration in the ISA Firewall console, as seen in the figure below.
There must be a mechanism to get the Direct Access list to the Web proxy clients. The Web proxy clients must have access to this list, because it’s the browser that makes the decision for Direct Access, not the ISA Firewall. That is to say, if the user wants to go to www.hotmail.com, its up to the user’s browser to decide “hey, I’m not supposed to use my Web proxy client configuration to reach Hotmail, so I’m not going to forward this connection request to the ISA Firewall’s Web proxy listener on my ISA Firewall Network.”
The way the browser gets the Direct Access list is via the autoconfiguration script. There are two ways to access the autoconfiguration script:
- Web browser autodiscovery (Autodiscovery information publishing must be enabled on the ISA Firewall)
- Web browser configuration to use the autoconfiguration script (this can be done manually, through Group Policy, or via start-up or log on script)
The figure below shows the Web browser configuration on my computer. This setting was made in AD Group Policy.
Notice the third option in this dialog box: Use a proxy server for you LAN. If you enable this option only, then the Web proxy client computers will not receive the autoconfiguration script and your Direct Access entries will not work.
The next step is to remove the Web proxy filter from the HTTP protocol. We need to do this because if we don’t remove the Web proxy filter from the HTTP protocol, then the Firewall client and the SecureNAT client requests will be automatically forwarded to the Web proxy filter and we’ll end up in the same mess we were in when the machine was acting as an explicit Web proxy client.
Go to the Properties of the HTTP protocol and remove the checkmark from the Web Proxy Filter checkbox. Click OK and save the changes.
After the Web proxy filter is unbound from the HTTP protocol, only machines acting explicitly as Web proxy clients will benefit from the Web proxy filter’s features, such as Web caching and HTTP protocol inspection. When machines configured as Web proxy clients try to access servers on the Direct Access list, the Web proxy client will not act as a Web proxy client for those connections and thus no caching or HTTP protocol inspection will take place for these problematic sites.
The last step is to create a rule (or rules) for the Direct Access site(s). If you still want to require authentication for outbound access, to those sites, then the client machines must be configured as Firewall clients, since SecureNAT clients can’t authenticate. If you don’t want to require authentication to reach the Direct Access site(s), then you can use the SecureNAT configuration.
HTH,
Tom
Thomas W Shinder, M.D.
Site: www.isaserver.org
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
Email: [email protected]
MVP — Microsoft Firewalls (ISA)