FortiGuard troubleshooting
The FortiGuard service provides updates to AntiVirus (AV), Antispam (AS), Intrusion Protection Services (IPS), Webfiltering (WF), and more. The FortiGuard Distribution System (FDS) consists of a number of servers across the world that provide updates to your FortiGate unit. Problems can occur with the 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
The following process shows the logical steps that you should take when you troubleshoot problems with FortiGuard update:
- 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 status of the support contract for your devices at the Fortinet Support website.
- If the device is part of a high availability (HA) cluster, do all members of the cluster have the same level of support?
As with the previous step, you can verify the status of the support contract for all of the devices in your HA cluster at the Fortinet Support website.
- Are services enabled on the device?
To see the FortiGuard information and status for a device, in the GUI, go to System > FortiGuard. On that page, you can verify the status of each component, and enable each service.
- Can the device communicate with FortiGuard servers?
Go to System > FortiGuard in the GUI and try to update AV and IPS, or test the availability of WF and AS default and alternate ports.
- Is there proper routing to reach the FortiGuard servers?
Ensure there is a static or dynamic route that allows your FortiGate 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.
- Are there issues with DNS?
An easy way to test this is to attempt a traceroute from behind the FortiGate to an external network using the Fully Qualified Domain Name (FQDN) for a location. If the traceroute FQDN name doesn't resolve, you have general DNS problems.
- 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 ISPs often block ports that are low. There may be a firewall between the FortiGate and the FortiGuard servers that's blocking the traffic. FortiGuard uses port 53, by default, so if that port is blocked you need to either open a hole for it or change the port it is using.
- Is there an issue with source ports?
It's possible that ports that the FortiGate uses to contact FortiGuard are being changed before they reach FortiGuard or on the return trip before they reach the FortiGate. A possible solution for this is to use a fixed-port at NAT'd firewalls to ensure the port remains the same. You can use packet sniffing to find more information about what's happening with ports.
- Are there security policies that include antivirus?
If none of the security policies include antivirus, the antivirus database won't be updated. If antivirus is included, only the database type that's used will be updated.
FortiGuard server settings
Your local FortiGate connects to remote FortiGuard servers to get updates to FortiGuard information, such as new viruses that may have been found or other new threats. This section shows ways that you can to display FortiGuard server information on your FortiGate, and how you can use that information and update it to fix potential problems.
Displaying the server list
The get webfilter status or diagnose debug rating command shows the list of FDS servers that the FortiGate uses to send web filtering requests. Rating requests are only sent to the server at the top of the list in normal operation. Each server is probed for Round Trip Time (RTT) every two minutes.
Optionally, you can add a refresh rate to the end of this command to determine how often the server list is refreshed.
Rating may not be enabled on your FortiGate.
To show the list of servers a FortiGate uses to send web filtering requests - CLI
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) -=-
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Output details
The server list includes the IP addresses of alternate servers if the first entry can't be reached. In this example, the IP addresses are not public addresses.
The following flags in get webfilter status indicate the server status:
|
Flag |
Description |
|---|---|
|
|
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. |
|
|
The server to which the last INIT request was sent |
|
|
The server hasn't responded to requests and is considered to have failed |
|
|
The server is currently being timed |
|
|
Rating requests can be sent to the server The flag is set for a server only in two cases.
|
Sorting the server list
The server list is sorted first by weight. The server with the smallest RTT appears at the top of the list, regardless of weight. When a packet is lost (there has been no response in 2 seconds), it's re-sent to the next server in the list. Therefore, the top position in the list is selected based on RTT, while the other 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 isn't allowed to dip below a base weight. The base weight is calculated as the difference in hours between the FortiGate and the server multiplied by 10. The farther away the server is, the higher its base weight is and the lower it appears in the list.