A utility's NOC FortiGate has phase 1 configured with an 86400-second key lifetime for its tunnel to a substation, while the substation's older FortiGate still has phase 1 set to 28800 seconds. Both sides use matching encryption and authentication proposals. What is the most likely outcome?
Select an answer to reveal the explanation.
Short Explanation
A lifetime mismatch isn't like a mismatched encryption algorithm — the peers don't have to agree on it to talk in the first place. They just end up rekeying whenever the shorter of the two timers runs out, so the substation's more frequent 28800-second value effectively sets the pace for the whole tunnel.
Full Explanation
IKE phase 1 lifetime is a locally configured timer that controls when each peer initiates a rekey, not a value both sides must match to complete negotiation the way encryption, authentication, and Diffie-Hellman group proposals do; a mismatch here does not prevent the security association from forming. In practice, whichever peer's timer expires first triggers the rekey, so with the substation set to 28800 seconds and the NOC set to 86400 seconds, the tunnel effectively rekeys roughly every eight hours, governed by the shorter value, rather than waiting for the NOC's longer setting. This differs fundamentally from a genuine proposal mismatch (mismatched encryption, hashing, or DH group), which does prevent phase 1 from ever completing, so treating a lifetime difference the same way overstates its impact. The tunnel does not simply adopt the NOC's longer value and ignore the substation, since rekeying is peer-initiated rather than centrally arbitrated. Nor does the tunnel stop rekeying altogether; IKE continues to rekey automatically on whichever schedule triggers first, requiring no manual daemon restart. An operational check is to review the IPsec phase 1 logs on both FortiGates around the shorter interval and confirm a rekey event occurs roughly every 28800 seconds without any drop in tunnel status.