1. Introduction

 

It is very common to firewall administrators to have deny rules to block traffic to some destination and sometimes instead of just exposing an error page to the end user they prefer to redirect the end user to a custom and friendlier page.  This redirect is done by using the Deny/Redirect action in the access rule as shown below:

 

 

Figure 1 – Deny rule with a redirect to the destination page.

 

Note: for more information on the HTTP 302 redirect on ISA read How to Allow HTTP 301 through ISA Server 2006.

 

When the end user hits this rule ISA Server sends a HTTP 302 redirect as shown in the following working netmon trace:

 

10.20.20.200  10.20.20.2    HTTP   HTTP:Request, GET http://www.fabrikam.com/

- Http: Request, GET http://www.fabrikam.com/

    Command: GET

  + URI: http://www.fabrikam.com/

    ProtocolVersion: HTTP/1.1

    Accept:  image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*

    Accept-Language:  en-us

    UA-CPU:  x86

    Accept-Encoding:  gzip, deflate

    UserAgent:  Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)

    Host:  www.fabrikam.com

    ProxyConnection:  Keep-Alive

    HeaderEnd: CRLF

 

10.20.20.2    10.20.20.200  HTTP   HTTP:Response, HTTP/1.1, Status Code = 302, URL: http://www.fabrikam.com

- Http: Response, HTTP/1.1, Status Code = 302, URL: http://www.fabrikam.com/

    ProtocolVersion: HTTP/1.1

    StatusCode: 302, Moved temporarily

    Reason: Object Moved

    Date:  Tue, 01 Sep 2009 12:36:26 GMT

    Connection:  close

    ProxyConnection:  close

    ContentLength:  0

    Location:  http://dccont.contoso.msft

    HeaderEnd: CRLF

 

For this specific example the following page appears as result of this redirect:

 

 

Figure 2 – Redirect to a custom page.

 

This is the behavior that the system administrator wants to accomplish with the settings that he has on ISA Server, however this post describes a potential problem that can happen when users using Internet Explorer 7 (and above) are trying to access a site that is located in the deny list using HTTPS.

 

2. Internet Explorer Cannot display the page

 

For this failing scenario the internal client (behind ISA Server) was trying to access https://mail.fabrikam.com and during that access the error below appeared:

 

 

Figure 3 – Error that client was receiving when trying to access the HTTPS site.

 

Using Network Monitor I capture the request to better understand why this was happening and at the same time I enabled ISA Logging. Here it is the result:

 

1. Client sends the request:

 

10.20.20.200  10.20.20.2    HTTP   HTTP:Request, CONNECT mail.fabrikam.com:443

- Http: Request, CONNECT mail.fabrikam.com:443

    Command: CONNECT

  + URI: mail.fabrikam.com:443

    ProtocolVersion: HTTP/1.0

    UserAgent:  Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)

    ProxyConnection:  Keep-Alive

    ContentLength:  0

    Host:  mail.fabrikam.com

    Pragma:  no-cache

    HeaderEnd: CRLF

 

2. ISA Server evaluates the request and identify that this URL belongs to the Domain Name set that the deny access rule is using and logs the following event in the Monitoring/Logging Page:

 

 

Figure 4 – ISA identifies that the destination URL belongs to a block list.

 

3. The access rule blocks the request and since it has an option to redirect the request to an internal server which has the error message that users should receive, the packet below is sent:

 

 

10.20.20.2    10.20.20.200  HTTP   HTTP:Response, HTTP/1.1, Status Code = 302, URL: mail.fabrikam.com:443

- Http: Response, HTTP/1.1, Status Code = 302, URL: mail.fabrikam.com:443

    ProtocolVersion: HTTP/1.1

    StatusCode: 302, Moved temporarily

    Reason: Object Moved

    Date:  Tue, 01 Sep 2009 12:39:45 GMT

    Connection:  close

    ProxyConnection:  close

    ContentLength:  0

    Location:  http://dccont.contoso.msft

    HeaderEnd: CRLF

 

4. For our surprise (since it was working on IE6 and other browsers) Internet Explorer 7 sends a FIN and doesn’t go out to the redirect page:

 

10.20.20.200  10.20.20.2    TCP    TCP:Flags=...A...F, SrcPort=1359, DstPort=HTTP Alternate(8080), PayloadLen=0, Seq=3697209130, Ack=2998660669, Win=65368 (scale factor 0x0) = 65368

 

Collaborating with IE Team (thanks Michael Van Dao) we learned that this is expected due a behavioral change on IE 7 as it is explained in the post below:

 

http://blogs.msdn.com/askie/archive/2009/06/18/change-in-behavior-with-internet-explorer-7-and-later-in-regard-to-connect-requests.aspx

 

Starting with IE7, a behavior change has been made in how IE handles Server certain response codes to web browser connections that originate as a CONNECT request.  Specifically, if a CONNECT request is made by IE to a Web Server and it receives a Server response to that CONNECT request with something other than 200, IE could reject that response as invalid (ERROR_HTTP_INVALID_SERVER_RESPONSE). 

 

4. How to Block HTTPs without using Redirect?

 

One alternative to keep blocking access to the URL that you want and avoid the end user to receive a “page cannot be display” error is to create two rules on ISA Server. The plan is to handle all redirects with one rule that applies to all protocols except HTTPS, and the other rule would only apply to HTTPS and not use the redirect option.

 

These rules will be configured as follows:

 

Rule #1

·         Type: Deny

·         Protocols: All Protocols Except HTTPS (see Figure 5)

·         Redirect Enabled.

·         To:  Domain Name Set or URL Set that has the list of unwanted URLs.

 

 

Figure 5 – Protocols that belongs to the rule first deny rule.

 

Note: It is very important to emphasize that by blocking all protocols you can also be affected by lack of DNS performance or DNS issue as explained in this post http://blogs.technet.com/isablog/archive/2009/01/12/isa-server-2006-stops-answering-requests.aspx.

 

Rule #2

·         Type: Deny

·         Protocols: HTTPS (see Figure 6)

·         Redirect Disabled (see Figure7).

·         To:  Domain Name Set or URL Set that has the list of unwanted URLs.

 

 

Figure 6 – Protocols for the second deny rule.

 

 

Figure 7 – Action for the second deny rule

 

Here it is what will happen on this scenario when the client workstation tries to access https://mail.fabrikam.com/exchange:

 

1. Client sends the request:

 

10.20.20.200  isacontn2.contoso.msft     HTTP   HTTP:Request, CONNECT mail.fabrikam.com:443

 

2. ISA Server evaluates the request and sees that this request matches with the “My Block List – HTTPS” rule:

 

 

Figure 8 – ISA blocks the access using the HTTPS rule.

 

3. ISA Server then sends the HTTP 502 to the client workstation:

 

isacontn2.contoso.msft     10.20.20.200  HTTP   HTTP:Response, HTTP/1.1, Status Code = 502, URL: mail.fabrikam.com:443

- Http: Response, HTTP/1.1, Status Code = 502, URL: mail.fabrikam.com:443

    ProtocolVersion: HTTP/1.1

    StatusCode: 502, Bad gateway

    Reason: Proxy Error ( The ISA Server denied the specified Uniform Resource Locator (URL).  )

    Via:  1.1 ISACONTN2

    Connection:  close

    ProxyConnection:  close

    Pragma:  no-cache

    Cache-Control:  no-cache

  + ContentType:  text/html

    ContentLength:  666  

    HeaderEnd: CRLF

  + payload: HttpContentType =  text/html

 

4. The error below appears in the client workstation:

 

 

Figure 9 – Default message for 502 error.

 

The good thing about this approach is that if you don’t like this error message that client will receive, you still can customize it by using the guidelines from the article below:

http://technet.microsoft.com/en-us/library/bb794832.aspx

 

Author

Yuri Diogenes

Sr Security Support Escalation Engineer

Microsoft CSS Forefront Edge Team

 

Technical Reviewers

Vic Singh Shahid

Escalation Engineer

Microsoft CSS Forefront Edge Team

 

Michael Van Dao

Sr Support Escalation Engineer

Microsoft DSI IE Core Team