Technical Tip: Workaround for Certificate based IPsec Authentication failure due to NTPSync failure caused by Incorrect time on Boot of FortiGate

bmuhammad · ‎08-08-2025

Description

The article describes a workaround for IPsec establishment failures where IPsec tunnels use certificate-based authentication, but the NTP servers are only accessible after the tunnels are established. If a FortiGate does not boot up with the correct time, the IPsec tunnels cannot be established because the NTP servers are not reachable, and the certificate validity fails.

Scope

FortiGate.

Solution

See below for a summary of the steps involved in this procedure:

Log the FortiGate Start Event ID
Use an Automation stitch that triggers on FortiGate start to manually set the FortiGate NTP servers to a public NTP server.
After the FortiGate obtains the correct system time by syncing with the public NTP servers, the certificates used in the IPsec tunnels should now be within the validity period and good to use for authentication.
After the IPsec tunnels gets established, run an automation stitch to delete the configured Public servers and have the FortiGate then reach out to the internal NTP servers for the NTP sync.

Step 1: The FortiGate should be logging Event ID 32009, which denotes 'FortiGate started'. This flag will be used as a trigger to initiate the automation stitch.
Additional details of this Event ID can be found in Log ID system start - FortiOS log message reference.

config log memory setting

set status enable

end

config log memory filter

config free-style

edit 1

set category event

set filter "logid 32009" <----- Event ID denotes FortiGate started

end

Step 2: Configure the Automation Action to use the Public NTP server and remove the Public NTP server after a delay.

config system automation-action

edit "Use_Public_NTP"

set action-type cli-script

set script "config system ntp

config ntpserver

edit 3

set server 129.6.15.28 <----- Public NTP server. The administrator can use other publicly available servers that match the security requirements.

set server 132.163.97.1 <----- Public NTP server. The administrator can use other publicly available servers that match their security requirements and is of their choosing.

unset source-ip

end"

set accprofile "super_admin"

set action-type cli-script

set script "config system ntp

config ntpserver

delete 3

delete 4

end

set source-ip 10.0.0.1 <----- This IP depends on what Interface or IP address the FortiGate Administrator uses for critical services. This IP is only for demonstration and may need to be adjusted by the administrator.

end"

set accprofile "super_admin"

Step 3: Configure the Automation-trigger utilizing the criteria set in Step 1.

config system automation-trigger

edit "FGT-Start"

set description 'Event FortiGate started'

set trigger-type event-based

set event-type event-log

set logid 32009

Step 4: Configure the automation Stitch to obtain NTP Sync and then remove the public NTP servers once the FortiGate has obtained the correct time.

config system automation-stitch

edit "GET_NTP_Sync"

set trigger "FGT-Start"

config actions

edit 1

set action "Use_Public_NTP"

set required enable

set action "Remove_Public_NTP"

set delay 900 <----- This is a timer for demonstration purposes only. The actual timer value can be configured by the FortiGate administrator.

set required enable

Pictorial depiction of Automation Stitch's workflow:

Depiction of automation stitch flow

Related documents:
Automation stitches - FortiGate 7.6.3 administration guide

Technical Tip: Workaround for Certificate based IPsec Authentication failure due to NTPSync failure caused by Incorrect time on Boot of FortiGate

You are leaving our website