Troubleshooting Web Proxy Traffic in ISA Server 2004

The Web Proxy filter in Microsoft Internet Security and Acceleration (ISA) Server 2004 works at the application level on behalf of clients residing in networks protected by ISA Server that request Hypertext Transfer Protocol (HTTP) and Secure Hypertext Transfer Protocol (HTTPS) objects. Such Web requests benefit from application layer inspection and caching, and may be from a number of sources:

• Requests from Web Proxy clients. Specify ISA Server as a proxy server in browser settings. Web Proxy client requests are passed directly to the Web Proxy filter.
• Requests from SecureNAT or Firewall clients. Do not have Web Proxy settings in the browser pointing to ISA Server. By default, the predefined protocol, HTTP, in ISA Server is bound to the Web Proxy filter. With this setting in place, ISA Server intercepts requests from SecureNAT and Firewall clients, and passes them to the Web Proxy filter for transparent handling. This is known as transparent network address translation (NAT).

Applying NAT substitutes a global Internet Protocol (IP) address that is valid on the Internet for the internal IP address of the client request, thus protecting internal addresses. In some circumstances, applying NAT to traffic passing through the Web Proxy filter may cause unexpected results. This document describes a number of issues related to this default behavior.

VPN Client Issues

Internet Requests from VPN Clients Fail

Local Host Network Issues with the Web Proxy Filter

A Web Request to the Internal Network Fails

A Client Request Authenticated with a Client Certificate Fails, even though the Client Certificate Is Valid

Traffic Is in a Proxy Chain Loop

Appendix A: Disable the Web Proxy Filter

VPN Client Issues

This section describes virtual private network (VPN) client issues.

Internet Requests from VPN Clients Fail

Problem: A VPN client connected to ISA Server attempts to make an HTTP request to the Internet through ISA Server. The VPN client is not configured as a Web Proxy client. The access attempt fails, even though there is an access rule allowing outbound HTTP requests from the VPN Clients network to the External network, and a network rule configured to route traffic between the two networks.

Cause: ISA Server intercepts the VPN client request and redirects it to the Web Proxy filter. It is handled as a transparent Web Proxy request, and the IP address is translated (NAT). The VPN client request is identified by ISA Server as coming from the VPN tunnel interface and NAT is not handled correctly and is blocked by ISA Server firewall policy.

Solution: Possible workarounds include the following:

• Construct the rules as follows:
  • Create a new protocol definition with the following settings: Protocol: TCP; Direction: Outbound; Port: 80. Disable the Web Proxy filter for this protocol, as described in Appendix A: Disable the Web Proxy Filter later in this document.
  • Create a new access policy rule allowing VPN clients to use the new protocol you created, with all networks. Set this as the first rule in the access rule ordering.
  • Create another access rule allowing all outbound traffic for VPN clients to all networks. Set this as the second rule in the access rule ordering. Set the protocol condition to this rule to All outbound traffic except selected. Add HTTP to the exception list.
  • Create a network rule with a route relationship from the VPN Clients network to all networks.
• The other workaround is to disable the Web Proxy filter for HTTP. 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.

Local Host Network Issues with the Web Proxy Filter

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.

Appendix A: Disable the Web Proxy Filter

To disable the Web Proxy filter for HTTP, do the following:

1. In ISA Server Management, click the Firewall Policy node.
2. On the Toolbox tab, click Protocols.
3. Expand All Protocols, right-click HTTP, and then click Properties.
4. Click the Parameters tab, and in Application Filters, clear Web Proxy Filter. Then click OK.
5. Click Apply to update the firewall policy.