SSL Scanning Exception

Sounds like you ha e a firewall rule which is blocking the connecton when UTM is not involved.  If Web Proxy was blocking you, the error="" clause would not be empty.  

As far as I can tell UTM is involved as otherwise I wouldn't be seeing entries in the http logs for the SSL connection/blocking.  With my exception I only tried to deactivate SSL scanning  but not Category filtering, so I would expect the Web Proxy to still be involved in the establishment of the connection.

Having said that I will run a few tests later and check for any unexpected drops due to firewall rules.

Hi, Kenneth, and welcome to the UTM Community!

The first access is a CONNECT that wasn't allowed ("403"), but I don't see why.  How was user="kcronin" authenticated?  Is Google SafeSearch activated?

The second access is a successful GET, which makes me wonder why you want to skip 'Decrypt and scan' for this FQDN.

Cheers - Bob

Hi Bob,

The user kcronin is an eDirectory user and is Authenticated using eDirectory SSO. Google SafeSearch is not activated. I actually don’t want to skip 'Decrypt and Scan' for FQDN www.google.de, but am using it in order to test my rules.  I need the exception for a few Applications (Elster, UPS Worldship etc.) which have not being working properly since we activated Decrypt and Scan.  I have also tested the exception using other Domains but have had the same results.

Regards, Ken

Hi Douglas,

I ran a few test but have not detected any unexpected drops due to firewall rules. I even went as far as allowing my test client to directly access the internet.  This however made no change, as I still could not access the https pages when I manually activated the proxy in my web client.

Regards, Ken

Hi Kenneth,

The issue might be caused due to proxy as the first method to connect to the web proxy will be a connect request. What happens when you delete the conntrack for the source IP address and clear cache from the web browser?

Finally, give a restart to httpproxy. Take SSH to the UTM and execute, /var/mdw/scripts/httpproxy restart

Any help?

Hi Sachingurung

Unfortunately this didn't help. I'm still seeing the blocked web requests after following your advice.

Thanks, Ken

You certainly have a curious problem.   I have had no surprises with SSL exceptions.

I note that the URLs are not identical in your initial post.   One is explicitly connecting to https:, the other omits a protocol, which should mean that it tries to connect on http, after which Google will redirect it to https.  Do you have another rule which blocks uncenrypted HTTP traffic under certain circumstances?

It does not seem to be an authentication problem, because it has your userid and auth method in both entries, and the error code would be 407 (authentication required) instead of 403 (forbidden).

The other anomaly is that the destination IP is not in the log entry for the Connect.   A successful Connect is logged with ID=0003 and very little useful information, but I think the IP is included.  Could there be a DNS issue being exposed by this?  I think at this point you need a Sophos Support call.

I just spent the last hour or so troubleshooting this problem with our Sophos Reseller.  They couldn't find the cause of the problem but are going to open a Sophos Support Call for us.

I will post the results here.

Provide us some information about the network setup and which is the firmware version on the UTM. 

Thanks

We are running 2 SG450 in an Active-Passive HA with the latest firmware (9.413-4). 

The Proxy is running in Standard Mode, eDirectory SSO and block access on authentication failure is active. We have several different Web filtering Profiles configured, each with a different filtering Action. We use eDirectory groups in order to assign our users to a particular filtering policy. We also have a Transparent Proxy active from a number of defined systems.  We don't have https decrypt and scan active for the Transparent Proxy and my test system is not in the Transparent Proxy group.

Our end users have no direct connection to the Internet, they can only access it through the UTM Web Filter. Proxy Settings our obtained through a proxy pac file from the UTM.

Pharming Protection is active

Advanced Threat Protection is active

Application Control is active

I'm not too sure what other information maybe useful.

Your comment about internal pcs being isolated from the internet seems like the critical issue.

With scanning off, I think some portion of the exchange is being offloaded to the PC, which either cannot resolve dns names or cannot connect to the target.

Somebody who understands the inner workings of proxy logic will need to weigh in, but you should ensure that support undetstands how you restrict internet access.

Your comment about internal pcs being isolated from the internet seems like the critical issue.

With scanning off, I think some portion of the exchange is being offloaded to the PC, which either cannot resolve dns names or cannot connect to the target.

Somebody who understands the inner workings of proxy logic will need to weigh in, but you should ensure that support undetstands how you restrict internet access.