Symptoms
You log into the FortiGate GUI and the FortiGuard section is showing red. Maybe it says Update Status: Failed, or the license indicators are gray and unresponsive. In the CLI,
diagnose autoupdate statusreturns connection errors. Your AV signatures are days or weeks out of date. Intrusion prevention definitions haven't moved. The firewall is technically running, but it's flying blind because it can't reach Fortinet's update infrastructure.
The symptoms you'll typically encounter include:
- GUI dashboard showing "FortiGuard Connection: Failed" or "Update Unavailable"
- AV engine and IPS definitions stuck on old dates
- Web filtering lookups failing or returning default allow/deny instead of category-based results
- Logs showing
forticldd
daemon errors or repeated failed update attempts diagnose autoupdate status
output showing "Connection timeout" or "Server not found"
The tricky part is that FortiGuard failures can manifest quietly. The firewall keeps passing traffic, so nothing looks obviously broken until you notice signatures haven't updated in a week. Let's work through the real causes, starting with the most common and moving outward.
Root Cause 1: No Internet Access from FortiGate
Why It Happens
This is the first thing I check and, embarrassingly, the most common cause I've seen in the field. The FortiGate itself — not the traffic flowing through it — needs a route to the internet. In many deployments, the management interface or even the WAN interface is missing a default route, or there's no firewall policy permitting the FortiGate's own traffic to leave. People think of the firewall as a transit device, but it's also a client that needs to initiate outbound connections to Fortinet's servers.
In my experience, this happens most often after a fresh deployment where someone configured policies for user traffic but forgot that the FortiGate itself needs outbound internet access. It also shows up after network changes where the default route got removed or overridden by a routing protocol without anyone noticing.
How to Identify It
Start with a direct ping from the FortiGate to a known internet address:
FortiGate # execute ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet lossIf that fails, pull the routing table:
FortiGate # get router info routing-table all
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
* - candidate default
C 10.10.10.0/24 is directly connected, port1
C 192.168.1.0/24 is directly connected, port2No default route. That's your problem right there. There's no
S* 0.0.0.0/0entry, meaning the FortiGate doesn't know where to send internet-bound traffic. Everything just drops into the void.
How to Fix It
Add a default route pointing to your upstream gateway:
FortiGate # config router static
FortiGate (static) # edit 1
FortiGate (static_1) # set gateway 203.0.113.1
FortiGate (static_1) # set device port1
FortiGate (static_1) # next
FortiGate (static) # endAfter adding the route, verify it appears in the routing table and re-run the ping. If pings work but FortiGuard still fails, you may also need a local-out policy permitting the FortiGate itself to initiate outbound traffic. Check whether your environment uses explicit policies for management traffic:
FortiGate # show firewall local-in-policyIn some hardened deployments, local-out traffic is restricted just like transit traffic, so the FortiGate needs an explicit allow policy for its own initiated connections to Fortinet's infrastructure.
Root Cause 2: DNS Resolution Failing
Why It Happens
FortiGuard uses hostnames, not hardcoded IPs. The update process resolves
update.fortiguard.netand
service.fortiguard.netbefore establishing connections. If DNS is broken, updates silently fail before a single packet reaches Fortinet's servers. I've seen this happen when the FortiGate's DNS servers are pointed at internal resolvers that don't have internet connectivity themselves, or when the DNS server IP is flat-out wrong after a migration or IP renumbering exercise.
It's deceptive because the FortiGate might have a valid default route and internet connectivity, but without DNS it can't resolve the update server hostnames. The error messages don't always make it obvious that DNS is the bottleneck.
How to Identify It
Check the current DNS configuration:
FortiGate # show system dns
config system dns
set primary 10.10.10.1
set secondary 10.10.10.2
endNow test resolution directly from the FortiGate:
FortiGate # diagnose sys dns lookup update.fortiguard.net
Server: 10.10.10.1
Address: 10.10.10.1#53
DNS lookup timeout.That timeout confirms DNS is the bottleneck. The internal resolver at 10.10.10.1 either isn't reachable or can't resolve external names. Try a known-good public resolver to isolate the issue:
FortiGate # diagnose sys dns lookup update.fortiguard.net 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53
Name: update.fortiguard.net
Address: 208.91.112.220That resolves fine, which tells you the FortiGate has internet connectivity but your configured resolver is the problem.
How to Fix It
Either fix the internal DNS resolver so it can forward external queries, or point the FortiGate at a working resolver:
FortiGate # config system dns
FortiGate (dns) # set primary 8.8.8.8
FortiGate (dns) # set secondary 1.1.1.1
FortiGate (dns) # endRe-run the lookup to confirm resolution works, then force an update:
FortiGate # execute update-nowIn production, I'd recommend pointing the FortiGate's DNS at your internal resolvers and ensuring those resolvers can forward public queries. Don't leave a public DNS server as a permanent fix if your security policy requires DNS inspection or split DNS — fix the resolver chain instead.
Root Cause 3: Proxy Not Configured
Why It Happens
Some corporate environments route all outbound HTTP and HTTPS traffic through an explicit proxy. If the FortiGate is sitting in one of these networks, it needs to know about the proxy to make outbound HTTPS connections to Fortinet's update servers. Without this configuration, the FortiGate sends packets directly to the internet, those packets get dropped or reset by the proxy enforcement device upstream, and updates fail with what looks like a generic connection timeout.
This one catches people out because everything else on the network works fine — end users browse through the proxy without issue — but the FortiGate itself is a separate client that needs its own proxy configuration. It doesn't inherit proxy settings from the network the way a browser does.
How to Identify It
Check whether a proxy is currently configured for autoupdate:
FortiGate # show system autoupdate tunneling
config system autoupdate tunneling
endAn empty block means no proxy is set. Then confirm whether direct connections are being blocked by running a packet capture while attempting an update:
FortiGate # diagnose sniffer packet any "host 208.91.112.220" 4
interfaces=[any]
filters=[host 208.91.112.220]
0.414250 port1 out 10.10.10.254.45231 -> 208.91.112.220.443: syn
0.914512 port1 out 10.10.10.254.45231 -> 208.91.112.220.443: syn
1.414891 port1 out 10.10.10.254.45231 -> 208.91.112.220.443: synRepeated SYN packets with no SYN-ACK response. The FortiGate is sending directly but getting no reply — consistent with a proxy-enforced environment where direct connections are silently dropped. If you see this pattern and know your environment requires a proxy, that's your answer.
How to Fix It
Configure the proxy settings under autoupdate tunneling. Get the proxy address and port from your network team:
FortiGate # config system autoupdate tunneling
FortiGate (tunneling) # set status enable
FortiGate (tunneling) # set address 192.168.50.10
FortiGate (tunneling) # set port 8080
FortiGate (tunneling) # set username infrarunbook-admin
FortiGate (tunneling) # set password YourProxyPassword
FortiGate (tunneling) # endIf the proxy doesn't require authentication, skip the username and password fields. After applying, force an update and watch whether the connection now completes. The packet capture should show traffic going to the proxy IP on port 8080 rather than directly to 208.91.112.220.
Root Cause 4: License Expired
Why It Happens
FortiGuard services — AV, IPS, web filtering, anti-spam, and others — are subscription-based. When a subscription lapses, Fortinet's cloud infrastructure stops serving updates for that device. The FortiGate can still connect to FortiGuard servers and the connection itself may succeed at the network layer, but the update request gets rejected because the entitlement is gone. This is fundamentally different from a connectivity failure — the network path works, but the transaction fails at the application layer.
In my experience, license expiry surprises people because the FortiGate doesn't always shout about it immediately. Some versions display a subtle dashboard warning; others just quietly stop updating. You only notice when someone asks why the AV signatures are three months old.
How to Identify It
Check the system status for license state:
FortiGate # get system status
Version: FortiGate-100F v7.2.5,build1517,230209 (GA)
Virus-DB: 90.08775(2023-01-15 10:22)
Extended DB: 90.08775(2023-01-15 10:22)
IPS-DB: 6.00741(2023-01-15 10:30)
Serial-Number: FGT100F0000000001
License Status: Expired
BIOS version: 07000027
System time: Fri Apr 18 14:23:11 2025The License Status: Expired line is the giveaway. Then get the per-service expiry detail:
FortiGate # diagnose autoupdate status
FDS address: 208.91.112.220:443
Virus definitions status:
Version: 90.08775
Contract Expiry Date: Tue Jan 14 2023
IPS Attack Engine status:
Contract Expiry Date: Tue Jan 14 2023
Web Filtering:
Contract Expiry Date: Tue Jan 14 2023Past expiry dates on every service confirm it. The FortiGate will still pass traffic, but FortiGuard lookup-dependent features — category-based web filtering, real-time AV lookups, botnet C&C blocking — degrade or fail entirely depending on the service and FortiOS version.
How to Fix It
This requires a commercial fix — renew the FortiGuard subscription through Fortinet or your reseller. Once renewed, the entitlement is updated against your serial number in FortiCare. Force a license refresh from the FortiGate:
FortiGate # execute update-nowIf the entitlement update doesn't reflect within a few minutes, trigger a manual contract check:
FortiGate # execute federated-upgrade check-versionGive it five to ten minutes before declaring it stuck. Fortinet's licensing backend sometimes has propagation delays after a renewal. If it's still not reflecting after 15 minutes, open a case with Fortinet TAC — occasionally the entitlement update requires manual intervention on their backend.
Root Cause 5: Update Server Unreachable
Why It Happens
Even when the FortiGate has internet access and DNS works, the specific servers and ports that FortiGuard uses may be blocked somewhere in the network path. Upstream firewalls, ISP-level filtering, or overly restrictive egress ACLs can silently drop traffic to Fortinet's update infrastructure. FortiGuard communications use TCP 443 for firmware and signature downloads, UDP 8888 for FortiGuard rating queries, and occasionally TCP 8890 as an alternate. If any of these are blocked, specific FortiGuard functions will fail even though general internet access appears fine.
I've seen this in environments where a transit firewall has a strict application whitelist for outbound connections. Someone opens port 443 broadly, but FortiGuard's UDP 8888 traffic never made it into the ruleset. HTTPS-based lookups half-work, but rating queries time out, and the dashboard shows a partial connectivity state that's confusing to diagnose.
How to Identify It
Use the built-in rating diagnostics to see how the FortiGate perceives FortiGuard server status:
FortiGate # diagnose debug rating
Weight: 0x0004
Strict: 0
FGIP: 208.91.112.220 FGSD: 0 FGWT: 0.0 State: - TO: 0
FGIP: 208.91.112.221 FGSD: 0 FGWT: 0.0 State: - TO: 0
FGIP: 208.91.112.222 FGSD: 0 FGWT: 0.0 State: - TO: 0The
State: -means the FortiGate can't determine server reachability at all. A healthy output would show numeric state values. Test direct connectivity to the primary update server:
FortiGate # execute ping update.fortiguard.net
PING update.fortiguard.net (208.91.112.220): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2ICMP might be blocked while TCP works fine, so don't conclude too much from ping alone. Run a packet capture to confirm traffic is actually leaving the FortiGate:
FortiGate # diagnose sniffer packet port1 "dst host 208.91.112.220" 4
0.001234 10.10.10.254.52341 -> 208.91.112.220.443: syn
0.001567 10.10.10.254.52341 -> 208.91.112.220.443: syn
0.001890 10.10.10.254.52341 -> 208.91.112.220.443: synTraffic is leaving but getting no response. The block is upstream of the FortiGate. Work with your ISP or the team managing upstream firewall devices to identify where the traffic is being dropped.
How to Fix It
Add egress rules on the upstream device permitting outbound from the FortiGate's WAN IP to Fortinet's infrastructure:
- TCP 443 to 208.91.112.0/24 — signature and firmware downloads
- UDP 8888 to 208.91.112.0/24 — FortiGuard rating queries
- TCP/UDP 53 to your DNS resolvers — hostname resolution for FortiGuard domains
If your environment won't permit UDP 8888, FortiGate supports forcing all FortiGuard communication over HTTPS. This loses the lower-latency UDP path but maintains full functionality over TCP 443:
FortiGate # config system fortiguard
FortiGate (fortiguard) # set protocol https
FortiGate (fortiguard) # set port 443
FortiGate (fortiguard) # endAfter forcing HTTPS mode, re-run
diagnose debug ratingto confirm the server state values populate correctly. If they do, your updates should resume.
Root Cause 6: Time Synchronization Out of Sync
Why It Happens
SSL/TLS certificate validation is time-sensitive. If the FortiGate's system clock is significantly wrong — off by more than a few minutes in either direction — the TLS handshake to FortiGuard's HTTPS update servers will fail certificate validation. The certificate appears either not yet valid or already expired from the FortiGate's warped perspective. This is one of those causes that looks completely unrelated to what's actually breaking.
It happens most often after a device reboot when NTP hasn't been configured, leaving the clock at a factory default or a date from the last time the NVRAM battery drained. The FortiGate tries to connect to FortiGuard, the TLS handshake fails silently, and the update daemon logs a generic connection error.
How to Identify It
Check the current system time:
FortiGate # get system status | grep "System time"
System time: Thu Jan 1 00:04:17 2004That's obviously wrong — the FortiGate is stuck at what looks like a post-boot time with no NTP sync. Confirm NTP configuration:
FortiGate # show system ntp
config system ntp
set ntpsync disable
endNTP sync is disabled. Without it, the clock drifts and after a reboot it may reset to a nonsensical date entirely.
How to Fix It
Enable NTP and point it at a reliable time source. Here the internal NTP server at sw-infrarunbook-01.solvethenetwork.com is used, falling back to a public pool:
FortiGate # config system ntp
FortiGate (ntp) # set ntpsync enable
FortiGate (ntp) # set type custom
FortiGate (ntp) # config ntpserver
FortiGate (ntpserver) # edit 1
FortiGate (ntpserver_1) # set server 192.168.1.10
FortiGate (ntpserver_1) # next
FortiGate (ntpserver) # edit 2
FortiGate (ntpserver_2) # set server 192.168.1.11
FortiGate (ntpserver_2) # next
FortiGate (ntpserver) # end
FortiGate (ntp) # endVerify the clock corrects itself within a minute or two:
FortiGate # execute date
current date is: 2025-04-18 14:23:00Once the clock is accurate, retry the FortiGuard update. In most cases it succeeds immediately after time is corrected.
Root Cause 7: SSL Deep Inspection Intercepting FortiGuard Traffic
Why It Happens
This one surprises people. If you have an upstream device performing SSL deep inspection — including a parent FortiGate in a layered deployment — it may be intercepting the TLS sessions to FortiGuard's update servers and re-signing them with its own CA certificate. FortiGate's update client pins or strictly validates Fortinet's certificates, so when it sees a cert signed by an internal CA instead of Fortinet's legitimate CA chain, the handshake fails. I've seen this in multi-tier setups where someone enabled deep inspection on the perimeter device without adding Fortinet's update domains to the SSL inspection bypass list.
It's particularly insidious because the network path is completely fine, DNS resolves correctly, and the upstream device thinks it's doing its job properly. The failure is entirely at the certificate validation layer.
How to Identify It
Enable update debug output while forcing an update attempt:
FortiGate # diagnose debug application update -1
FortiGate # diagnose debug enable
FortiGate # execute update-now
update: FDS connect to 208.91.112.220:443
update: SSL connection failed: certificate verify failed
update: retry with next server...
update: FDS connect to 208.91.112.221:443
update: SSL connection failed: certificate verify failed
update: all servers tried, update failedThe certificate verify failed message is the fingerprint of this issue. The certificate presented by the update server doesn't match what the FortiGate expects because it's been re-signed by the upstream inspection device.
How to Fix It
On the upstream device performing SSL inspection, add the FortiGuard domains to the SSL inspection exemption list. For a FortiGate performing the deep inspection upstream, add exemptions in the SSL/SSH inspection profile:
UpstreamFortiGate # config firewall ssl-ssh-profile
UpstreamFortiGate (ssl-ssh-profile) # edit "deep-inspection"
UpstreamFortiGate (deep-inspection) # config ssl-exempt
UpstreamFortiGate (ssl-exempt) # edit 0
UpstreamFortiGate (ssl-exempt_0) # set type fqdn
UpstreamFortiGate (ssl-exempt_0) # set fqdn "update.fortiguard.net"
UpstreamFortiGate (ssl-exempt_0) # next
UpstreamFortiGate (ssl-exempt) # edit 0
UpstreamFortiGate (ssl-exempt_0) # set type fqdn
UpstreamFortiGate (ssl-exempt_0) # set fqdn "service.fortiguard.net"
UpstreamFortiGate (ssl-exempt_0) # next
UpstreamFortiGate (ssl-exempt) # end
UpstreamFortiGate (deep-inspection) # endThis tells the upstream device to pass FortiGuard connections through without re-signing. After applying the exemption, clear the debug output on the downstream FortiGate and retry:
FortiGate # diagnose debug disable
FortiGate # diagnose debug reset
FortiGate # execute update-nowThe update should complete cleanly once FortiGuard's certificates are no longer being replaced mid-stream.
Prevention
Most FortiGuard update failures are preventable if you build a few habits into your standard operating procedures.
First, document and test outbound connectivity requirements during initial deployment. Before a FortiGate goes live, verify it can reach FortiGuard servers on the required ports. Run
diagnose debug ratingas part of your deployment checklist and make sure you see valid numeric server state values — not dashes — before signing off on the deployment. This takes two minutes and catches routing, DNS, and port issues before they become production problems.
Second, set up license expiry monitoring. FortiManager can alert on expiring contracts, and FortiGate itself will log warnings as expiry approaches. Map those log events to your alerting platform so you get ahead of renewals by at least 30 days. Scrambling to renew a license after it's already expired — especially when procurement approvals are involved — is painful and avoidable. Treat FortiGuard subscriptions like any other renewable service in your asset tracking system.
Third, always run NTP. It sounds obvious, but I've audited environments where NTP was left disabled on the assumption that the clock wouldn't drift meaningfully. It does, and the failures it causes are subtle. Configure NTP during initial setup, verify sync is working, and check it periodically. While you're at it, make sure the NTP server the FortiGate points to is reachable — an unreachable NTP server is nearly as bad as no NTP configuration at all.
Fourth, maintain a network diagram that explicitly shows which devices perform SSL deep inspection and what exemptions are in place. When you add a new device to the network — especially a downstream FortiGate that needs to reach FortiGuard — check whether it needs to be exempted from existing SSL inspection policies before you deploy it. This context is easy to lose track of as infrastructure grows and teams change.
Finally, schedule periodic checks of FortiGuard update status. A simple monitoring check that reads
diagnose autoupdate statusoutput and alerts if the last successful update is more than 48 hours old will catch failures before your signatures get dangerously stale. FortiGuard AV definitions often update multiple times per day, so a multi-day gap is an unambiguous signal that something is wrong. Pair this with an alert for signature dates older than 72 hours and you'll never get caught running outdated definitions without knowing it.
When you do hit a FortiGuard update failure, work through the causes methodically: verify routing first, then DNS, then port connectivity, then license status, then time sync, then check for SSL inspection interference. Most failures fall into one of those buckets and resolve quickly once you've correctly identified the root cause. Don't jump straight to opening a TAC case — the majority of these are local configuration issues that you can resolve faster than a support ticket will get triaged.