FortiGuard troubleshooting

The FortiGuard service provides updates to Antivirus, Antispam, IPS, Webfiltering, and more. The FortiGuard Distribution System (FDS) involves a number of servers across the world that provide updates to your FortiGate unit. Problems can occur both with connection to FDS, and its configuration on your local FortiGate unit. Some of the more common troubleshooting methods are listed here including

• Troubleshooting process for FortiGuard updates
• FortiGuard server settings

 

Troubleshooting process for FortiGuard updates

The following process are the logical steps to take when troubleshooting FortiGuard update problems. This includes antivirus (AV), intrusion protection services (IPS), antispam (AS), and web filtering (WB).

1. Does the device have a valid licence that includes these services?

Each device requires a valid FortiGuard license to access updates for some or all of these services. You can verify the support contract status for your devices at the Fortinet Support website — https://support.fortinet.com/.

2. If the device is part of an HA cluster, do all members of the cluster have the same level of support?

As with the previous step, you can verify the support contract status for all the devices in your HA cluster at the

Fortinet Support website.

3. Have services been enabled on the device?

To see the FortiGuard information and status for a device, in the web-based manager go to System > Config > FortiGuard. On that page you can verify the status of each component, and if required enable each service. If there are problems, see the FortiGuard section of the FortiOS Handbook.

4. Is the device able to communicate with FortiGuard servers?

At System > Config > FortiGuard you can also attempt to update AV and IPS, or test the availability of WF and

AS default and alternate ports. If there are problems, see the FortiGuard section of the FortiOS Handbook.

5. Is there proper routing to reach the FortiGuard servers?

Ensure there is a static or dynamic route that enables your ForitGate unit to reach the FortiGuard servers. Usually a generic default route to the internet is enough, but you may need to verify this if your network is complex.

6. Are there issues with DNS?

An easy way to test this is to attempt a traceroute from behind the FortiGate unit to an external network using the

FQDN for a location. If the traceroute FQDN name does not resolve, you have general DNS problems.

7. Is there anything upstream that might be blocking FortiGuard traffic, either on the network or ISP

side?

Many firewalls block all ports by default, and often ISPs block ports that are low. There may be a firewall between the FortiGate unit and the FortiGuard servers that is blocking the traffic. FortiGuard uses port 53 by default, so if it is being blocked you need to either open a hole for it, or change the port it is using.

8. Is there an issue with source ports?

It is possible that ports used to contact FortiGuard are being changed before reaching FortiGuard or on the return trip before reaching your FortiGate unit. A possible solution for this is to use a fixed-port at NATd firewalls to ensure the port remains the same. Packet sniffing can be used to find more information on what is happening with ports.

9. Are there security policies that include antivirus?

If no security policies include antivirus, the antivirus databse will not be updated. If antivirus is included, only the database type used will be updated.

 

FortiGuard server settings

Your local FortiGate unit connects to remote FortiGuard servers get updates to FortiGuard information such as new viruses that may have been found or other new threats. This section demonstrates ways to display information about FortiGuard server information on your FortiGate unit, and how to use that information and update it to fix potential problems.

 

Displaying the server list

The get webfilter status or diag debug rating command shows the list of FDS servers the FortiGate unit is using to send web filtering requests. Rating requests are only sent to the server on the top of the list in normal operation. Each server is probed for Round Trip Time (RTT) every two minutes.

You can optionally add a refresh rate to the end of this command and that will determine how often the server list will be refreshed.

Rating may not be enabled on your FortiGate unit.

get webfilter status

Sample Output:

Locale : english

License : Contract

Expiration : Thu Oct 9 02:00:00 2011

-=- Server List (Mon Feb 18 12:55:48 2008) -=-

 

IP	Weight	RTT	Flags	TZ	Packets	CurrLost	TotalLost
a.b.c.d	0	1	DI	2	1926879	0	11176
10.1.101.1	10	329		1	10263	0	633
10.2.102.2	20	169		0	16105	0	80
10.3.103.3	20	182		0	6741	0	776
10.4.104.4	20	184		0	5249	0	987
10.5.105.5	25	181		0	12072	0	178

 

Output Details

The Server List includes the IP addresses of alternate servers if the first entry cannot be reached. In this example the IP addresses are not public addresses

 

The following flags in get webfilter status indicate the server status:

• D – the server was found through the DNS lookup of the hostname. If the hostname returns more than one IP address, all of them will be flagged with D and will be 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 – means that 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 servers list received from the FortiManager is empty so the Fortimanager itself would be the only server known by Fortigate thus it should be used as the rating server.

The servers that are not currently serving will be pushed down to the bottom list (under the available serving servers, and on top of the failed servers) in order for the load-balance-servers feature in the config system fortiguard to work properly.

 

Sorting the server list

The server list is sorted first by weight. The server with the smallest RTT is put at the top of the list, regardless of weight. When a packet is lost (there has been no response in 2 seconds), it will be resent to the next server in the list. Therefore, the top position in the list is selected based on RTT while the other list positions are based on weight.

 

Calculating weight

The weight for each server increases with failed packets and decreases with successful packets. To lower the possibility of using a remote server, the weight is not allowed to dip below a base weight, calculated as the difference in hours between the FortiGate unit and the server times 10. The further away the server is, the higher its base weight and the lower in the list it will appear.