The communication between FortiGate and FortiGuard for web filtering and antispam is different from the communication for antivirus and IPS. If public FortiGuard services or servers are suspected to be down in one or more regions (s), the following link provides status, outage, maintenance, etc for such services: FortiGuard Anycast Query Status. Check connectivity to FortiGuard servers (Troubleshooting Tip: FortiGate FortiGuard Servers) by checking to ensure FortiGate correctly resolves DNS with the following hostnames:
securewf.fortiguard.net is for the HTTPS service. usservice.fortiguard.net = UDP - USA servers. ussecurewf.fortiguard.net = HTTPS - USA servers.
execute ping service.fortiguard.net
execute ping update.fortiguard.net
execute ping guard.fortinet.net
execute ping securewf.fortiguard.net
execute ping usservice.fortiguard.net
execute ping ussecurewf.fortiguard.net
 If DNS resolves but there is no ping, check the routing table (get router info routing-table all) to determine the best route for FortiGuard services (if ISDB is used in SD-WAN/policy route or static route) or the default route. If all traffic is sent via an IPsec tunnel, ensure that: If SD-WAN is configured as the default route, verify:
config system fortiguard
set interface-select-method sdwan
end
See this article: Technical Tip: Traffic routing from SD-WAN member in case tunnel interface does not have an IP address for more information. Note: Suppose connectivity to FortiGuard is required through one of the outgoing interfaces. In that case, it is possible to use 'interface-select-method' with the 'specify' action and then select the outgoing interface under the FortiGuard configuration.
config system fortiguard
set interface-select-method {specify}
set interface <WAN Interface>
end
Note: Verify the local-in firewall policies on the FortiGate to ensure it is not blocking local FortiGuard traffic. See Local-in policy. If the DNS resolves and it is able to ping, move to Step 2. If it is not resolving, check the DNS configuration.  Important note: If the interface that is being used for outbound communication is in DHCP mode, it receives IP addresses and DNS addresses from it.
If the option 'Override internal DNS' is enabled, it means that it will override the system's DNS settings with the ones that it received from DHCP, and it might not be able to resolve the domains to the correct addresses, resulting in failed FortiGuard communication:
 Another possible FortiGuard connectivity failure scenario is one where the FortiGate 'Time Settings' are set up manually with the wrong time and date. The solution is to either adjust the time settings or switch to using an NTP server.
For example:
 The time settings menu can also be accessed through the CLI:
config system ntp
set ntpsync [enable | disable]
set server-mode [enable | disable]
end
Note: An incorrect system time can also break HTTPS/TLS connections to FortiGuard because FortiOS checks the current date against the FortiGuard server certificate's validity window - if the clock is wrong, a perfectly valid certificate can look expired or not yet valid, and the connection gets blocked.
This is a separate issue from DNS or routing and is fixed the same way, by correcting the date manually or pointing the unit to a working NTP server.
Reference: Technical Tip: Certificate shows invalid status due to FortiGate incorrect system time
One of the most possible causes is when the 'Use FortiGuard Servers' option is changed to 'Specify' for use with an internal DNS server, without switching the DNS protocols or validating if the new DNS Server supports DoT (default setting of FortiGuard servers), which uses TCP 853, or DoH, which uses TCP 443.
If that happens, the DNS server will be unreachable, and DNS resolution will not work, as shown in the screenshot below.
 After changing to UDP 53, the DNS server will be reachable, and resolution should start working. The following are the commands to change the protocol via CLI:
For v6.4 and below:
config system dns
set dns-over-tls disable
end
When DNS-over-TLS is enabled, it will use TCP/853. Disable the use of UDP/53.  For v7.0 and above:
config system dns
set protocol cleartext
end
 To use DoT or DoH, make sure to use the DNS server hostname for the DNS server configured. For example, if 8.8.8.8 is configured as a DNS server, the server hostname for it is 'dns.google':
config system dns
set primary 8.8.8.8
set protocol dot
set server-hostname "dns.google"
end
Run 'diagnose debug rating' in the CLI:
diagnose debug rating
 The output of the command 'diagnose debug rating' displays flags next to the servers: I=Initial: The server initially connected to validate the license and fetch the server list. Typically, only one server will have this flag. D=Default: The IP address FortiGate received when resolving the name service.fortiguard.net. If the administrator has not overwritten the FortiGuard FQDN or IP address in the FortiGuard configuration, there are usually two or three servers with this flag. S=Serving: The IP address FortiGate received from FortiManager. T=Timing: The server is not replying to FortiGate queries. F=Failed: The server is down.
If all servers in the list have failed, this may mean either that all FortiGuard servers on the Fortinet side are down (unlikely) or that this FortiGate has a problem reaching them at the network level. If the PPPoE interface is being used as a WAN interface, review the MTU value and configure TCP-MSS on the PPPoE interface.
fnsysctl ifconfig -a
The PPPoE interface name will be displayed as 'ppp(x)'.
ppp1 Link encap:Point-Point Protocol
inet addr:x.x.x.x Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
The MSS value should be MTU - 40: Technical Tip: Cannot view some web sites when using PPPoE. For example, if the MTU of the PPPoE interface is 1492:
config system interface
edit <interface name>
set tcp-mss 1452
end
Additionally, reducing the tcp-mss value could help fix the TLS probe cert error (tls-active-probe). This is because the certificate may be large; it will reduce the chance of getting an error while probing an external certificate. Even if the FortiGate is not using PPPoE, there could still be MTU issues along the path, either in the directly connected ISP or a transit ISP. Lowering the MTU is still a valid test. The best way to determine if there are MTU issues along the path is to perform a packet capture for the FortiGuard server IP the FortiGate is connecting to, and if the larger packets after the initial TCP handshake (1500 bytes MTU) do not get ACK'd, it means they are getting dropped somewhere, and MTU could be the reason. If a VPN interface is being used as a WAN interface to reach FortiGuard servers, the MTU can be set to 1400 as follows:
config system fortiguard
set fortiguard-anycast disable
set sdns-server-ip "208.91.112.220"
set protocol udp
set port 53
unset source-ip
set interface-select-method specify
set interface To_Core_XYZ
end
An adjustment is made in the VPN interface:
config system interface
edit To_Core_XYZ
set mtu-override enable
set mtu 1400
end
The issue might be caused by the 'cloud-communication' and 'include-default-servers' settings being disabled in the previous firmware version. These settings must be enabled to allow FortiGate to communicate with FortiGuard services hosted in the cloud.
config system global
set cloud-communication ?
enable Allow cloud communication.
disable Disable all cloud-related settings.
set cloud-communication enable
end
config system central-management
set include-default-servers enable
end
If there are VDOMs enabled, all communication to the FortiGuard network is initiated only from the management/root VDOM.
config system global
set management-vdom "root"
end
However, from firmware v7.2 onwards in multi-VDOM mode, users can choose which VDOM FortiGuard services and updates are initiated instead of being locked to the management VDOM.
config global
config system fortiguard
set vdom "root"
end
end
The VDOM specified should be able to reach the internet. To enable the specified non-management VDOM to make and resolve DNS queries, configure vdom-dns as noted in this document: Allow FortiGuard services and updates to initiate from a traffic VDOM.
config vdom
edit root
config system vdom-dns
set vdom-dns enable
set primary 208.91.112.53
set primary 208.91.112.52
end
next
end
To set up FortiGuard services on a non-management VDOM: Specify the VDOM to be used under 'config system fortiguard'. Ensure that the specific VDOM has connectivity to the internet. vdom-dns should be configured to allow the VDOM to generate its own DNS requests.
Verify Antivirus & IPS Definition and Filtering Services: Check Antivirus & IPS Definition under System -> FortiGuard -> AntiVirus & IPS Updates -> Update Antivirus and IPS Definitions.
 v7.2.x:
The active subscriptions under System -> FortiGuard are being updated with the 'FortiGuard Updates'; the options for 'AntiVirus & IPS Updates' have been removed.  v7.6.x:
The active subscriptions under System -> FortiGuard -> Subscriptions -> Licensed are being updated with the 'FortiGuard Updates' in System -> FortiGuard -> FortiGuard settings.   Check Filtering Services under System -> FortiGuard -> Filtering.  Check Filtering Services under System -> FortiGuard -> FortiGuard settings, and then expand the Filtering option.  Note: Also, check if the override FortiGuard Servers are enabled. As displayed in the picture below. 
If the Server is set to disabled, the following logs appear in the debug output:
upd_daemon[1889]-Received update request from pid=5310
upd_daemon[1709]-Found cached action=00000002
do_update[723]-Starting now UPDATE (final try) <----- Trying to update server.
upd_fds_create_list[1295]-No server found for update[00000001] <----- Unable to reach servers.
update_upd_comp_by_settings[494]-Disabling FLEN components.
update_upd_comp_by_settings[498]-Disabling NIDSDB/ISDB/MUDB components.
update_upd_comp_by_settings[502]-Disabling APPDB/IOTDB/OTDB components.
update_upd_comp_by_settings[510]-Disabling AVEN components.
update_upd_comp_by_settings[514]-Disabling AVDB/FLDB/MMDB components.
do_update[734]-UPDATE failed <----- Update failed.
calculate_next_update_time_auto[192]-interval=20, cur_time=Wed Aug
next_update=Wed Aug
Anycast servers:
If FortiGuard is not reachable via the default anycast method, try changing the anycast source from the default Fortinet setting to AWS. This changes the source to Fortinet's AWS servers to provide FortiGuard services.
config system fortiguard
set fortiguard-anycast enable
set fortiguard-anycast-source aws
end
Note: In FortiOS v7.6.5, FortiGate VM-Azure may encounter the error 'No server found for update.' This issue can be resolved by changing the anycast source to AWS. If there are still issues with the AWS setting, it is recommended to disable Anycast and switch back to unicast servers (Use anycast to communicate with FortiGuard servers).
config system fortiguard
set fortiguard-anycast disable
set protocol udp
set port 8888
set sdns-server-ip 208.91.112.220 173.243.140.53 210.7.96.53 200.91.112.220
end
For FortiGuard's SDNS rating service, there are two modes in FortiOS:
Mode 1: Use of a unicast network, which uses the DNS over UDP protocol for FortiGate and FortiGuard transactions. Mode 2: Use of an Anycast network (default), which uses the DNS over TLS protocol for FortiGate and FortiGuard transactions.
config system fortiguard
set fortiguard-anycast disable
set sdns-server-ip 208.91.112.220 173.243.140.53 210.7.96.53
end
config system fortiguard
set fortiguard-anycast enable
end
With Anycast, FortiGate is only aware of one single server IP. This is a floating IP address that will connect to the closest server geographically, and if this server is down, it will point to another server instead. With Unicast, the FortiGate must maintain a list of servers that it tries, and if one stops working, it then switches over to another.
 In many cases, problems related to FortiGuard are caused by ISPs. Some ISPs block traffic on port 53 that is not DNS or that contains large packets. In those cases, the solution is to use port 8888. Other ISPs block traffic to HTTPS port 8888. In those cases, the solution is to use UDP port 53. There are also a few cases where ISPs block traffic based on source ports. Changing the source port range for FortiGuard to a range like the one below usually fixes the issue:
config sys global
set ip-src-port-range 1031-4999
end
Related port information: Encrypted Virus Samples auto-submitted to FortiGuard – 25. DNS lookups – 53 UDP. FortiGuard Server List requests to FortiGuard – 53 UDP. AntiSpam or Web Filtering rating lookup queries to FortiGuard – 53 UDP or 8888 UDP. URL/AS rating lookup queries to FortiGuard – 53 UDP. Real-time Black List (RBL) lookup requests to RBL services – 53 UDP. Fortinet Device Registration to FortiGuard – 80 HTTP. Firmware and Signature Downloads from FortiGuard – 443 HTTPS. FortiGuard Server List requests to FortiGuard – 1027 UDP / 1031 UDP. AntiSpam and Web Filtering rating lookup requests – 1027 UDP / 1031 UDP. AV/IPS Push / FortiGuard to FortiGate – 9443 UDP.
To configure FortiGate to use worldwide servers or only servers located in the USA, run the following command in the CLI:
config system fortiguard
set update-server-location [usa/any]
end
Note: In the latest version, the option has been changed as follows:
config system fortiguard
set update-server-location [automatic/usa/eu]
end
automatic: FortiGuard servers chosen based on the closest proximity to the FortiGate unit. usa: FortiGuard servers in the United States. eu: FortiGuard servers in the European Union.
Notes: From 8.0.1 onward, the syntax for the above command has changed to better reflect its purpose as changing the region for all services rather than updates. For more details, see the following document from the FortiOS 8.0.1 release notes: Changes in CLI.
config system fortiguard
set update-server-location <location>
end
This can also be done under System -> FortiGuard -> FortiGuard Update in the GUI.
v7.6.x:
This can also be done under System -> FortiGuard -> FortiGuard settings.
 Some debug commands for FortiGuard:
diagnose debug disable
diagnose debug reset
diagnose debug application update -1
diagnose debug console timestamp enable
diagnose debug enable
Force FortiGuard update after running debug application update -1:
execute update-now
If no output is generated after initiating the 'execute update-now', restart the update process by initiating the command 'fnsysctl killall updated'. The following command can also fix various issues with FortiGuard servers. In this example, 212.48.23.12 is used as the IP for the interface to the ISP router.
config system fortiguard
set fortiguard-anycast disable
set protocol udp
set port 8888
set sdns-server-ip 208.91.112.220 173.243.140.53 210.7.96.53
set ddns-server-ip 173.243.138.225
set source-ip 212.48.23.12
end
config system dns
set primary 8.8.8.8
set source-ip 212.48.23.12
end
The source IP should match the IP address on the WAN port of the FortiGate (ISP port). If the Source IP is changed, DNS and FortiGuard settings should be changed as well.
Note: Despite changing the FortiGuard settings to disable anycast and configuring the UDP protocol to reach the FortiGuard servers, the connection still fails because the DNS servers will still use the 'DNS over TLS' settings, which is a default setting. In this case, public IPs will be reachable, but DNS resolution fails.
Changing the DNS settings to use 'DNS over UDP' will help resolve the domain names properly. Check the dashboard WAN IP is displayed as unknown, and getting the same unable to connect to FortiGuard Server.
Follow the command line below:
config system interface
edit <wan interface>
set mtu-override enable
set mtu 1400
end
Even the FortiGate configured with a Private IP address for WAN will provide the Public IP address on the Dashboard. Try to capture the output of the following debugs:
diagnose debug reset
diagnose debug application update -1
diagnose debug console timestamp enable
diagnose debug enable
execute update-now
If no output is generated after initiating the 'execute update-now', restart the update process by initiating the command 'fnsysctl killall updated'.
In this case, the output of the debugs looks like:
upd_act_setup_with_action[190]-Trying FDS 173.243.138.68:443
tcp_connect_fds[231]-select() timed out
upd_comm_connect_fds[423]-Failed TCP connect
Try to use 'interface-select-method' with the 'specify' action and then select the outgoing interface under the FortiGuard configuration as mentioned above.
This error may also be related to FortiGate not being able to establish a TCP connection to FortiGuard through the proxy if the proxy is configured on FortiGate.
Verify on the proxy that it allows FortiGuard traffic and does not block TCP connections. Additionally, make sure that the proxy is not doing SSL inspection for FortiGuard traffic.
Note: If web-filtering and rating database updates fail while firmware/AV/IPS updates work fine through the same proxy, the proxy settings for those two update types live in different places. Firmware/AV/IPS updates use config system autoupdate tunneling (removed in v7.6.3 and later), while web-filtering and rating updates need the proxy configured separately under config system fortiguard with set proxy-server-ip and set proxy-server-port. In v7.6.3 and later, both are handled under config system fortiguard.
Reference:
Troubleshooting Tip: FortiGuard web-filtering and rating cannot update via explicit proxy
If the following debugs are observed, change the MTU on the internet-facing interface.
upd_comm_send_fds[555]-Failed SSL writing (-1, 5), left=1749, sent=0
__upd_act_update[294]-Failed sending update req
upd_comm_disconnect_fds[502]-Disconnecting FDS 173.243.140.6:443
[212] __ssl_data_ctx_free: Done
[1123] ssl_free: Done
[204] __ssl_cert_ctx_free: Done
[1133] ssl_ctx_free: Done
[1114] ssl_disconnect: Shutdown
do_update[734]-UPDATE failed
config system interface
edit WAN
set mtu-override enable
set mtu 1300
next
License errors may be found in two places, as shown below: If DNS issues occur, the following output will be seen in the CLI:
Verify DNS settings in FortiWeb under Network -> DNS. Verify the reachability of the DNS IP. If the DNS is private, change to a public DNS and verify the connectivity. If the DNS resolves, check reachability. If there is a firewall, allow ICMP for FortiWeb.
If there is any firewall in place, allow traffic to all destinations for testing purposes. If this fixes the license issue, it indicates the issue is on the firewall policy level. If all checks have been performed successfully, collect the following logs and share them in a ticket created with support:
diagnose debug application fds 7
diagnose debug application update 7
diagnose debug console timestamp enable
diagnose debug enable
execute update-now
If no output is generated after initiating the 'execute update-now', restart the update process by initiating the command 'fnsysctl killall updated'. To disable the debugging:
diagnose debug disable
diagnose debug reset
FortiGuard licenses and the communication to FortiGuard are viewable via GUI through System -> FortiGuard, as well as through the CLI using the following commands:
diagnose autoupdate versions
The output is quite long, but it is possible to pipe the output to grep:
diagnose autoupdate versions | grep -A6 "IPS Attack Engine"
If the communication to FortiGuard is OK, but the Web Filter is still shown as 'disabled' in the 'diagnose debug rating' output:
diagnose debug rating
Locale : english
Service : Web-filter
Status : Disable
Service : Antispam
Status : Disable
Service : Virus Outbreak Prevention
Status : Disable
The web filter should be licensed:  Check the firewall policy. If there is no Web Filter Profile configured in the firewall policy, the web filter will be shown as disabled in the 'diagnose debug rating' output. Check FortiGuard settings to verify the Web Filtering service is enabled globally:
show full-configuration system fortiguard | grep webfilter
set webfilter-force-off disable
end
set webfilter-force-off enable: This command forces Web Filtering to be turned off, bypassing any Web Filtering services provided by FortiGuard. Note: If the error persists after applying changes, try accessing the same page in another browser or a private window, as the browser might be displaying a cached version of the page.
Check if there are any upstream devices towards the internet. Make sure to allow UDP port 53 or port 8888 services in the upstream devices, and make sure not to block these services for FortiGuard Connectivity. To change the FortiGuard anycast status from disabled to enabled:
config system fortiguard
set fortiguard-anycast enable
set fortiguard-anycast-source fortinet
end
Run a sniffer to check the communication between FortiGuard servers and the FortiGate. In this example, the port communication is 8888. This will depend on the port used for communication between FortiGuard servers and the FortiGate.
FGT81E-1 (root) # diagnose sniffer packet any "port 8888" 4 0 l
interfaces=[any]
filters=[port 8888]
2025-06-30 19:16:59.554635 wan1 out 99.155.236.254.24391 -> 12.34.97.71.8888: udp 110
2025-06-30 19:16:59.587549 wan1 in 12.34.97.71.8888 -> 99.155.236.254.24391: udp 32
2025-06-30 19:17:00.985143 wan1 out 99.155.236.254.24391 -> 12.34.97.71.8888: udp 129
2025-06-30 19:17:01.017842 wan1 in 12.34.97.71.8888 -> 99.155.236.254.24391: udp 32
2025-06-30 19:17:02.887007 wan1 out 99.155.236.254.24391 -> 12.34.97.71.8888: udp 118
2025-06-30 19:17:02.919602 wan1 in 12.34.97.71.8888 -> 99.155.236.254.24391: udp 32
2025-06-30 19:17:09.733639 wan1 out 99.155.236.254.24391 -> 12.34.97.71.8888: udp 129
2025-06-30 19:17:09.737496 wan1 out 99.155.236.254.24391 -> 12.34.97.71.8888: udp 129
2025-06-30 19:17:09.739352 wan1 out 99.155.236.254.24391 -> 12.34.97.71.8888: udp 129
2025-06-30 19:17:09.764794 wan1 in 12.34.97.71.8888 -> 99.155.236.254.24391: udp 32
2025-06-30 19:17:09.768763 wan1 in 12.34.97.71.8888 -> 99.155.236.254.24391: udp 32
2025-06-30 19:17:09.770504 wan1 in 12.34.97.71.8888 -> 99.155.236.254.24391: udp 32
2025-06-30 19:17:13.976504 wan1 out 99.155.236.254.24391 -> 12.34.97.71.8888: udp 113
2025-06-30 19:17:14.007701 wan1 in 12.34.97.71.8888 -> 99.155.236.254.24391: udp 32
Note: To utilize the DNSProxy commands, see Technical Tip: DNS issues and commands to use for more information.
Tip: FortiGuard European (EU) Servers work only with the Anycast domain name.
If Anycast is disabled with the EU Location:
config system fortiguard
set fortiguard-anycast disable
set update-server-location eu
end
It is not possible to receive updates from the FortiGuard servers.
Notes: If the FortiGate VM cannot connect to FortiGuard servers, the license status may appear as invalid. If the management connectivity on the FortiManagement cloud (previously known as FortiGate cloud) is shown as down after resolving the FortiGuard error, use the following commands:
di fdsm contract-controller-update
fnsysctl killall fgfmd
fnsysctl killall forticldd
For additional management connectivity troubleshooting steps, refer to this article: Technical Tip: FortiGate Cloud shows management tunnel down
Related documents: | 
