Description
This article describes 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 Web filter is blocking everything.
- FortiGuard Web filter 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 cannot alter contract details.
Contact the 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, and ensure webfilter-force-off is disabled in 'config system fortiguard'.
config system fortiguard
set webfilter-force-off disable
end
After ensuring the service is enabled on a firewall policy and in FortiGuard settings, collect the 'diagnose debug rating' again.
Flag Description:
- D The server was found through the DNS lookup of the hostname. If the lookup 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 has not 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:
- The server exists in the servers list received from the FortiManager or any other INIT server.
- 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, 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:
execute 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 the ping test. Make sure the unit can resolve host names. For example:
execute ping google.com
Output sample:
execute 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.
The important part of this test is that the unit successfully resolves an FQDN to an IP, not that the ping succeeds.
If the Test is successful, proceed to Test #4.
Test #4: Can the FortiGate resolve a specific hostname:
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 address for FortiGuard web filtering to function correctly. From the command line on the FortiGate:
execute ping service.fortiguard.net
execute ping update.fortiguard.net
execute ping guard.fortinet.net
execute ping securewf.fortiguard.net (HTTPS)
execute ping usservice.fortiguard.net(UDP - USA servers)
execute ping ussecurewf.fortiguard.net (HTTPS - USA servers)
Output sample:
execute 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:
The IP addresses resolved by DNS lookup might not be reachable, this is expected behavior. The key point is that FQDNs are resolved.
If the test fails, troubleshoot why the DNS lookup is failing and verify the FortiGate has correct system DNS settings such as source-ip if required. See the article 'How to control/change the FortiGate source IP for self-generated traffic'.
If the test is successful, proceed to Test #5.
Test #5: Is an upstream device blocking Web Filter requests:
- Some ISPs do compliance checks on port 53 and will block non-standard DNS traffic.
- Some ISPs block port 8888 as a nonstandard destination port.
- Some ISPs do port blocking based on the source ports that traffic originates on.
By default, FortiGate uses UDP port 8888 as a destination port for Web Filtering communication with FortiGuard servers, and port range 1024-25000 as a source port for self-originated traffic. Port 53 is another. The source port range can be changed as well.
If the other tests have succeeded, verify if there is any response back from the FortiGuard server showing in a packet sniffer.
VAN-EDGE-A # get system fortiguard | grep port
port : 8888
sdns-server-port : 53
proxy-server-port : 0
ddns-server-port : 443
VAN-EDGE-A # diagnose sniffer packet any 'port 8888' 4 100 l
interfaces=[any]
filters=[port 8888]
2024-12-10 15:20:07.640962 wan1 out 10.133.200.1.1333 -> 208.184.237.61.8888: udp 72
2024-12-10 15:20:07.641002 wan1 out 10.133.200.1.1333 -> 208.184.237.62.8888: udp 72
2024-12-10 15:20:07.641033 wan1 out 10.133.200.1.1333 -> 12.34.97.71.8888: udp 72
2024-12-10 15:20:07.641062 wan1 out 10.133.200.1.1333 -> 140.174.22.71.8888: udp 72
2024-12-10 15:20:07.641092 wan1 out 10.133.200.1.1333 -> 140.174.22.72.8888: udp 72
2024-12-10 15:20:07.641121 wan1 out 10.133.200.1.1333 -> 12.34.97.72.8888: udp 72
2024-12-10 15:20:07.641148 wan1 out 10.133.200.1.1333 -> 140.174.22.73.8888: udp 72
2024-12-10 15:20:07.641178 wan1 out 10.133.200.1.1333 -> 12.34.97.73.8888: udp 72
2024-12-10 15:20:07.641206 wan1 out 10.133.200.1.1333 -> 12.34.97.74.8888: udp 72
2024-12-10 15:20:07.641235 wan1 out 10.133.200.1.1333 -> 12.34.97.75.8888: udp 72
2024-12-10 15:20:09.350899 wan1 out 10.133.200.1.1333 -> 208.184.237.61.8888: udp 99
<--- no response back from any FortiGuard server, an indication that port might be filtered by an upstream device.
If the port is potentially filtered, change the ports used for web rating.
Starting from v6.2.2, there is an option to use HTTPS on ports 443, 53, or 8888 instead of UDP.
Starting from v6.4, Web Filter uses HTTPS on port 443. To change the port/protocol, follow the below CLI configuration.
config system fortiguard
set fortiguard-anycast disable
end
After disabling fortiguard-anycast, it is possible to select transport protocol and port.
config system fortiguard
set port 53
end
If different destination ports show no response in the packet sniffer, the source port may be filtered. While many ISPs claim not to be doing port blocking, changing the source port FortiGate uses for its requests (ip-src-port-range) can sometimes correct this issue.
config system global
set ip-src-port-range 1031-4999
end
Additional Web Filter diagnostic commands:
- FortiGuard web filtering real-time debug:
diagnose debug urlfilter test-url <url>
diagnose debug urlfilter src-addr <source_IP>
diagnose debug application urlfilter -1
diagnose debug enable
- FortiGuard web filter rating cache dump:
diagnose webfilter fortiguard cache dump
Caution: This command is for diagnostic purposes ONLY. The bigger the cache size is set, the more impact on performance the command has.
Do you want to continue? (y/n)y
Saving to file [/tmp/urcCache.txt]
Cache Contents:
-=-=-=-=-=-=-=-
Cache Mode: TTL
Cache DB Ver: 234.885
Rating DB Ver DOT SLASH ORIG_FLAG T URL
00000000|00000000 234.0885 1 0 00000001 P Ahttp://0.0.0.0/
34000000|34000000 234.0885 1 0 00000001 P Ahttp://fortinet.com/
This command shows the FortiGuard category ID in hexadecimal for each URL/IP. For example, 0x34 is 52 in decimal, so 'fortinet.com' was resolved as 'Information Technology'.
- List all the categories with respective ID numbers:
get webfilter categories
- Restart the webfilter service if needed.
diagnose test application urlfilter 99
Note:
Starting from v7.4.1 GA, FortiGuard web filter categories for AI and cryptocurrency have been added:
- Artificial intelligence technology (category 100): sites that offer solutions, insights, and resources related to artificial intelligence (AI).
For example, deepl.com. - Cryptocurrency (category 101): sites that specialize in digital or virtual currencies that are secured by cryptography and operate on decentralized networks.
These two categories are set to ALLOW by default in 'FortiGuard Category Based Filter': ensure it is enabled/disabled appropriately in the web-filtering profile intended for filtering AI and/or Cryptocurrency websites.
Related Article:
Troubleshooting Tip: WebFiltering not working - The service is not enabled
