The Local Host network represents the ISA Server 2004 computer. You do not explicitly configure this network. During installation, ISA Server places all local IP addresses for the ISA Server computer in the Local Host network. After installation, if an IP address is added to the ISA Server computer, it is automatically added to the Local Host network. All traffic from the ISA Server computer has Local Host as its source, and all traffic directed explicitly to the ISA Server computer has Local Host as its destination. By default, there is a network rule (Local Host Access) that defines a route relationship between the Local Host network and other networks, and a number of system policy rules (default access rules) that allow access from the Local Host network to basic services and applications residing in other networks. To manage traffic not defined by these rules, you create additional access rules.
When you make Web requests from the ISA Server computer (Local Host network), it is intercepted by the Web Proxy filter. Such traffic originating at the Local Host network is associated with the destination network. The source of the request is not considered to be the Local Host network. Instead, the source IP address is considered to be the default IP address of the network in which the destination address is located.
The implication of this behavior is that for the purposes of policy checking, the destination network’s access policy will be applied to the Local Host request. The properties of the Local Host network will not be considered. This behavior may cause a number of issues, listed in the following sections.
A Web Request to the Internal Network Fails
Problem: A Web request from the ISA Server computer to a resource on the Internal network fails with Error 12209: ISA Server denies the specified Uniform Resources Locator. Require All Users To Authenticate is enabled on the Internal network, and Web Proxy settings are not specified in the browser of the client making the request. This may occur even if you have an access rule configured to allow traffic from the Local Host network to the Internal network.
Cause: ISA Server sets the source IP address of the request to the default IP address of the Internal network (the destination network). ISA Server applies the policy for the Internal network, which requires client authentication. The transparent Web Proxy request cannot be authenticated, and the connection fails.
Solution: Possible workarounds include the following:
-
If only Internet Explorer access is required from the ISA Server computer, the preferred workaround for this issue is to enable Web Proxy access on the Local Host network, and set the Internet Explorer browser Web Proxy settings on the ISA Server computer to use Local Host port 8080 as a proxy.
-
Disable the Require All Users to Authenticate setting on the Internal network. Note that this means that requests to the Internal network will not require authentication unless authentication is required on specific access rules.
A Client Request Authenticated with a Client Certificate Fails, even though the Client Certificate Is Valid
Problem: A client request (authenticated with a client certificate) for a published Web resource fails, even though the client certificate is valid. This may occur when you publish a Web server over Secure Sockets Layer (SSL) allowing access to authenticated users only. When a client presents a client certificate for authentication, the certificate cannot be validated. This occurs in the following scenario:
-
The network in which the certification authority (CA) that generated the client certificate is located has the Require All Users to Authenticate setting enabled.
-
The client certificate includes a certificate revocation list (CRL) distribution point, which points to an HTTP location for the CRL.
Cause: During the client authentication process, ISA Server tries to retrieve the CRL. This request is a transparent Web Proxy request from the Local Host network to the network in which the CA that issued the client certificate resides, which fails because authentication is required on the CA network. Without a valid CRL, the client certificate is assumed to be revoked.
Solution: Possible workarounds include the following:
-
The preferred workaround method (to preserve authentication settings) is as follows:
-
Disable the setting Require All Users to Authenticate on the network on which the CRL distribution point is located.
-
Create a new rule (place it in rule ordering above HTTP access rules), to allow access from the Local Host network to the required network. Do not require authentication on this rule.
-
Modify all HTTP access rules to allow access to authenticated users only.
The other alternative is to disable the Require All Users to Authenticate setting on the network in which the CA is located, and ensure that rules allowing access from the Local Host network to the Internal network do not require authentication. Note that disabling Require All Users to Authenticate on the CA network turns off authentication, unless user authentication is configured for specific access rules that control traffic to the network.
Traffic Is in a Proxy Chain Loop
Problem: You are running a third-party proxy application on the same computer as ISA Server, with the following settings:
-
Clients make Web requests to ISA Server (port 8080).
-
ISA Server has a Web chaining rule configured, to direct traffic upstream to the second Web Proxy application on an alternative port (for example, port 8082).
The client receives a 12206 error: ISA Server detected a proxy chain loop.
Cause: ISA Server receives a Web request on port 8080 and redirects it to port 8082. The third-party proxy application receives the request on port 8082, and sends it to port 80 as an HTTP request.
ISA Server intercepts the traffic on port 80 as a transparent proxy request, and passes it to the Web Proxy filter. This causes traffic to be directed upstream again, causing a proxy chain loop. This is detected when ISA Server receives the request for the third time, and returns an error.
Solution: Possible workarounds include the following:
-
The preferred workaround method (to preserve authentication settings) is as follows:
-
Add a new protocol for outbound TCP port 80. Disable the Web Proxy filter from this protocol.
-
Add an allow rule from the Local Host network to the External network for the new protocol, and set it as the first rule.
-
Add a deny rule from the Local Host network to the External network for HTTP, and set it as the second rule.
-
Disable all system policy rules that apply to HTTP.
-
The other workaround is to disconnect the Web Proxy filter from HTTP, as described in Appendix A: Disable the Web Proxy Filter later in this document. The disadvantage of this workaround is that outbound HTTP requests from SecureNAT and Firewall clients will then go directly to the Web server instead of being redirected to the Web Proxy filter. Such requests will not be served from the cache, and HTTP application layer filtering will not be applied.
This solution works because of the way in which ISA Server processes traffic. Traffic arrives on a particular port, and this port matches specific protocols. ISA Server gathers all the rules that apply to the specific protocols, and processes all these rules up to the first deny rule. The traffic is then passed to the filters registered for the resultant rules. The second rule (denying access) allows port 80 traffic to pass, without going through the filter. Note that this workaround will not work if the Web browser on the ISA Server computer has Web Proxy settings specified. Web requests from the browser will be blocked by the second rule.