topic Re: FW Hardware Datetime instead of NTP-settings in Firewall and Security Management

FW Hardware Datetime instead of NTP-settings

Grigoriy — Mon, 15 Sep 2025 06:24:10 GMT

Good Day, Dear Checkpmates!

We had an issue with our NTP-servers (IT department is still resolving it) - as a result FWs syncronised to 2006 year and stopped to sync in the cluster correctly (in the SMS the clusters were red).

I've changed datetime settings to 'Manual' and gave the correct datetime - the problem has been resolved.

So a question came to my mind - is it technically possible to use FW Hardware Datetime instead of NTP-settings or system datetime and if yes what should I change?

What are the caveats and "hidden rocks" of such approach?

Thank you in advance!

Re: FW Hardware Datetime instead of NTP-settings

emmap — Mon, 15 Sep 2025 07:22:42 GMT

I believe the system will take its time from the BIOS clock at bootup, and then sync what it has to BIOS on shutdown. So by turning off any NTP syncing you have already achieved this as much as it can be done.

Re: FW Hardware Datetime instead of NTP-settings

Grigoriy — Mon, 15 Sep 2025 09:07:33 GMT

Do you mean that even when I choose 'Set Time and Date Manually' (as on the screenshot below) the appliance will take time from system/BIOS?

Re: FW Hardware Datetime instead of NTP-settings

emmap — Mon, 15 Sep 2025 11:42:09 GMT

It has to get it from somewhere when it boots up. My understanding is that any OS gets the time from BIOS on bootup, then keeps it going either itself or regularly checks it via NTP. On shutdown the OS then updates the BIOS clock.

Re: FW Hardware Datetime instead of NTP-settings

the_rock — Mon, 15 Sep 2025 18:41:01 GMT

For what is worth, AI pretty much says what @emmap advised.

Andy

************************

1. Where the firewall gets its time

Hardware clock (RTC / BIOS clock):
This is a low-level clock on the appliance. It starts ticking as soon as you power on, but it is not precise and tends to drift over time.
On boot, Gaia copies the hardware time into the system clock.
System clock (software clock):
This is what the OS (and all processes, including clustering, VPN, logs, etc.) actually uses during runtime.
You can set it manually (set timezone, set date, set time) or let it sync to NTP.
NTP:
This is the recommended way to continuously discipline the system clock against a reliable source.

2. Can you rely on the hardware clock instead of NTP?

Technically: No, not in a reliable way.

After boot, the system does not continuously sync to the hardware clock.
The hardware clock drifts significantly compared to NTP sources (minutes or even hours per month).
Time drift will break:
- Cluster synchronization (CPHA/CCP timestamps)
- VPN tunnels (IKE relies on time windows)
- Log correlation in SmartConsole/SMS
- Certificates validity
- Forensics/auditing

So the hardware clock is only a bootstrap fallback, not a long-term alternative.

3. What you could do if NTP is not available

Short-term workaround: Set the time manually on all cluster members + SMS (like you did). Make sure they are very close (within a second or two).
Medium-term: Use an internal stratum-1/stratum-2 NTP server in your infra, even if isolated from the internet. Many orgs run an internal NTP server that syncs to GPS or an upstream source.
Last-resort hack: You could schedule a cron job to periodically sync the system clock to the hardware clock (hwclock --hctosys), but this is not supported and won’t solve drift — you’d just be reinforcing a drifting clock.

Re: FW Hardware Datetime instead of NTP-settings

Bob_Zimmerman — Mon, 15 Sep 2025 21:09:56 GMT

It depends. Some syscalls reference the RTC directly, others reference one of a number of software clocks the system maintains. Most commands will use the kernel's main software clock, as the system RTC is generally less accurate.

And speaking of accuracy, most servers which don't discipline their software clocks against NTP gain or lose as much as a minute per day. I have several mechanical watches with less drift. Servers' clocks are really, really bad, and NTP papers over the problem. Rather than not using NTP, you should use multiple NTP servers with known behavior when handling large offsets. NTP servers from reputable sources should not be able to hand out a time that far off of real TAI. If they have significant clock disagreements, they should go to stratum 16 and make an admin fix the problem.

Re: FW Hardware Datetime instead of NTP-settings

Grigoriy — Tue, 16 Sep 2025 04:00:42 GMT

Thank you for the detailed explanation.

Re: FW Hardware Datetime instead of NTP-settings

the_rock — Tue, 16 Sep 2025 11:01:43 GMT

Well, its nothing really, I just copied what AI showed, haha.

Andy

Re: FW Hardware Datetime instead of NTP-settings

Grigoriy — Tue, 16 Sep 2025 11:06:12 GMT

Checkpoint AI?)

Re: FW Hardware Datetime instead of NTP-settings

the_rock — Tue, 16 Sep 2025 11:07:52 GMT

Chatgpt lol

Re: FW Hardware Datetime instead of NTP-settings

Grigoriy — Tue, 16 Sep 2025 11:40:16 GMT

Hello,

Let's suppose that Checkpoint FW synchronizes from NTP stratum 1-4 - everything is ok and works like charm.

But at some moment of time NTP changes it's stratum to 16 - What would happen with FW in this case? Would it change it's synchronization to system time?

Re: FW Hardware Datetime instead of NTP-settings

Bob_Zimmerman — Tue, 16 Sep 2025 13:29:11 GMT

NTP clients will not synchronize to a server at stratum 16. The firewall will run on its local clock, not synchronized to anything. If all NTP servers report stratum 16, it's effectively the same as not having any configured NTP servers.