Troubleshooting Tip: Troubleshooting FortiGuard Web Filtering problems
This article gives basic advice and steps to follow when beginning to troubleshoot and resolve some of the most common FortiGuard issues.
FortiOS FortiGuard Web Filtering services. NAT or Transparent mode units.
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 22.214.171.124 0 28 1 1 0 0 126.96.36.199 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 188.8.131.52 0 28 1 1 0 0 184.108.40.206 0 29 1 1 0 0 220.127.116.11 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 18.104.22.168
# execute ping 22.214.171.124 PING 126.96.36.199 (188.8.131.52): 56 data bytes 64 bytes from 184.108.40.206: icmp_seq=0 ttl=50 time=17.3 ms 64 bytes from 220.127.116.11: icmp_seq=1 ttl=50 time=17.3 ms 64 bytes from 18.104.22.168: icmp_seq=2 ttl=50 time=17.3 ms 64 bytes from 22.214.171.124: icmp_seq=3 ttl=50 time=17.4 ms 64 bytes from 126.96.36.199: icmp_seq=4 ttl=50 time=17.4 ms --- 188.8.131.52 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
# exec ping google.com PING google.com (184.108.40.206): 56 data bytes 64 bytes from 220.127.116.11: icmp_seq=0 ttl=51 time=18.2 ms 64 bytes from 18.104.22.168: icmp_seq=1 ttl=51 time=18.3 ms 64 bytes from 22.214.171.124: icmp_seq=2 ttl=51 time=18.2 ms 64 bytes from 126.96.36.199: icmp_seq=3 ttl=51 time=18.2 ms 64 bytes from 188.8.131.52: 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 PING guard.fortinet.net (184.108.40.206): 56 data bytes 64 bytes from 220.127.116.11: icmp_seq=1 ttl=50 time=102.5 ms 64 bytes from 18.104.22.168: icmp_seq=2 ttl=50 time=104.2 ms 64 bytes from 22.214.171.124: icmp_seq=3 ttl=50 time=104.2 ms 64 bytes from 126.96.36.199: icmp_seq=4 ttl=50 time=104.2 ms 64 bytes from 188.8.131.52: 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