Thread Info
  • State Suggested Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 49 replies
  • Answers 1 answer
  • Subscribers 10 subscribers
  • Views 71967 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

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

markstones

Hi

Since upgrading to 9.509-3 I have been having difficulties with random websites (amazon, scan.co.uk and others)  timing out when using Google chrome. I've inspected the logs and cannot see any issues at all. I've cleared the cookies/cache, re-installed the browser but now exhausted my options. I am in no doubt the problem lies directly with chrome as the websites have no issues in Firefox, Internet Explorer, Edge.

My setup is;

SG-210 in Transparent mode with SSO and STAS configured

When the pages time out, the following is displayed;

This error is completely random and doesn't appear on other UTMs using older firmware. It seems to break for random websites whilst still allowing me to browse others. Everything was working fine up until the upgrade.

Any ideas would be appreciated

Thanks



This thread was automatically locked due to age.
Parents
  • 0

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

  • 0 in reply to markstones

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

  • 0 in reply to BAlfson

    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. 

  • 0 in reply to JanGatzke

    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.

     

     

  • 0 in reply to DouglasFoster

    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

  • 0 in reply to Thomas Dueringer

    Yes, but it did not solve the problem.

  • 0 in reply to markstones

    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.

  • 0 in reply to markstones

    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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    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"
  • 0 in reply to markstones

    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

Reply
  • 0 in reply to markstones

    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

Children
No Data
Unfiltered HTML