Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 4 subscribers
  • Views 26060 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

Sophos UTM 9 - This site can’t be reached / took too long to respond / Connection to server timed out

Peter Charlton

Good Afternoon,

 

I am having difficulties with handful of websites not loading, giving one of the following error messages, 

  • This site can’t be reached
  • Took too long to respond
  • Connection to server timed out

Websites

These sites are working outside of this network.

 

Sophos Sepcs:

Model: SG115w

Subscriptions: Base Functionality, Email Protection, Network Protection, Web Protection, Webserver Protection, Wireless Protection, Endpoint AntiVirus

Firmware version: 9.411-3

 

Error:

2017:07:12-12:26:42 utm httpproxy[4018]: id="0002" severity="info" sys="SecureWeb" sub="http" name="web request blocked" action="block" method="CONNECT" srcip="172.16.1.2" dstip="194.154.170.15" user="" group="" ad_domain="" statuscode="500" cached="0" profile="REF_DefaultHTTPProfile (Default Web Filter Profile)" filteraction="REF_DefaultHTTPCFFAction (Default content filter action)" size="226" request="0xe2589e00" url="personnelchecks.employmentcheck.org.uk/" referer="" error="Connection timed out" authtime="0" dnstime="7" cattime="34956" avscantime="0" fullreqtime="127313170" device="0" auth="0" ua="Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36" exceptions="" overridereputation="1" category="105" reputation="trusted" categoryname="Business"

 

Screen Shot:

Testing Completed So Far

So Far I have completed the following:

  1. Removed the web filtering all together
  2. Added Whitelisting 
  3. Added Exceptions to the firewall
  4. https://community.sophos.com/products/unified-threat-management/f/web-protection-web-filtering-application-visibility-control/74018/categorization-sometime-fails---long-loading-time-of-website

I have reverted all this testing back to the original state

 

Previous Error

Previously we had an error with our ISP forwarders being incorrect however this was months ago and seems to not be the reason for this error.

 

I am at a loss as to where this is getting blocked or why it is not working properly, any help would be much appreciated.

 

Kind Regards

 

Peter



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

    I am having a similar issue, but only when the device is in the transparent host list, or I turn off the web proxy.  Masq and Firewall rules are set to allow all traffic out of the house.  If the proxy is used, it works flawlessly.  If I add the computer to the transparent host list, then some sites work and some don't.  It is almost like DNS requests are not getting sent unless the device is in the web proxy list.  This just started happening with 9.501 and is happening on 9.502.  Also, I have noticed considerable lag in Live Log for the Firewall.

  • 0 in reply to GoBlando

    I'm confused by your comment about DNS requests...

    In Transparent mode, all DNS requests are made by the browser before the browsing request is sent through the UTM, and the Transparent Proxy makes none.  In this mode, the Transparent mode skiplists determine which traffic skips the Proxy.

    In Standard mode, the browser doesn't request name resolution, the Proxy does.  In this mode, the 'Exceptions' in 'Proxy Settings' in the Browser determine which traffic skips the Proxy.

    If the Default Profile is your only Profile and it is in Transparent mode, it will react as if in Standard mode if the browser sends a port 8080 request to the IP of "Internal (Address)" instead of resolving the FQDN itself and sending port 80 traffic to the website address.

    If 'Automatically detect settings' is selected in the 'LAN Settings' of the browser, it's likely that the browser is addressing the Proxy in Standard mode, so do not select 'Automatically detect settings' if you want to use Transparent mode.

    Cheers - Bob

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

    I'm confused by your comment about DNS requests...

    In Transparent mode, all DNS requests are made by the browser before the browsing request is sent through the UTM, and the Transparent Proxy makes none.  In this mode, the Transparent mode skiplists determine which traffic skips the Proxy.

    In Standard mode, the browser doesn't request name resolution, the Proxy does.  In this mode, the 'Exceptions' in 'Proxy Settings' in the Browser determine which traffic skips the Proxy.

    If the Default Profile is your only Profile and it is in Transparent mode, it will react as if in Standard mode if the browser sends a port 8080 request to the IP of "Internal (Address)" instead of resolving the FQDN itself and sending port 80 traffic to the website address.

    If 'Automatically detect settings' is selected in the 'LAN Settings' of the browser, it's likely that the browser is addressing the Proxy in Standard mode, so do not select 'Automatically detect settings' if you want to use Transparent mode.

    Cheers - Bob

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

    I said DNS, only because it is the first part of the process and the error comes back as the OP described.  I don't think DNS should be to blame, so I just manually changed the DNS to be google on the computer, and watched a custom firewall rule, and it did hit.  However, the browser still displayed this same message the OP posted even though the firewall rule just below the DNS rule, says to allow all outbound traffic from any port to any IP from any internal IPs.  It seems to happen when I add the computer to the transparent source skip list, or turn off the web proxy all together.  If I go with the transparent skip list, ALL ports that were covered by the proxy just seem to blackhole.  I can still RDC out of the house, but 80,81,8080,443 traffic goes to lala land.

    If I turn the proxy all the way off, in about 5 minutes, traffic starts flowing again (but makes the original problem that led me to discover this even worse).  If it is in the transparent skip list, it never came back in my testing EXCEPT if the website was open before the computer was added to the skip list.  If I have gmail open when I add the computer to the skip list, it gets new responses from Google just fine.  If I punch up speedtest_dotnet, it would time out and say host not found.  Some sites randomly worked but i think it is because they had keep-alives from advertising or other computers on the network.

    This is a weird one, and it was all set off for because stupid Blizzard changed their client and now it doesn't work with the UTM for the first time in years.  When I tried to debug their problem, things just got stranger and stranger.  All of their sites were already in exceptions, and most of their content delivery was in the destination skip list (why it was working the last 3 years).  Based on a brief investigation with Wireshark and Fiddler, I believe Blizzard is trying to use some TLS trickery to verify that you are a legitimate client.  Problem is, I see the traffic leave my computer, but I never see it at the UTM, so at some point in the process, the UTM is silently dropping these extra packets. They aren't showing as a default drop, and they won't display in any firewall, web proxy, or dnat created rule no matter how much I try.  I shouldn't be playing games anyway right now so I am dropping it, but to make this seem even weirder, the app worked better when I took the hosts out of the destination skip list.  It still failed, but it was further along in the process when it did.

     

    Sorry for the rambling, I have been up for 38 hours (The last 12 dedicated to this).

Unfiltered HTML