Disclaimer: This information is posted as-is and the content should be referenced at your own risk

Given the number of questions along these lines, I decided that it was time to write up some troubleshooting guidelines. 

First, let me say that after several years of working with UTM Web Filtering, the product works pretty reliably.   If it appears to be doing something really weird, you should assume that the issue is in your configuration until you can prove otherwise.   Hopefully, this script will help you solve your problem or develop your proof.

The troubleshooting process is pretty similar whether your complaint is:

• “traffic getting through when it should be blocked”,
• “traffic getting blocked when it should get though”, or
• “web page opens but does not look or behave as expected”

Understand the Architecture

UTM is a collection of mutually-exclusive packet filters.   If a packet is processed by the web filter, it is not processed by any firewall rules.   A packet will only be processed by the firewall rules if all of the specific purpose proxies are bypassed.   That may not be how you want the product to work, but it is how it does work.

UTM is directionless, so it does not know that you want to block traffic from the DMZ to the Internal network.   It only knows that you have traffic on interfaces A0, A1, and A2.   You have to create the rules to block unwanted traffic.   Because each proxy works independently, you prevent DMZ-to-Internal traffic by configuring blocks in the web filter proxy, in the firewall rules, and possibly elsewhere.

Create a Firewall Rule to Block UDP port 443

Chrome has a QUIC protocol that handles https sessions over UDP 443 instead of TCP 443.   It will try to bypass the webfilter.   To ensure that Chrome traffic can be handled by your web filter, create a firewall rule to block UDP port 443.   This will force it to use TCP port 443, which both web filter operating modes will detect and handle.

In Standard Mode, you can enable QUIC by adding UDP 443 to the Allowed Services list.   In Transparent Mode, there is no way to make it detect UDP 443.

Deploy the UTM CA Root Certificate

UTM needs to impersonate the remote web server (a) whenever either filter mode needs to send a block or warn page for an https site, and (b) whenever Standard Mode Web filters an HTTPS page.   There is a common assumption that Transparent Mode is easier because you do not need to distribute the root certificate.   This is wrong.   If you do not distribute the certificate, you will see "server not trusted" warnings in your browsers. 

Note that when the root certificate is exported, it includes the private key.   You do not want to distribute this version of the certificate because it allows any PC to become a certificate issuer.   Instead, import the certficate onto one PC, then export it back out without the key.   Then distribute that version of the key to your desktops.   In an Active Directory environment, this is done pretty easily with Group Policy.   For business networks with a mix of Active Directory and disconnected devices, you might want to evaluate the third-party product PolicyPak.  For home networks, certificate distribution is probably a manual task, and may not be possible for some devices, such as televisions.

Find the Traffic

Web pages will do many unexpected things, so you have to evaluate all of the traffic to find the problem.   You really need two PCs to do testing:   one to access the web page, and one to monitor the live logs.  If you use one PC for both, the Live Log updates will appear in the logs.

Before starting, determine the IP address of the client device.   Open the web filtering live log and enter the client IP address in the filter box, followed by the enter key to activate it.   The log always populates with some initial traffic, which can be ignored.   You want to watch for the new traffic, which will be limited by the filter rule.

Initially, the web filter live log may be sufficient.   In some cases, you may need the Firewall, Application Control, and IPS live logs as well.

Review All of the Traffic

A novice may assume that when investigating “example.com”, he only needs to watch for traffic to “example.com”.   In reality, most web sites include content from many unrelated sites.  You will also see overhead activity as the browser verifies certificate integrity.

Start by verifying that the traffic appears in the web filter log.  If not, then look for the traffic in the Firewall log, and begin assessing why the web filter was bypassed.  

Next, check the filterprofile=”name” and policy=”name” entries in the event log to verify that the packet was handled by the webfilter configuration elements that you expected.  The Filter Action name is not in the log files, because it is uniquely determined by the Filter Profile and Policy.  If these values are not as expected, review the selection rules to determine what went wrong.

Traffic blocked when allowed was intended

If the problem is blocked traffic, look for log entries that indicate action=”block”.   Check for the name=”text”, which will explain blocks caused for category, country, or application.  Check statuscode=”<code>” and look up the meaning of the HTTP error code.   Also check error=”text” for additional information.   If the log entry indicates error=”” (empty string), it usually indicates a certificate verification problem in Standard Mode.

If the error is Host Not Found, research whether the machine really is offline or if you have blocked access to it as a result of an address-based blocking rule.    In Standard Mode, a DNS problem can cause a Host Not Found error to appear in the logs.  In transparent mode, DNS resolution occurs at the client, so DNS errors will not produce a log entry because no web packet will be ever sent toward UTM.

If there is a timeout error, the packet may have been allowed by Web Filter but the response may have been blocked by the Intrusion Protection System.   Check the IPS log.   The IPS event may be as much as two minutes earlier than the Web Filter timeout event.

Traffic allowed when blocked was intended

Review which rule was expected to block the traffic, and compare it to the web log.   Remember that web log traffic is only blocked by web filter rules, and outbound non-web traffic is typically blocked by firewall rules.

For expected category blocks, see if the category assigned is what you expected.   For expected country blocks, see if the country assigned is what you expected.   For application blocks, see if the application block is what you expected.

Differences between Transparent and Standard Mode

Transparent Web Proxy only blocks port 80 and 443.  It can be combined with Transparent FTP proxy to handle port 21.   Any non-standard port will bypass the web filter and be evaluated only be the Firewall Rules.   DNS occurs on the client before the web request is attempted/

Standard Mode asks UTM to fetch the page on behalf of the client.  DNS resolution occurs on the UTM.   UTM will see all web traffic, including non-standard ports, but by default it will block traffic for ports other than 80, 443, and 21.   When a non-standard port is blocked, it will appear in the Web Filter log.   The port can be allowed by adding it to the Allowed Services list within the Web Filter configuration.  Remember that the Allowed Services list only applies to Standard Mode, and it applies to all websites.

Differences with HTTPS Inspection enabled or disabled

If decrypt-and-scan is off, UTM only creates one log entry, for method=”CONNECT”, at the end of the session.   If decrypt-and-scan is on, UTM creates one log entry for each web request.   Turning this feature on and off can be useful for debugging HTTPS sites.

Check for Dual Sessions

Many streaming applications and remote access applications use two sessions, one on HTTPS for authentication, and one on a non-standard port after authentication.   In transparent mode, the first session will be in the web log and the second session will be in the firewall log

Enable Firewall Traffic Logging

By default, the firewall only logs blocked traffic.   To ensure that all of your test traffic is logged, create a firewall rule with source=test_client_ip, Allow=All, and Logging=On.   Place it immediately before the firewall rule to allow all outbound traffic.   There may be other firewall rules that need to have logging enabled as well