Web Filtering: Default Content Filter Action

Firewall rules and Web Filtering are mutually exclusive paths through the device, so the rule is not working because it is not being evaluated.   (Review the articles in the WiKi section and the articles pinned to the top of the Web Filtering forum for valuable information on Web Filtering).

If you have Standard Mode enabled, the proxy configuration needs to be pushed to your clients, typically using Active Directory Group Policies.

For either mode, you need to ensure that the "Allowed Networks" list on your filter profile includes all of the IP ranges that are supposed to use web filtering.

For both modes, you should also push out the UTM root certificate, so that block/warn pages will display correctly.

Ah! That pointed me to the right paragraph in the docs. Thanks! I'm using it in Transparent mode, which ignores https traffic, which many of these sites are.

The docs say "The disadvantage however is that only HTTP requests can be processed. Thus, when you select the transparent mode, the client's proxy settings will become ineffective." but the box "Do not proxy HTTPS traffic in transparent mode" is uncheckable, so I'm wondering either...

why does the documentation not say it "OPTIONALLY does not proxy traffic"

or

Is it bad to uncheck this box, why it's bad, more importantly, why it's uncheckable if it is?

I may also one confused about the above statement as I'm not sure what "only HTTP requests can be processed" has to do with what my proxy settings are, especially when I haven't set any.

Thanks,

Jeff

I am unsure what you read, but I think you misunderstood.

Transparent Mode Web Filter intercepts traffic on port 80 and 443 as it flows through the device on its way to the internet.   However, it only filters traffic from sources identified in the "Allowed Networks" list of your enabled Filter Profile.   If that traffic is going through the Firewall Rules, then the Filter Profile is not on or the Allowed Networks list does not include your source device.   A common beginner mistake can be to leave the list empty.   Typically it should include all of your internal addresses, so that all of your outgoing web traffic is filtered.   Then you can adjust the list if something requires a bypass.   So if your traffic is being blocked by Firewall Rules, you need to find out what's wrong with your Filter Profile definition.

When Transparent Mode Web Filter is enabled, it is a good idea to enable the Transparent Mode FTP Filter for the same "Allowed Networks" addresses, to filter port 21 traffic is well.   These two transparent filter expect traffic on standard ports:  http only on port 80, https only on port 443, and ftp only on port 21.  I expect they will block traffic that uses a non-standard protocol on those ports.

Standard Mode Web Filter processes everything that the web browser sends to it, but the client device must be configured for Standard Mode Proxy so that can happen.   Standard Mode sees the URL, so it determines the expected protocol from the URL prefix rather than from the port number.   It filters http, https, and ftp.   Custom protocols, such as "httX://" will be blocked.   Traffic on non-standard ports will be blocked until the system administrator allows them in the "Allowed Target Services" list of the "Misc" tab.

Because Standard Mode handles non-standard ports, and Transparent Mode handles traffic that does not come from a cooperating web browser, the most complete protection occurs when you are using both modes.   But for home use, transparent mode is probably sufficient.

Limitations of https filtering:

HTTPS inspection ("decrypt and scan") intercepts the traffic, decrypts it, checks it, and then starts a session with the target server on behalf of the client device.    I do not recommend this for home users.   When it is not enabled, UTM can only see the protocol and FQDN portion of the URL, the path and querystring are hidden in the encrypted part of the packet.   UTM can only filter on what it can see, so you cannot block on the path portion of a web address if the protocol is https and decrypt-and-scan is off.    I have not found much need to filter on the path or querystring, so this limitation has not bothered me.   There are also complications related to identifying packets to a specific user, but this is only of interest to people using Single SignOn with Active Directory.  What you read is probably related to these limitations.