User able to access site that should be blocked on ProxySG or Advanced Security Gateway

Products

• Advanced Secure Gateway Software - ASG
• ProxySG Software - SGOS

Issue/Introduction

You have put in user-based Policy rules which should have denied access to a user, but the user still has access to blocked sites using ProxySG or Advance Security Gateway (ASG).

Resolution

To start troubleshooting and getting to a root cause of a situation like this, it's best to start with a policy trace from the ProxySG or ASG.

This article discusses how to collect a policy trace and use it to troubleshoot access issues. See Use policy trace to debug access issues

To determine why a user has access to a blocked site have the user go to the site and collect a policy trace from the ProxySG or ASG. Review the policy trace and see whether or not the blocking rules are matching or subsequent rules. Make changes to policy using the above information and repeat testing until the user is blocked.

There are many reasons a user may still have access to sites which should be blocked, such as the site includes a full path, but the site is also an HTTPS site. In which case, the ProxySG or ASG may allow the request if SSL interception is not enabled.

See Can the ProxySG inspect entire HTTPS URL's when SSL interception is not configured? 

See HTTPS request being allowed/denied incorrectly after implementing SSL Intercept in Explicit Proxy Deployment

Another possible reason is that a subsequent policy layer allowed access even though a previous layer blocked the site. The general rule for policy is that the first rule of the last policy layer to match will be the final decider.  To override this behavior, you can use the policy gesture "Force". See In ProxySG Policy what is the difference between Deny and Force Deny?