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.

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?

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

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 ;)

After 5 month the issue is solved!!!!!!

The sophos support suggested to switch off the ssl scanning ----------------------------> No Way!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Funny to disable security features ;)

But this unbelievable answer gave us a new Idea

UTM Auto Proxy

This two links helped us:

https://www.fastvue.co/sophos/blog/sophos-utm-auto-proxy-configuration-3-simple-steps/

https://proxyforurl.thorsen.pm/

Greets

Tom