So... why are NVIDIA drivers suddenly taboo to download?

As does mine, however my original post for downloading shows otherwise, because it's from download.nvidia.com, which does get categorized as Shareware... which its not at all.

I'm still just reeling on the fact that I can add a URL category to completely bypass a top list firewall rule, and something as trash as Shareware at that...

This is getting stupid.

I tried to download a driver.

As you said the test for download.nvidia.com returns shareware.

Ian

Classified as Executable files.....

For that error to occur, you must have HTTPS inspection enabled with .EXE or .MSI as a blocked filetype.

So then it looks like webfilter exceptions override firewall rules? I remember this happening with the UTM too. It just must have to do with the flow of how data is inspected.

I'm not going to lie to you, the firewall is very tricky to configure and I spend a lot of time trying to figure things out with multiple ways of accomplishing the same thing. 

Have you tried my method, of changing the category of downloads.nvidia.com from Unacceptable to Acceptable? This essentially overrides the shareware & freeware categorization block for that downloads.nvidia.com driver. But if the exception worked, then it worked. It would be good to see some more screenshots to be sure.

Either change the category from Unaccptable to Acceptable, or this exception should be all you have to do: something similar to this...

Yes,I do, but the point is the site is classified and blocked as share ware etc.

Ian

rfcat_vk said:

Yes,I do, but the point is the site is classified and blocked as share ware etc.

Underneath where it says > about this request

What does it say then you click on it?

Amodin said:

So trying to figure this out again, I get a notification of another download for drivers.  I created a web exception in my Safe Downloading exceptions list which I add a regex entry for ^([A-Za-z0-9.-]*\.)download\.nvidia\.com/ and try again.

I think your regex might be formatted incorrectly. According to the online giude, it looks like it should be this

^[A-Za-z0-9.-]*\.download\.nvidia\.com/

and not...

^([A-Za-z0-9.-]*\.)download\.nvidia\.com/

Let me explain what is happening.

If you have a Firewall Drop rule, SFOS will do a trick to show you the blockpage in the browser and not the "connection timeout" by the Proxy. This is a feature to show the user what is going on. On other products, you will get a browser error like the dino in Chrome. In SFOS, we allow the traffic by the firewall and forward it to the proxy. The proxy will throw the block page. That is only possible, if the browser reaches the packet and the firewall will not deny it. 

See: https://doc.sophos.com/nsg/sophos-firewall/19.5/help/en-us/webhelp/onlinehelp/AdministratorHelp/Logs/LogViewer/Logsbehavior/index.html#firewall-action-and-logs

You could change that by using Reject internally (so the firewall rejects the packet, everything is as usual).

BTW: SFOS does it only for internal to external. 

If the proxy does this block page, it also evaluates the exception list. Means, you can allow certain traffic based on your exception, even if you have a block page criteria. 

LuCar Toni said:

If the proxy does this block page, it also evaluates the exception list. Means, you can allow certain traffic based on your exception, even if you have a block page criteria. 

So does that explain why the Amodin was able to finally download the nvidia driver from China (which is GeoIP blocked in his firewall rules) from a China-based CDN server? 

Only if the CDN block is part of your access rule, if it is a rule at the top of your list then the proxy would never know about it.

Ian

Just follow-up, it didn't work on the regex change.  Also, I copied my regex from Sophos XG from a built-in existing regex entry on their own list, I just changed it for NVidia.