Thread Info
  • State Not Answered
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 11 replies
  • Subscribers 3 subscribers
  • Views 26978 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

IE9 and IE10 is crashing

m@rek
Internet Explorer 9 and 10 is crashing (not IE10, Chrome and Firefox) when users go to web sites that are blocked by policy. It also happens when visited web sites attempt to connect/get content from web sites that are blocked by policy as well.

UTM 9.35 with the following settings:
-HTTPS Scan Settings: "URL filtering only"
-Transparent mode with Active Directory SSO

As of yesterday, IE9 and IE10 was crashing constantly and I saw five sites being "block" in Web Filtering Live Log so I added those URLs into existing "Exception List" for Microsoft sites; here's what we had in that exception list before:

Skipping: Authentication / Block by download size / Extension blocking / SSL scanning

Matching these URLs:
   ^https?://([A-Za-z0-9.-]*\.)?windowsupdate\.com/
   ^https?://([A-Za-z0-9.-]*\.)?microsoft\.com/


After watching Web Filtering Live Log for a while, I have changed that exception and seems like IE9 and IE10 is not crashing now as long as users do not attempt to visit site that is blocked by policy etc.

Here's that exception list after change:

Skipping: Authentication / Block by download size / Extension blocking / URL Filter / SSL scanning

Matching these URLs:
   ^https?://([A-Za-z0-9.-]*\.)?windowsupdate\.com/
   ^https?://([A-Za-z0-9.-]*\.)?microsoft\.com/
   https://iecvlist.microsoft.com
   http://crl.microsoft.com/
   http://ie9cvlist.ie.microsoft.com/
   crl.microsoft.com


Is there a solution to that problem? Seems like when users attempts to visit https site that is block by policy, the IE9 and IE10 will crash but not IE11, Chrome and Firefox.

Thanks guys,
Mark


This thread was automatically locked due to age.
  • 0
    If this were a widespread problem caused by the UTM we would hear about it.  It must be something specific to your Windows boxes or configuration.
  • 0
    Seems like I'm not the only one with this problem; here's another post I just found:

    https://community.sophos.com/products/unified-threat-management/astaroorg/f/55/t/46915

    Besides not using IE9 and IE10, is there any work around this issue?
    Thanks,
    M
  • 0
    In fact i'm seeing the same... I had this issue back in july that made me rollback the version to 9.1  The problem seem to be related to id 34460 that was suposed to be solved by now. The fact is that we continue to have it (does not happen with Firefox or Chrome or IE11).   Updating to IE11 is not possible (due to application compatibility).  Does no one have more info on this ? I need urgently a WA (btw, this is happening with standart mode proxy with SSO).

    (I find it "weird" that this is not affecting more customers)
  • 0
    The problem is related to IE handling of 4xx and 5xx error codes.  It is Microsoft bug.  Mantis 34460 (released in 9.314) did fix it for a majority of cases.

    I know that developers had a hard time investigating.  Because it only happens at client sites on their window computers, in order to investigate properly they need more access than normal (they need access to the computers that crash, not just the UTM).

    For anyone still having a problem, please contact Support, mention 34460.  Especially if you are willing to allow support/dev the access they need.

    If you have a support contact for Microsoft, I would also recommend contacting them.  [:)]
  • 0
    Update/Correction.  I just talked to the Dev.

    34460 is in 9.314.  This does not fix the problem.  This puts in a workaround, which adds a 1 second delay to blocks and error conditions.  It is disabled by default.

    Please contact Support and ask them to enable the workaround on your box.
  • 0
    Hi Michael,

    I´ve been talking with support since yesterday (currently on L3). They are trying to replicate the issue on their boxes using my configurations. 

    I´m waiting for their feeback (hope that will be soon since everyone is being affected).

    Do you think it´s better to contact them in order to ask for this?
  • 0
    If you need a quick fix: Ask them to apply the workaround introduced in Mantis 34460.

    If you want to help find an ultimate solution and are willing to help towards it then continue working with support as you are.


    In my opinion - this is a Microsoft problem.  My guess is that some interaction with applications and KBs that you have installed on your boxes is causing this.  An ultimate solution will be to figure out what that is and then uninstall it.  Even if we could come up with a Sophos workaround that is acceptable enough that it can be turned on for everyone everywhere, it is still a workaround for an MS bug.

    IMO, it might be interesting if you could install a brand new plain Win7 box with no corporate image and no automatic updating and see if it works in your network.
  • 0
    I don´t mind of find the solution, but, the customer cannot have this on their browsers (this is already day 2).

    We have made your suggestion (yesterday we have installed a new Windows 7, and installed a Internet Explorer 9) without making any update. The behaviour happens right on the first access. As soon we try to access a https page that has some content blocked, the browser crashes.

    I´m waiting for support to apply the WA, but of course it would be a good idea to keep in working to find the solution.
  • 0
    A little spelunking in cc indicates what probably is the setting.  Don't do the below yourself if this is on a UTM with a paid subscription.  Without a release or instruction from Sophos, you could endanger your Support contract.  As root:

    cc set http ie_ssl_blockpage_workaround 1



    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    Hi Balfson and Michael Dunn,

    in fact it worked! By performing that command, Internet Explorer is not crashing anymore [[[:D]]] [[[:D]]] [[[:D]]]

    Support has done the above procedure last Friday and the customer has confirmed that the issue is gone (still making some additional testing since the fix was applied at the the end of the day).

    Thank you very much for the help. 

    This forum really "rocks" [H]
Unfiltered HTML