Troubleshooting Tip: Resolving FDS Communication Issues (FortiGuard Distribution Servers)

[vrajendran]

Description

This article provides help to troubleshoot and resolve issues that may arise when trying to connect to the FortiGuard servers.
The related article 'Accessing and Debugging FortiGuard Services' provides further information about FDS (FortiGuard Distribution Servers).

Scope

FortiGate in NAT, TP, VDOM mode.

Solution

1. Connect to the CLI of the FortiGate and run the following debug command:

FGT# diagnose debug rating                                       <----- For FortiGuard Web Filtering.

OR

FGT# diagnose spamfilter fortishield servers          <----- For FortiGuard Email Filtering.

Example:

FGT# diagnose debug rating

Normally an extensive list of servers will be available, however a shortlist of 3 available servers will be visible, which means that the FDS servers are responding to DNS replies to service.FortiGuard.net, but the INIT requests are not reaching full FDS services on the servers.

For each IP address, the output of the commands shows the following:

• RTT (round trip delay)
• TZ (Server time zone)
• Curr Lost (The number of recent and consecutive queries without reply)
• Total lost (The historical total number of queries without reply; these values reset when the device restart)

The 'diag debug rating' flags indicate the server status as described in the table below:

Notes:

• How is the server list sorted:
  

The server list is sorted first by weight and then the server with the smallest RTT is put at the top of the list (regardless of weight).

When a packet is lost (no response in 2s), it will be resent to the next server in the list.

So, the top position in the list is selected based on RTT while the other list positions are based on weight.

• How is the weight calculated:
  

The weight for each server increases with failed packets and decreases with successful packets.

To lower the possibility of using a faraway server, the weight is not allowed to dip below a base weight which is calculated as the difference in hours between the FortiGate 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.

•  If one or more servers are entered manually ('config system fortiGuard; set srv-ovrd enable ; config srv-ovrd-list'), the FortiGate will flush the dynamic server list to use and print only the configured server(s).
  

2. If this is the case then check that a good UDP port is available, the UDP ports used are either ports 53 or 8888.
   

These can be modified via the GUI in system -> FortiGuard.

Note these ports are sometimes on ACLs defined by the service provider.

3. This leads to Step 3, the source ports that are configured on the FortiGate and being used to connect to FDS are low source port numbers, these ports are also sometimes used by Net bios, therefore some service providers are filtering and blocking these ports.
   

To modify this, use the following command:

FGT# show system global
config system global
    set ip-src-port-range 4000-4999

end

4. If the above steps fail, connect to the CLI of the FortiGate and collect the following debug:

FGT# diag debug rating 1

This command will refresh the rating every second and will show how many packets are being sent to the FDS servers.

This gives a good health check, wrong ratings appear then note the server in question and raise this in the FortiCare case when reporting the ticket.

Note: this article's contents mainly pertain to the legacy method of FortiGuard communications. For new deployments, anycast is used by default. To troubleshoot anycast, refer to this article:

Technical Tip: FortiGuard is not reachable via Anycast default method