Who rated this post

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.