FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
ppatel
Staff
Staff
Article Id 196965

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. 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 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:

 

  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, 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 the 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.


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 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

exec ping securewf.fortiguard.net (HTTPS)
exec ping usservice.fortiguard.net(UDP - USA servers)
exec ping ussecurewf.fortiguard.net (HTTPS - USA servers)

 

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: The above-mentioned FQDNs might not be pingable, it is an expected behavior.
The 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 port for self-originated traffic.
An alternative to port 8888 can be port 53. The 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 the Web Filtering port from 8888 to 53 in GUI (or from 53 to 8888, depending on the configuration).
Go to System -> FortiGuard, and under the Filtering section change the port 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:
 
 
 
 
Note: An increase in one of the error counters from the below command indicates communication problems with FortiGuard too.
 
diag webfilter fortiguard statistics list
 
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 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 uses HTTPS on port 443. To change the port/protocol, 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.

Another possible cause is that the web-filter service is disabled. To verify this, use the command 'diagnose debug rating'.

rating disable.PNG

To enable web-filter service, use the following command:
 
config system fortiguard
    set webfilter-force-off disable
end
 
After that, check the rating service again and the web-filter should be enabled.
 
Below is a list of additional webfiltering commands, illustrating how URLs are categorized and processed.
 
  • 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 webfiltering cache dump:

diagnose webfilter fortiguard cahce dump

 

This command shows the FortiGuard category ID in hexadecimal for each URL/IP.

 

  • List all the categories with respective ID numbers:

get webfilter categories