Troubleshooting Tip: Troubleshooting FortiGuard Web Filtering problems
Products
FortiGate v5.4
FortiGate v5.6
FortiGate v6.0
FortiGate v6.2
FortiGate v6.4
Description
This article gives basic advice and steps to follow when beginning to troubleshoot and resolve some of the most common FortiGuard issues.
Scope
FortiOS FortiGuard Web Filtering services. NAT or Transparent mode units.
Solution
Problems that may be encountered could include:
•    FortiGuard Webfilter is blocking everything
•    FortiGuard Webfilter is blocking nothing
•    Rating errors are displayed on every website
1st Step: Make sure the unit has a Valid Contract and Web Filter subscription

FortiGuard Web filtering is a subscription service.
If the subscription has expired FortiGuard web filtering will stop functioning and effectively give a rating error for every website accessed. 

If this is the case, technical support has no ability to alter contract details.
Contact Fortinet Customer Service department for issues regarding the contract status.


Test #1:  Is the service enabled? Make sure that at least one firewall policy has a Web Filter and SSL/SSH Inspection profile enabled

Run this CLI command in FortiGate CLI or Console in GUI:
# diagnose debug rating
Output sample (FortiOS 5.4 and 5.6):
# diagnose debug rating
Locale       : english
License      : Contract

-=- Server List (Wed Oct  9 16:25:34 2019) -=-

IP                     Weight    RTT Flags  TZ    Packets  Curr Lost Total Lost
62.209.40.73                0     28         1          1          0          0
62.209.40.72                0     29         1          1          0          0
Output sample (FortiOS 6.0 and 6.2):
# diagnose debug rating
Locale       : english

Service      : Web-filter
Status        : Enable
License      : Contract

Service      : Antispam
Status        : Disable

Service      : Virus Outbreak Prevention
Status        : Disable

-=- Server List (Thu Oct 10 10:53:55 2019) -=-

IP                     Weight    RTT   Flags  TZ    Packets  Curr Lost Total Lost
62.209.40.73             0       28            1          1         0          0
62.209.40.72             0       29            1          1         0          0
209.222.147.43          10        0     DT     0          4         2          2
If the output shows that the service is not enabled, create a firewall policy and enable Web Filtering inspection there. Then try the above command once again.

Flag Description:
•    D The server was found through the DNS lookup of the hostname.
If the hostname returns more than one IP address, all of them are flagged with D and are
used first for INIT requests before falling back to the other servers.
•    I The server to which the last INIT request was sent
•    F The server hasn't responded to requests and is considered to have failed
•    T The server is currently being timed
•    S Rating requests can be sent to the server
The flag is set for a server only in two cases:
1. The server exists in the servers list received from the FortiManager or any other
INIT server.
2. The server list received from the FortiManager is empty so the FortiManager is the
only server that the FortiGate knows, and it should be used as the rating server

If the output is similar, please proceed to Test #2.

Test #2: Can the FortiGate get to the Internet DNS by IP?

Pick an IP address of a publicly available DNS Server and ping it from the CLI of the FortiGate:
# exec ping 8.8.8.8
Output sample:
# execute ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=50 time=17.3 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=50 time=17.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=50 time=17.3 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=50 time=17.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=50 time=17.4 ms
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 17.3/17.3/17.4 ms
If this test fails: The problem is a routing issue, possibly on Fortigate or beyond. 
Troubleshooting must be done to find the source of the problem. 
This is a common problem when first installing the unit in transparent mode.


Note.
Some ISPs and networks block ICMP (ping) traffic.
This should be taken into account before considering the test to have failed.


If the Test is successful, proceed to Test #3.

Test #3: Can the FortiGate resolve FQDNs?

Pick random FQDNs and try to access them using ping test.  Make sure the unit can resolve host names. For example:
# exec ping google.com
Output sample:
# exec ping google.com
PING google.com (216.58.206.238): 56 data bytes
64 bytes from 216.58.206.238: icmp_seq=0 ttl=51 time=18.2 ms
64 bytes from 216.58.206.238: icmp_seq=1 ttl=51 time=18.3 ms
64 bytes from 216.58.206.238: icmp_seq=2 ttl=51 time=18.2 ms
64 bytes from 216.58.206.238: icmp_seq=3 ttl=51 time=18.2 ms
64 bytes from 216.58.206.238: icmp_seq=4 ttl=51 time=18.2 ms
--- google.com ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 18.2/18.2/18.3 ms
If this test fails: the problem is DNS related. 
Try using a different DNS server until this test can resolve.


Note.
Some ISPs and networks block ICMP (ping) traffic. 
This should be taken into account before considering the test to have failed. 
The important part of this test is that the unit successfully resolves an FQDN to an IP, not that the ping suceeds.


If the Test is successful, proceed to Test #4.

Test #4: Can the FortiGate resolve a specific host name?

In the default configuration the unit needs to be able to resolve “service.fortiguard.net”, “update.fortiguard.net” and “guard.fortinet.com” to an IP in order to have FortiGuard web filtering function correctly. From the command line on the FortiGate:
# exec ping service.fortiguard.net
# exec ping update.fortiguard.net
# exec ping guard.fortinet.net
Output sample:
# exec ping service.fortiguard.net
PING guard.fortinet.net (209.222.147.43): 56 data bytes
64 bytes from 209.222.147.43: icmp_seq=1 ttl=50 time=102.5 ms
64 bytes from 209.222.147.43: icmp_seq=2 ttl=50 time=104.2 ms
64 bytes from 209.222.147.43: icmp_seq=3 ttl=50 time=104.2 ms
64 bytes from 209.222.147.43: icmp_seq=4 ttl=50 time=104.2 ms
64 bytes from 209.222.147.43: icmp_seq=5 ttl=50 time=104.2 ms
--- guard.fortinet.net ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 102.5/103.6/104.2 ms
Note: Above mentioned FQDNs might not be pingable, it is an expected behavior.
Key point here is to see, if these FQDNs are resolved


If the test 4 fails, contact Fortinet Technical Support.

If the Test is successful, proceed to Test #5.

Test #5: Something in front of the unit is doing port blocking.

By default, FortiGate uses port 8888 as a destination port for Web Filtering communication with FortiGuard servers, and port range 1024-25000 as a source ports for self-originated traffic.
An alternative to port 8888 can be port 53. Source port range can be changed as well.


Some ISPs do compliance checks on port 53 and will block non-DNS standard traffic.

Some ISPs block port 8888, as it is a nonstandard port.

Some ISPs do port blocking based on the source ports that traffic originates on.

First, try to change Web Filtering port from 8888 to 53 in GUI (or from 53 to 8888, depending on the configuration).
Go to System -> FortiGuard, and under Filtering section change the port and press the Check Again button and then Apply to save the changes:





Starting from FortiOS 6.2.2, there is also an option to use HTTPS on ports 443, 53 or 8888 instead of UDP.
Try different combinations to see if any of them can work:




Alternatively, change the Fortiguard Web Filtering Port in CLI the following way:
# config system fortiguard
(fortiguard) set port 53
(fortiguard) end
In case changing the Web Filtering port cannot solve the problem with Web Filtering, try to change the source port range for self-originated traffic:
# config system global
(global) set ip-src-port-range 1031-4999
(global) end
# diagnose test application urlfilter 99
Double-check with the ISP to confirm there is absolutely no port blocking going on.
With many ISPs that claim not to be doing port blocking, changing the source port of the Firewall information (ip-src-port-range) corrects this issue.
Starting from FortiOS 6.4, by default it use HTTPS on ports 443. In order to change the port/protocol please follow the below CLI configuration.
# config system fortiguard
    set fortiguard-anycast disable
By disabling anycast settings it will be possible to view the  options to select the protocol and port.
Last Modified Date: 04-12-2021 Document ID: FD30088