FortiGate suddenly won't accept any IPsec Phase 1 proposals from FortiClient

[LeadTogether]

Yesterday, out of the blue, our FortiGate 500E stopped accepting any client IPsec phase 1 proposals from our FortiClients.  I quadruple checked the settings on FortiClient, FortiClient EMS, and the FortiGate and nothing has changed.  No versions have changed either.  I verified that that proposals being sent by FortiClient and received by the FortiGate using diag debug, and multiple proposals match what is configured, but none of them are being accepted.

I opened a case with FortiNet support and am awaiting a reply.  In the meantime, I'm curious if anyone else in the community has faced this and how you solved it.

FortiGate: 7.4.8

FortiClient: 7.2.9

FortiClient EMS: 7.2.10

2025-08-06 16:29:40.813149 ike V=root:0:f4964d4586eabba5/0000000000000000:1235631: negotiation failure
2025-08-06 16:29:40.813171 ike V=root:Negotiate ISAKMP SA Error:
2025-08-06 16:29:40.813184 ike V=root:0:f4964d4586eabba5/0000000000000000:1235631: no SA proposal chosen

VPN config on FortiGate:

config vpn ipsec phase1-interface
edit "v4-PSK-IKEv2"
set type dynamic
set interface "x1"
set ike-version 2
set peertype any
set net-device disable
set mode-cfg enable
set ipv4-dns-server1 ######
set ipv4-dns-server2 ######
set proposal aes128-sha1 aes256-sha256
set dpd on-idle
set dhgrp 5
set eap enable
set eap-identity send-request
set nattraversal forced
set assign-ip-from name
set ipv4-name "IPsec_Tunnel_Addr1"
set save-password enable
set client-auto-negotiate enable
set client-keep-alive enable
set psksecret ENC ######
set dpd-retryinterval 60
next
end

Excerpt from FortiClient EMS VPN settings:

<ipsec_settings>
<remote_networks>
<network>
<addr>0.0.0.0</addr>
<mask>0.0.0.0</mask>
</network>
<network>
<addr>::/0</addr>
<mask>::/0</mask>
</network>
</remote_networks>
<dhgroup>5</dhgroup>
<key_life_type>seconds</key_life_type>
<key_life_seconds>43200</key_life_seconds>
<key_life_Kbytes>5200</key_life_Kbytes>
<replay_detection>1</replay_detection>
<pfs>1</pfs>
<use_vip>1</use_vip>
<virtualip>
<type>modeconfig</type>
<ip>0.0.0.0</ip>
<mask>0.0.0.0</mask>
<dnsserver>0.0.0.0</dnsserver>
<winserver>0.0.0.0</winserver>
</virtualip>
<proposals>
<proposal>AES128|SHA1</proposal>
<proposal>AES256|SHA256</proposal>
</proposals>
</ipsec_settings>

[AEK]

If nothing has changed on FGT/FCT/EMS, then probably something has changed on the network. Also check if something has changed on ISP router or from ISP side.

[LeadTogether · Accepted solution]

Thanks to help from FortiNet support, we found the problem.  AEK was correct about something changing on the network, but it took a while for the effect to appear... the device that the firewall was using for NTP  was moved about a month ago.  The clock finally skewed enough to disrupt the SAML authentication.  We couldn't see any SAML failures, but the debug logs that FortiNet support ran revealed the problem.

FW-Prime # diagnose vpn ike log filter rem-addr4 199.111.20.245

FW-Prime # diagnose debug application ike -1
Debug messages will be on for 30 minutes.

FW-Prime # diagnose debug application fnbamd -1
Debug messages will be on for 30 minutes.

FW-Prime # diagnose debug application eap_proxy -1
Debug messages will be on for 30 minutes.

FW-Prime # diagnose debug application samld -1

FW-Prime # diagnose debug enable

Here are the entries I noticed while the tech was scrolling through the output:

__samld_sp_login_resp [847]: Clock skew tolerance: 15

__samld_sp_login_resp [852]: Clock skew issue.
samld_send_common_reply [91]: Code: 5, id: 1147753, pid: 431, len: 53, data_len 37
samld_send_common_reply [99]:     Attr: 22, 12, )h
samld_send_common_reply [99]:     Attr: 23, 25, Undefined error.
samld_send_common_reply [119]: Sent resp: 53, pid=431, job_id=1147753.