NTP bursts from FortiGate firewalls

(This summarizes a problem mentioned in other discussions.)

A recent enhancement to FortiOS, used in the FortiGate firewall, did not handle NTP DNS changes correctly. When DNS mapping changed FortiGate firewalls sent 10 second duration NTP bursts at rates that could exceed 20,000 requests/second. NTP Pool servers were impacted due to the use of DNS load balancing. Our team monitored three NTP pool servers and detected over 150 FortiGate devices sending NTP bursts.

FortiGate support identified the problem: Bug ID 607015

FortiGate support informed us that FortiOS 6.2.4, released on May 12, 2020, fixed the problem. Operators of the FortiGate firewall must install that software, it is not an automatic upgrade. We don’t know when the updates will be complete. Questions should be directed to FortiGate support.

We recommended that FortiGate apply for a Vendor Zone .

Miroslav Lichvar
Hal Murray
Steve Sommars


Ha, no better than TP-Link.

1 Like

The rate of the bursts is different in different zones. From the zones I’m currently monitoring, the US zone seems to be most impacted with about 13% of NTP requests generated by these broken clients. Over time, we should see how quickly are the clients being updated.


Due to unrelated issues FortiOS 6.2.4 adoption has been insignificant. FortiNet now says 6.2.5, slated for mid-August, will be the recommended upgrade. This is disappointing, to say the least.

1 Like


Is FortiOS 6.06 having Same bug ?

FortiNet says the bug was introduced in 6.2.3, which was released December 19, 2019.

1 Like

Ok thanks and have a following query,

We are having the DC , it is syncing the time with “asia.pool.ntp.org”.
On 10th Oct20 1 minute 20 seconds ahead of actual time in DC .

Example : Actual time 12:14:00 PM but DC time was 12:15 :20 PM.

Impact : Some of the job scheduler was run 1 minutes 20 seconds before .

After some duration DC time & Actual time are same .

So what could be the changes of this 1mins 20 sec gap ?

we checked in network team , traffic and UDP port status are normal.

Server CMOS health check : OK

So what are the parameters needs to check in "Firewall " end ?

Does DC mean “Domain Controller” as in Microsoft Windows or something else?

We would need more details on the client software/configuration to speculate on what happened.

The 80 seconds difference means that one or both of the time sources were inaccurate.
If a difference is repeatable, a smartphone with a GPS/GNSS application can be used as a third time source and then determine whether either NTP time or DC time is within a couple of seconds of GPS time.

asia.pool.ntp.org” is a pool of servers, see https://www.ntppool.org/zone/asia . There are nearly 300 NTP servers in that pool that are continuously checked by the NTP pool monitors.


yes DC means Domain Controller (Windows 2012 R2).

This configuration did in Domain controller

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetervicesW32TimeParameters] “Type”="NTP “NtpServer”=“NTP Server link”.

is right configuration or i need to more ?

Client end configuration

1.Domain controller clients will sync by active directory domain services .

2.Workgroups or standalone servers syncing by the following command ,

w32tm /config /computer: /manualpeerlist: /syncfromflags:manual /update **

please suggest above configuration and methods are okay or needs to finetune .


please don’t hijack threads.
There’re currently two other threads regarding your Windows Time problem

1 Like

Back to the original topic.

It is now 11 months since the FortiGate bug was introduced in 6.2.3. The current software version is 6.2.6. I hope that the unwanted NTP request bursts are decreasing.
However, we’re monitoring a few pool servers and still see substantial bursts.

I wrote a short note on the problem