# NTP bursts from FortiGate firewalls
**URL:** https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661
**Category:** Uncategorized
**Created:** [May 19, 2020, 2:49am UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661 "2020-05-19T02:49:29Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@stevesommars](https://community.ntppool.org/u/stevesommars)
#### Post date: [May 19, 2020, 2:49am UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/1 "2020-05-19T02:49:29Z")
(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](https://docs.fortinet.com/document/fortigate/6.2.3/fortios-release-notes/236526/known-issues)
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](https://www.pool.ntp.org/vendors.html) .
Miroslav Lichvar
Hal Murray
Steve Sommars
---
### Author:  [@alica](https://community.ntppool.org/u/alica)
#### Post date: [May 19, 2020, 3:23am UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/2 "2020-05-19T03:23:56Z")
> [@stevesommars](#):
>
> Operators of the FortiGate firewall must install that software, it is not an automatic upgrade.
Ha, no better than TP-Link.
---
### Author:  [@mlichvar](https://community.ntppool.org/u/mlichvar)
#### Post date: [May 19, 2020, 8:21am UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/3 "2020-05-19T08:21:50Z")
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.
---
### Author:  [@stevesommars](https://community.ntppool.org/u/stevesommars)
#### Post date: [July 27, 2020, 7:22pm UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/4 "2020-07-27T19:22:41Z")
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.
---
### Author:  [@gobinath1984](https://community.ntppool.org/u/gobinath1984)
#### Post date: [October 14, 2020, 9:12am UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/5 "2020-10-14T09:12:54Z")
Hi,
Is FortiOS 6.06 having Same bug ?
---
### Author:  [@stevesommars](https://community.ntppool.org/u/stevesommars)
#### Post date: [October 14, 2020, 1:56pm UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/6 "2020-10-14T13:56:21Z")
FortiNet says the bug was introduced in 6.2.3, which was released December 19, 2019.
---
### Author:  [@gobinath1984](https://community.ntppool.org/u/gobinath1984)
#### Post date: [October 14, 2020, 4:13pm UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/7 "2020-10-14T16:13:39Z")
Ok thanks and have a following query,
We are having the DC , it is syncing the time with “[asia.pool.ntp.org](http://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 ?
---
### Author:  [@stevesommars](https://community.ntppool.org/u/stevesommars)
#### Post date: [October 14, 2020, 5:50pm UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/8 "2020-10-14T17:50:53Z")
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](http://asia.pool.ntp.org/)” is a pool of servers, see [https://www.ntppool.org/zone/asia](https://www.ntppool.org/zone/asia) . There are nearly 300 NTP servers in that pool that are continuously checked by the NTP pool monitors.
---
### Author:  [@gobinath1984](https://community.ntppool.org/u/gobinath1984)
#### Post date: [October 15, 2020, 6:40am UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/9 "2020-10-15T06:40:45Z")
Thanks,
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 .
---
### Author:  [@apuls](https://community.ntppool.org/u/apuls)
#### Post date: [October 15, 2020, 12:05pm UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/10 "2020-10-15T12:05:09Z")
@gobinath1984
please don’t hijack threads.
There’re currently two other threads regarding your Windows Time problem
- [Event ID : 1 in windows Server 2012](https://community.ntppool.org/t/event-id-1-in-windows-server-2012/1806/3)
- [Time Service Event log query](https://community.ntppool.org/t/time-service-event-log-query/1800/6)
---
### Author:  [@stevesommars](https://community.ntppool.org/u/stevesommars)
#### Post date: [December 1, 2020, 1:09am UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/11 "2020-12-01T01:09:27Z")
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](https://weberblog.net/fortigate-bug-firewalls-sending-excessive-requests-to-the-ntp-pool/)
---
### Author:  [@stevesommars](https://community.ntppool.org/u/stevesommars)
#### Post date: [September 20, 2021, 3:44am UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/12 "2021-09-20T03:44:38Z")
Quick update. It is now September 2021. The FortiGate problem continues.
It is especially severe in Lithuania, comprising 80-90% of NTP Pool traffic.
I’ve been monitoring New Zealand closely: 15-20% of NTP Pool traffic there over the past year has come from these bursts.
I’ve had little success reaching the administrators of the abusive clients.
---
### Author:  [@marco.davids](https://community.ntppool.org/u/marco.davids)
#### Post date: [November 23, 2021, 11:45am UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/13 "2021-11-23T11:45:40Z")
> [@stevesommars](#):
>
> The FortiGate problem continues.
There is an IP address bothering us every now and then and I would like to find out if it is still suffering from this bug.
The packets are NTP version 3. Below is a picture of the NTP-packet. The source port never changes. It does look like the FortiGate problem, except it aren’t bursts, but rather a continuing stream of packets (well over 70,000 per second), that lasts for some 12 hours on a row.
Can anyone tell if this looks like FortiGate? Or maybe something else? One would assume the FortiGate-issue should have disappeared by now.
---
### Author:  [@stevesommars](https://community.ntppool.org/u/stevesommars)
#### Post date: [November 23, 2021, 2:52pm UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/14 "2021-11-23T14:52:35Z")
The FortiGate problem is still present, though the number of affected clients is slowly dropping. [It’s been almost two years!] The burst duration is typically 10 seconds or less.
Miroslav recently pointed to a [systemd bug](https://community.ntppool.org/t/uncommon-load-question-many-packets-from-one-ip/2187/4) . The key indicator seems to be "fractional part wrapping around 232 milliseconds " I’ve seen this bug as have several others.
Can you forward a pcap?
---
### Author:  [@marco.davids](https://community.ntppool.org/u/marco.davids)
#### Post date: [November 23, 2021, 3:36pm UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/15 "2021-11-23T15:36:53Z")
> [@stevesommars](#):
>
> Can you forward a pcap?
Send you a private message. Thanks.
---
### Author:  [@avij](https://community.ntppool.org/u/avij)
#### Post date: [January 23, 2025, 5:28pm UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/16 "2025-01-23T17:28:08Z")
My server in Finland has seen traffic peaks every now and then, but I only recently started capturing the traffic to see what is going on. Most of the peaks were caused by traffic from Lithuania (see above) – 10 second bursts with ~2k requests/sec. I think this looks like a FortiGate bug. I’ve sent notices to the appropriate abuse email addresses, but so far I’ve only received one automatic reply that a ticket was created.
To that one, I responded with this:
> I’ll amend my report by stating that if you are indeed using an older version of FortiOS, you may be vulnerable to CVE-2024-21762:
>
> CVE-2024-21762: An out-of-bounds write vulnerability in the SSL VPN daemon (sslvpnd) of FortiOS. This flaw allows remote, unauthenticated attackers to execute arbitrary code or commands via specially crafted HTTP requests. Fortinet disclosed this vulnerability on February 8, 2024, and indicated it was “potentially being exploited in the wild.” The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2024-21762 to their Known Exploited Vulnerabilities list on February 9, 2024, confirming active exploitation.
> [PSIRT | FortiGuard Labs](https://www.fortiguard.com/psirt/FG-IR-24-015)
>
> It would be in your own best interests to upgrade.
I’ll likely include this information in any future NTP traffic correspondence.
There are likely [others](https://www.fortiguard.com/psirt) as well, but this “remote unauthenticated attackers” caught my eye. Now that I had a closer look at that page, [CVE-2021-26109](https://www.fortiguard.com/psirt/FG-IR-21-049), [CVE-2022-0778](https://www.fortiguard.com/psirt/FG-IR-22-059) and [CVE-2022-42475](https://www.fortiguard.com/psirt/FG-IR-22-398) also sound interesting. The owners of those FortiGate firewalls might not care too much about some extra NTP traffic, but maybe a threat of someone hacking their corporate firewall would be enough to make them do something.
---
### Author:  [@stevesommars](https://community.ntppool.org/u/stevesommars)
#### Post date: [January 23, 2025, 7:45pm UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/17 "2025-01-23T19:45:26Z")
I’ve been seeing the bursts for over five years!
For a while I was in contact with Fortinet who confirmed the nature of the FortiGate bug. It’s been several years since Fortinet released a FortiGate software update. Outside of Europe the NTP bursts have mostly died out. Within Europe there are still many bursts seen, mostly from Lithuania.
The Lithuania traffic was different though. The source addresses varied over time. My guess is that these NTP clients use similar NTP code in another application that hasn’t been corrected. When I tried discussing this with Fortinet, they stopped responding to my emails. To be fair, I have no direct evidence that Fortinet software is at fault.
I suspect there are several hundred affected clients. It is interesting to see that at times many clients send bursts at the same time.
---
### Author:  [@mlichvar](https://community.ntppool.org/u/mlichvar)
#### Post date: [February 6, 2025, 3:21pm UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/18 "2025-02-06T15:21:46Z")
I was tired of seeing the Anti-DDoS outages of my OVH VPSes caused by Fortigates and decided to block the clients at the edge network firewall. I wrote an optimized detector in C and python scripts to prepare and load the firewall rules.
A major issue with the OVH firewall is that it can have only 20 rules, so the blocked networks need to be quite large to get a decent coverage of abusive clients. There are many addresses blocked incorrectly (one port only). I think that is better than having the server completely unreachable for 15 minutes every time when too many Fortigates decide to flood my server.
If anyone would like to try it, here is the source code:
> **[GitHub - mlichvar/ntpguard: Detect and block abusive NTP clients](https://github.com/mlichvar/ntpguard)**
>
> Detect and block abusive NTP clients
I’m still experimenting with adjustments of the coverage to minimize the number of falsely blocked addresses while still avoiding most of the outages. If there is interest I can publish my current rules.
I’m also not sure how to keep the rules up to date. When the they are active, the detector will not see that traffic. Maybe there could be a system where each rule is disabled for a day, but the processing script would need to be improved to track when is each addressed blocked and adjust the weights in processing accordingly.
---
### Author:  [@NTPman](https://community.ntppool.org/u/NTPman)
#### Post date: [February 6, 2025, 3:42pm UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/19 "2025-02-06T15:42:41Z")
> [@mlichvar](#):
>
> the Anti-DDoS outages of my OVH VPSe
Is this DoS protection on the OVH network level, or on the VPS level?
By the way, ask OVH to switch off that DoS “protection” for your system(s).
---
### Author:  [@mlichvar](https://community.ntppool.org/u/mlichvar)
#### Post date: [February 6, 2025, 3:54pm UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/20 "2025-02-06T15:54:07Z")
It’s somewhere in their network. It cannot be disabled and cannot be adjusted, unless it’s a bare-metal machine or public cloud instance. That’s a recent information from the OVH support after I explained multiple times what exactly is the problem and I got through to the second level.
Several years ago they claimed they adjusted the limits, but it never worked for me.
[Next page](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661.md?page=2)