Skip to main content
lcamilo
Staff
lcamilo
Staff
August 16, 2024

Technical Tip: Configuring load balancing for FortiGuard Webfilter Rating requests on the FortiGate

  • August 16, 2024
  • 0 replies
  • 1165 views
Description

 

This article describes the load-balance-servers option on the FortiGate, how this option affects outgoing requests to FortiGuard servers for Web Filter Rating requests, and the expected outcome.

Scope

 

FortiOS v6.0 and later, Web Filtering.

Solution

 

The load-balance-servers option is found under config system fortiguard and controls how many FortiGuard Web Filter Rating servers should be queried at the same time from the available server list on the FortiGate. By default, this option is set to 1, which means that only the first best FortiGuard server from the list is queried for Web Filtering purposes (i.e., no load balancing).

 

Note 1: For more information on how these servers are learned and how they are ordered, see Troubleshooting Tip: Resolving FDS Communication Issues (FortiGuard Distribution Servers) and Technical Tip: FortiGuard flags and meanings. Key points for this article are as follows:

  • Server entries with the F (Failed) flag are deprioritized and moved to the bottom of the list below working server entries.
  • In FortiOS v7.6 and older, weight was used to rank each server entry (lower weight = more preferred and closer to the top).
  • With FortiOS v8.0 and later, weight is no longer utilized for server sorting. Additionally, Web Filter Rating server entries learned through FortiManager central management can be prioritized or deprioritized relative to the standard FortiGuard list (see Note 2 below regarding both changes in v8.0).
  • Finally, round-trip time (RTT) is used as a tie-breaker if server entries have the same flags and weights.

 

Note 2: FortiOS v8.0.0 and later introduces several changes to how Web Filter Rating servers are utilized by the FortiGate:

  • Change #1223015 changes the default setting for load-balance-servers from 1 to 5, and so load balancing across Web Filter Rating servers will be enabled by default going forward.
  • This change also introduces a new setting called use-default-servers-as-main (present under config system central-management), which controls the priority of web rating servers learned through FortiManager. When enabled, this setting prioritizes the default FortiGuard servers over the FortiManager-advertised servers (which have an M flag), whereas setting it to disabled will move the FortiManager rating servers to the top of the list.
  • Change #1234531 discontinues the usage of the weight metric for sorting server entries and instead uses the round-trip time (RTT) to rank server entries under the diagnose debug rating.

 

Example 1 (Multiple servers, no failed servers):

In the example below, load-balance-servers has been set to 10, which means that the FortiGate will load balance queries across the 10 best servers in the list (if available). For demonstration purposes, fortiguard-anycast has been disabled so that more server entries are present in the list (via the older unicast FortiGuard servers):


config system fortiguard
    set fortiguard-anycast disable
    set load-balance-servers 10
end

 

The following example output comes from the command diagnose debug rating, which was taken after configuring the above:


diag_debug_rating_01.png

 

Given the above configuration and screenshot, the following is the expected behavior:

  • Currently, the FortiGate is configured to load balance up to ten servers. However, only five are available, and so all five are selected for load balancing.
  • Requests will generally be distributed evenly across all servers selected for load balancing, even though some servers may have better RTT (round-trip time) and offer faster responses.
  • The above screenshot was taken using FortiOS v7.2, which means that weight is used to order the server entries. 173.243.138.96 has a weight of 0 and is considered the relative best server, whereas 210.7.96.18 has a weight of 120 and is considered the relative worst server in the list.
  • However, because all five entries were selected for load balancing, their weights are otherwise ignored. Note that the weight value does not impact how the web rating queries are distributed.

 

Example 2 (Multiple servers with some failed entries):

This example also uses sets load-balance-servers to 10, but this time it uses anycast FortiGuard instead of unicast (set fortiguard-anycast enable). This results in fewer server IP address entries since they are shared across global Fortinet datacenters (compared to unicast FortiGuard, which uses separate public IPs for each datacenter):

 

config system fortiguard
    set load-balance-servers 10
end


Similar to the previous example, the following is the output of the diagnose debug rating. Notice how there are fewer entries, and there are also IPv4 and IPv6 resolved entries:

 

diag_debug_rating_02.png

 

Just like with Example 1, the FortiGate is configured to load balance across ten servers, but only two are available. However, notice that the IPv6 entry has the 'F' flag, which indicates that the server is unavailable or unreachable (in this case, the example FortiGate did not have IPv6 connectivity configured). This is important, as the FortiGate's behavior will be different depending on the firmware version:

 

Before change #1002266, the FortiGate would not factor in the 'F' flag when selecting available load-balancing servers. The 'F' flag lowered the priority of the server entry, but it was still considered valid for load balancing if load-balance-servers was set to a high enough value. Any web rating requests sent to unreachable servers would likely fail, resulting in disruptions to user web traffic. Checking the Web Filter event logs would likely show entries with a message of 'a rating error occurs':

 

webfilter_rating_errors.png

 

Similarly, debug commands on web filter rating requests would also show these failures occurring:

 

diagnose debug application urlfilter -1
Debug messages will be on for 30 minutes.

diagnose debug enable

 

0(6695) action=12(ftgd-monitor) wf-act=0(MONITOR) user="N/A" src=172.16.45.51 sport=46348 dst=17.253.144.10 dport=80 service="http" cat=52 url_cat=52 ip_cat=52 hostname="apple.com" url="/"
0(6695) (warning) connect to 2620:101:9000:140:173:243:140:16 failed 101:Network is unreachable

 

After change #1002266 (implemented in FortiOS v7.0.16, v7.2.9, v7.4.4, v7.6.0, and later), the load balance logic was updated such that server entries with the 'F' flag are no longer selected for load balancing, which means that there are no further risks with setting load-balance-servers to a high value.

 

Recommendations:

  • When using anycast FortiGuard on FortiOS versions before change #1002266, it is recommended to leave load-balance-servers set to the default of 1.
  • When using unicast FortiGuard on FortiOS versions before change #1002266, load-balance-servers may be set to any value that is smaller than the number of working servers (e.g., use 4 or fewer if there are 5 working servers).
  • For any FortiOS version after change #1002266, any value may be set for load-balance-servers, and for FortiOS v8.0 and later in particular, it is safe to leave the setting at the default of 5.

 

As a side note, there was also a Known Issue #931299 where it was previously possible that only a single IPv6 entry would be resolved for the web rating server list, which would generally result in Web Filter failure. This was fixed in FortiOS v7.0.13, v7.2.8, v7.4.2, and later so that Web Filtering would only initialize if at least one IPv4 entry was resolved via DNS.

 

If this issue is still being encountered and a firmware upgrade cannot yet be performed, then an available workaround is to run the command diagnose test application urlfilter 99, which restarts the urlfilter daemon and also retriggers a DNS lookup attempt.

 

Related documents:

Terms & ConditionsAccessibility statement