UTM 9.509-3 - Webpage Timeouts in Chrome after upgrade 9.509-3 in transparent mode

I've now opened a ticket. I have premium support so hopefully i'll get a response before the world cup ends

Dream on, I have a ticket open for this for 4 weeks now. There seems to be no easy fix.

Hi BAlfson,

We have already done Teamviewer sessions many times. But, for the moment they finds nothing.

This problem does not only occur on Chrome but also on IE and FF.

If I go on my SOPHOS WebAdmin page (not him IP but external address), I can reproduce the problem. If I don't empty the cache of the browser, the problem persist (not on FF I have to recreate a new profile)...

Regards,

News from anybody?

And Yes BAlfson I opened a ticket ;)

Tom

Support have been looking but have found nothing wrong.

They keep referring me to the SSO setup instructions (which i have gone over and checked more times than i can remember)

Funnily enough, i just upgraded another SG appliance to the latest firmware and now users that are using that have started to get the same issue.

Very frustrating when support won't even comprehend it could be an issue with the software/UTM >  Their current stance is "its the way you are using it / set it up"

Still waiting :(

I've had no luck so far either

They have even closed the case after giving up. They kept pointing me to the SSO setup page on their website. Their support has had zero value to me so far across all products i own.  Out of 5 critical tickets raised in the past , none have been resolved.

I have a current P1 critical issue with their Central Wifi product. All my networks are down which is having a severe business impact. After four days, i'm not even sure they are still working on it.

I'm sorry to hear that, Mark.  All of my clients' cases are resolved fairly quickly, so I would suggest that you connect with Sophos Sales to get a recommendation of a good UTM Sophos Solution Partner in your area.  There, you will have someone that understands how to get results from Sophos Support.  Best of luck!

Cheers - Bob

Guys, I thinked I fixed it. If you visit a Website using HTTPS with Firefox it will use HTTPS for later visits even if you try to access it using HTTP. This means that authentication will break if you accessed your UTM with HTTPS before (User Portal, Webadmin...). The Port does not matter. For Firefox it is still the same site. To solve this you need to go to your history (ctrl+shift+h), right click your utm and forget the site. Restart Firefox and authentication is working fine again. I tested this on multiple clients yesterday and was able to solve the problem on all of them. 

Your reported behavior is of course a known limitation of Transparent Web Filtering.   It cannot obtain NTLM information from an https session, so it has no information for doing AD SSO.   As a workaround, it assumes the last http user from the source IP address is also the current https user.   If you have no prior http traffic, it cannot guess, so you are an unauthenticated user.   If your policy does not allow unauthenticated traffic, it blocks the request because you asked it to do so.   So your problem will return.

Since flushing caches will get old very quickly, the better solutions are:

1. enable https decrypt-and-scan,
2. change your policy to allow a default set of web activity for an unauthenticated user, or
3. change authentication to use STAS, Browser, Client, or Basic methods.

Of the three options, I recommend #1.

Why might the problem have only appeared now?

Connecting to an https site with http causes a redirection, which adds overhead and latency.   Firefox probably added a performance tweak to cache the redirection rather than your original URL request.  My guess is that it has nothing to do with UTM.

DouglasFoster said:

Your reported behavior is of course a known limitation of Transparent Web Filtering.   It cannot obtain NTLM information from an https session, so it has no information for doing AD SSO.   As a workaround, it assumes the last http user from the source IP address is also the current https user.   If you have no prior http traffic, it cannot guess, so you are an unauthenticated user.   If your policy does not allow unauthenticated traffic, it blocks the request because you asked it to do so.   So your problem will return.

Since flushing caches will get old very quickly, the better solutions are:

1. enable https decrypt-and-scan,
2. change your policy to allow a default set of web activity for an unauthenticated user, or
3. change authentication to use STAS, Browser, Client, or Basic methods.

Of the three options, I recommend #1.

Why might the problem have only appeared now?

Connecting to an https site with http causes a redirection, which adds overhead and latency.   Firefox probably added a performance tweak to cache the redirection rather than your original URL request.  My guess is that it has nothing to do with UTM.

 

 

 

In my setup both solutions 2 & 3 have been in use since day one.

I get the issue in all browsers at random intervals and for random websites following prior http traffic.

I will look into Solution #1

Someone tested the Update?

Someone tested the Update?

Yes, but it did not solve the problem.

Thx Jan, thats what I expected