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.

Guys, I know that rules for Support are different in Europe than in the Americas, but I think you should request escalation.  My guess is that this is a Chrome problem or that you really do have a device that's requesting name resolution for a suspicious/malevolent domain, but Support should answer this question.

Cheers - Bob

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

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?

Yes, but it did not solve the problem.

Thx Jan, thats what I expected

Okay so this morning i've spent some more time on this.

I tried decrypt & Scan and that did not have any effect at all, so all three solutions suggested by DouglasFoster do not resolve the problem for my setup.

What i have discovered though is that if it is an authentication issue, the authentication is not being cached. For example, i can type in manually www.amazon.co.uk which will open successfully in Chrome.  If i just type amazon.co.uk in the same browser window (directly afterwards), i will get the timeout and also a firewall entry

Upon checking the web filter logs, this request appears to be blocked from reaching the web filter at all. The ip address 192.168.1.254 is the LAN interface of the UTM.

I'm tired so maybe i'm missing something but I can't fathom why this issue only affects certain https websites. In one session, i can browse various https websites without issue but there are two websites in particular i can reliably re-produce this problem with, which are amazon.co.uk and scan.co.uk.

Mark, this looks like a problem with your PC or browser.  Why would you get name resolution to a local IP?

Moreover, the www. FQDN resolves to (13.33.105.73), and the other to 54.239.33.58.

You might have a DNS configuration error, but none of this makes sense to me.

Cheers - Bob

Same here Bob

Makes no sense to me either and its not just my PC that's affected.  I've re-tested and can re-produce the problem so i'm not going Mad (just yet)

The only browser i can't break it with is Edge, all sites work first time with that seamlessly.

Heres the full firewall log for those "drops"

2018:08:16-23:22:39 network-ho ulogd[14795]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="1c:1b:0d:99:77:f8" dstmac="00:1a:8c:51:6a:d6" srcip="192.168.1.55" dstip="192.168.1.254" proto="6" length="52" tos="0x00" prec="0x00" ttl="128" srcport="55484" dstport="443" tcpflags="SYN" 

And with my last post, i think the "penny" may have just dropped!

I've just noticed that the host entry for my servers that are used for STAS have been used in some rules. This is bad as they have an interface set!

I am going to go through all my rules settings to remove these hosts and replace them with <any> interface versions.

I'll report back after some more testing

In the other browsers, don't select automatic for the proxy settings - does that fix this?

Cheers - Bob

No joy

I'm still getting random firewall drops from local ip to ~UTM LAN IP for port 443.

Back to the drawing board i guess...........

on the 2 of July i wrote that I expect the answer before christmas.

Now I change to easter!!! HAHAHAAHAH ;)