Site which should be blocked URLF not being blocked after SSL decryption

[AndrewCraick]

We are blocking a particular category of URLs (say gambling). When we access the unecrypted site it is blocked as expected. When we add https to the URL and browse we are not blocked.

I can see in the logs that access is allowed by the FW, even though it hits a rule with a URLF profile that should block the category. The category for the SSL connection is also correctly listed in the logs indicating that after decryption the site has been identified correctly by URLF.

I can confirm that the site is being decrypted because the certificate presented has been signed by the root CA configured in the SSL VPN.

Any idea's why this might be the case. Version 6.1.7.

Thanks

[bmorris1]

Hey Andrew,

Do you mind sharing the website you are browsing to? Or the logs of the issue? I can't say for sure what the cause of the behaviour is at the moment.

thanks,

Ben

[AndrewCraick]

Sure. The web sites are https://www.ladbrokes.com.au and https://www.sportsbet.com.au. Let me hit you up with logs shortly. They dont show much. They just show an allow on the category which should be blocked. they include the rule which is linked to a URLF profile which should block this category.

[AndrewCraick]

Log entry.

[gwesson · Accepted solution]

The action of a security rule will be allow, but the URL filtering log will show the block (if it is blocked). Technically the traffic was allowed, and only when everything was determined would it be blocked.

When you click the magnifying glass on that, it should have related logs which include URL filtering logs. Alternatively, you can pull up the same query in the URL filtering logs and it should show you what the verdict was.

Cheers,

Greg

[AndrewCraick]

Problem solved guys.  I did a session with support. The traffic wasn't hitting the rule i suspected (i didn't review the log files thoroughly enough).

The sites were  switching to SSL over port 80. This meant the URL rule that specified Application default did match the SSL traffic on port 80. I had to manually add services for 80 and 443 to the URLF rule to ensure that the site would hit the correct rule.