This page looks correct and the images and buttons work on the standard block page. The browser URL looks like the above.
But if the user already has IE or Firefox open on another internet page and tries to access a blocked site then get a 200 response from ISA. The block page URL is the site you tried to access and the block page doesn't display correctly because of some relative URL references.
Anyone seen anything similar? We have the same issues on both Standard and Enterprise ISA installs.
Websense support are very confused and of little hlp so far.
< Message edited by isaman_2009 -- 24.Nov.2009 6:31:51 AM >
From: Southern California
I've seen issues with incorrectly displayed blocked pages that were caused by improperly configured browser exception lists. If you are using autoconfiguration, make sure that you have the option to 'directly access computers specified in the addresses tab' selected on the 'web browser' tab of the Internal network properties. If you aren't using autoconfiguration, make sure that the IP address(es) of your ISA firewalls are included in the browser exception list on your clients.
We are not using Autoproxy and the bypass are configured for all internal networks.
The behaviour is the same if you access a node directly. I've also got ISA 2006 SP1 Standard installed on a test box and the same happens so I don't think it's an Enterprise problem. I can switch in ISAPI filter debug and see what turns up.
Can anyone tell me what the correct behaviour should be? Are user meant to see the URL of the page they attempted to go to or the URL of the ISA server?
Can you post or PM to me a pic of the blockpage you receive ?
If you run a packet trace and access a blocked site you shouldsee the response for the initial page being a '302' this is the redirect and you should then see the blockpage url (as above) and the response to that should be a 200
You mentioned that ISA responds with a 200 - do you see the 302 at all ?
From: Budapest, Hungary
I am facing with just the same problem. I did traces on both the cliant, the ISA and the Websense server. It shows that ISA just send an ACK to the request then stops sending any data to client. It starts negotiation the authentication type when works fine.
Some month went by since the last post, is there any solution for the problem?
From: Taylorville, IL
It shows that ISA just send an ACK to the request then stops sending any data to client.
If ISA sent an ACK then it is not supposed to send anything else. If the ISA is the one sending the ACK then it means the machine on the other end initiated the connection and ISA is doing what it is supposed to do after sending an ACK,...which is to sit there and wait for a response.
From: Budapest, Hungary
Thanks for the quick answare. I compared the trace with the another portion when it sends the normal blocking page: After thar particular ACK, ISA sends first some packets to initiate an authentication negotiation then lastly sends a 302 move redirect to the client in order to redirect the browser to the blocling page prepared by the Websense server. What was the solution in your case (if there was any)?