Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 9 replies
  • Subscribers 3 subscribers
  • Views 21210 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

Policy helpdesk shows allowed, but still blocked

Chris pounds

Hi, 

I'm trying to allow staff to upload images to prezi.com, which they were previously able to do, i have had a look at the web log and the only block i can see is from https://s3.amazonaws.com/0103.static.prezi.com Which i have allowed. I have also tested on Policy Helpdesk and it reports them being able to resolve and access the URL. But when i check the logs, they are still being blocked. 

 

Any ideas at all? They are under the right tag, otherwise policy helpdesk would report blocked right? Any help would be greatly appreciated! 



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

    Hi, Chris, and welcome to the UTM Community!

    Please show the line from the Web Filtering log file where this URL was blocked.

    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

    Hi Bob, 

    Thank you! It seems the rule i put in for s3.amazon has taken, but since last test another URL has come up as blocked.

     

    2017:04:28-08:34:41
    		 ********
    172.20.3.99
    pass
    ---
    2017:04:28-08:34:41
    		 ********
    172.20.3.99
    block
    ---

    It seems to be allowing the above address, which is the same as the blocked URL for all but the last part. I have allowed prezi.com with all subdomains, strange that it's blocking /xhr_streaming?

  • 0 in reply to Chris pounds

    If you are using https inspection, there are a bunch of certificate issues that can cause a site to be blocked:   root certificate in chain, intermediate certificate missing, certificates out of order, wrong server certificate (often a cloud service which enables port 443 for everything whether the client needs it or not),  DNS synonym that was not included in the certificate, expired certificate, and inappropriate wildcard use (trying to cover two levels with one *).   This show up in the logs with an empty string in the error="" clause.

    Similarly, with https inspection, you can be blocked if the server does not support TLS 1.2

    Both of these can be tested using the server test option at ssllabs.com, or an equivalent one provided by most certificate issuing services.

    Of course, since Chrome 58 was released, you should probably be running with HTTPS inspection disabled.

    For any other error, we need the statuscode="" and error="" clauses from the log entry, and I don't see that information in what you provided.   If the site was blocked for something other than a certificate problem, you should have useful information in the error="" clause.

Reply
  • 0 in reply to Chris pounds

    If you are using https inspection, there are a bunch of certificate issues that can cause a site to be blocked:   root certificate in chain, intermediate certificate missing, certificates out of order, wrong server certificate (often a cloud service which enables port 443 for everything whether the client needs it or not),  DNS synonym that was not included in the certificate, expired certificate, and inappropriate wildcard use (trying to cover two levels with one *).   This show up in the logs with an empty string in the error="" clause.

    Similarly, with https inspection, you can be blocked if the server does not support TLS 1.2

    Both of these can be tested using the server test option at ssllabs.com, or an equivalent one provided by most certificate issuing services.

    Of course, since Chrome 58 was released, you should probably be running with HTTPS inspection disabled.

    For any other error, we need the statuscode="" and error="" clauses from the log entry, and I don't see that information in what you provided.   If the site was blocked for something other than a certificate problem, you should have useful information in the error="" clause.

Children
No Data
Unfiltered HTML