When troubleshooting issues with the web filtering tool on the FortiGate, there are a number of things to consider. This post will hopefully assist you with getting to the cause of the issue if you encounter problems with Web Filtering.
Firstly, we must consider the 3 modes of operation with web filtering on the FortiGate; these are:
Proxy-Based (SSL Inspection Optional)
This is the most resource intensive and most accurate mode of operation. The FortiGate will proxy the connection, by that I mean it will maintain a connection with the user that requested a particular website, and it will also maintain a connection with the web server hosting the website. All traffic is buffered on the FortiGate to be inspected meaning it can also be cached to save on bandwidth. This mode allows content filtering, meaning you can inspect the content of a given website to determine if it should be blocked.
Flow-Based (SSL Inspection Optional)
Flow based inspects traffic as it passes through the FortiGate without buffering, meaning it’s much quicker; this also means it cannot cache content and cannot do all the advanced features available in proxy mode.
This is the least resource intensive but also least accurate method of inspection. It works by intercepting the DNS lookup for a website and running this against FortiGuard to determine the URL categorisation of the requested website. It is at this point the connection is dropped or the user is redirected to the block page. This mode is very limited on the available feature set.
Once you have determined the operating mode, we now need to think about SSL Inspection, and what limitations this has with Web Filtering.
This feature is to allow the FortiGate to either inspect or block traffic over HTTPS. There are two methods to do this, certificate inspection and deep packet inspection. The latter method being the most in depth and resource intensive.
With certificate inspection, the FortiGate relies inspection of the certificate of the website. It will inspect the hostname of the certificate to determine the rating and block or deny accordingly. This is less resource intensive that deep inspection.
This method requires you to install an accepted certificate on the FortiGate, or accept the FortiGates default certificate. The firewall maintains the connection between the HTTPS server and itself, then presents its own certificate to the client requesting the webpage, inspecting the traffic after it has been decrypted. This is the most resource intensive method of SSL Inspection.
The following are commands that you may find useful whilst troubleshooting Web Filtering on a FortiGate.
Lab-FG # diagnose webfilter fortiguard statistics list
This will show you a list of statistics relating to web filtering.
Lab-FG # diagnose debug urlfilter src-addr <source-IP>
Lab-FG # diagnose debug application urlfilter 255
Lab-FG # diagnose debug enable
This will provide you with a flow-like output, displaying useful information such as:
- Requested URL and destination port
- Web filter profile applied to the traffic
- Source of the request (client)
- Whether or not the page has already been cached
- Which category the site falls under (number ID)
- The destination IP address
Lab-FG # get webfilter categories
With the above command, you will be able to see a list of the categories and their corresponding ID numbers.
Hopefully this will provide you with some basic tools to get to the cause of any issues you encounter with Web Filtering on the FortiGate.