Blocked Web Filter category not showing in web filter log

Hi,

Are all devices on the same LAN?

please check there application log.

Ian

Hi, yes all devices are on the same LAN.

I just tested again.  When the "Radio & Audio Hosting" is removed from the "Bandwidth-heavy Browsing" I can see the traffic allowed in the Web Filter Log.  

When I add the "Radio & Audio Hosting" block back again, there is nothing reported in either the Web Filter or Application filter logs related to that category.  192.168.9.75 is the Google Mini - the "Mobile Applications" block is normal, there are loads of them over the last few days since I set up the Firewall, they still appear even when the "Radio & Audio Hosting" block is removed and casting is working normally.

Web Filter

Application Filter

Hi,

with the devices all being on the same LAN the switch will do the traffic routing and nothing will get the firewall, hence nothing in the logs.

Ian

Thanks, however, I know typical "casting" is contained locally but there is something else going on here.  When I cast there is still some traffic sent out to the internet from the Google Mini to Spotify CDN servers, I can see that in the logs as per the screenshot above.  I believe spotify is doing some kind of handoff to the mini as once I have "casted" I can turn my phone off and it continues to play my spotify playlist.

Despite how casting/spotify should work, it is easily repeatable, remove the block above and spotify/casting works and I see allowed traffic in the log.  Block it and casting stops working and I don't see anything blocked in the logs.  The Mini is clearly relying on talking to the internet for something during the process and i'm expecting to see something blocked in the log which I don't?

Probably going down a rabbit hole I don't need to and I have a fix but i'm more concerned there is a bug that isn't showing blocked traffic in the log?  30+ years working with various firewall vendors i'd expect to see it somewhere?

Hi,

more than likely it is a secure connection that does not like being scanned. The connection has been established and corrupted by the scanning process.

ian

Yeah ok thanks Ian.  So basically probably "normal" behavior and an unusual case?  Just makes troubleshooting hard when you don't see things like this in logs and i'd expect to at least see something in logs.  I had to use trial and error to narrow it down.

Thanks for your help!

The firewall would not know th packet had been corrupted, only the receiving device would be able to determine the status of the packet. So you would not expect to seen any failures in the logviewer.

Ian

Thanks Ian, still sounds a little strange to me.  I'm not doing any HTTPS inspection and in all my years as a network engineer i very rarely see a packet just disappear without any evidence anywhere.  I spun up wireshark and had a look and even when the blocking policy is in effect I can still see traffic trying to get out however decided to leave it there and not go down that rabbit hole. 

Thanks again for your help!  First post here, if there is something I should do to close this out let me know.

If anyone else has a Google home Mini, Spotify and more time than me it's very easy to replicate.

Cheers!

If you are using SSL/TLS then you are scanning according to your web policies etc.

If you are satisfied then the you leave the thread as it is or if the thread has been answered you tick verify answer in th more menu.

Ian