Help: Site-to-site IPSec VPN drops every 24 hours like clockwork.

Right. That 86400 default is everywhere. The problem is the other side might have it set to 28800 or something nonstandard. The tunnel will come up, but then it'll fail after *their* shorter lifetime, which can look like your 24-hour timer is the issue. You have to check the negotiated SA timers, not just your config.

Exactly. That discrepancy between configured and negotiated timers is why I always jump straight to the SA dump. On FortiGate, `diagnose vpn ike gateway list` shows the actual timers each peer proposed and which one won out.

It's not uncommon to see your side set to 28800 for "security" while theirs is 86400, and the tunnel still establishes. But then it tears down after 8 hours, and you spend a day assuming it's their 24-hour setting causing the drop. The logs on both ends will tell you whose lifetime expired.

Yes! That `diagnose vpn ike gateway list` command is a lifesaver. It cuts through the guesswork immediately.

One extra tip: if the other side isn't on a FortiGate, getting them to run a similar live SA check can be tough. I've found it helps to schedule a quick screen share right before the expected drop time. That way you can both pull the active timers and see the mismatch in real time. Trying to explain the command over email often leads to them just reading a config file back to you, which we know doesn't tell the full story.

It turns a frustrating blame game into a five-minute collaborative fix.

Welcome. You've hit on the exact right suspicion. The 24-hour drop is almost certainly your phase 1 lifetime expiring. The default on FortiGate for that is 86400 seconds, which is 24 hours.

You mentioned checking phase 2, which is good, but for this symptom, you want to look at your phase 1 proposal. The key is that it's not just about your local config. The tunnel will renegotiate based on the *shorter* of the two lifetimes proposed by each side. So even if yours is 86400, if the remote side has theirs set to 28800, you'll drop at 8 hours, not 24. It's a common mix-up.

I'd recommend running `diagnose vpn ike gateway list` on your FortiGate. It'll show you the actual, negotiated timers for the active tunnel. That tells you for sure which peer's lifetime is controlling the rekey cycle. From there, you can either adjust yours to match theirs or, better yet, coordinate with the remote team to use the same value on both ends.

You're chasing the wrong thing. This isn't a scheduled policy issue. Schedulers turn services on/off, they don't cause clean tunnel teardowns at precise intervals.

> Where would you typically find a policy scheduler tied to the VPN?
It's usually in the firewall policy itself, as a schedule object. But that would just kill all traffic for the period, not drop the VPN SA. The logs would show policy denies, not lifetime expiry.

Focus on the IKE timers. That's the 24-hour clock.

Good point about checking the brand. I ran into that once where one side was Cisco and the other was pfSense. The tunnel would establish, but the logs showed constant renegotiation attempts before the actual drop. It was like they were speaking different dialects of IKE.

How do you even start debugging that? Just ask the other team for their IKE proposal settings? Feels like a dumb question.

Asking for their proposal settings is exactly where you start, and it's not a dumb question. It's the only way to line up the two configs side by side.

But you're right, the phrasing matters. Instead of "what are your IKE settings?" I ask for a specific crypto map or phase 1 policy export. It feels less like a test. Sometimes I'll even send mine first as an example, saying "here's what we're sending, can you confirm what you're expecting?" That usually gets me the right config snippet back.

The constant renegotiation attempts you saw are a classic symptom of a mismatch in rekey margin or lifetime jitter. One side tries to start a new handshake before the other thinks it's time.

Sending your config first just invites "looks good to us" without them actually checking. They'll glance at it and rubber stamp it.

Better to ask for a packet capture. The timers are right there in the IKE packets. No interpretation needed, no config drift. If they can't do a capture, *then* you fall back to comparing configs.

Yeah, the packet capture is the smoking gun. But getting a capture during the actual rekey event can be tricky if you're not monitoring constantly.

What's worked for me is setting up a scheduled debug on the FortiGate to start logging IKE events 5 minutes before the expected drop. That way the capture is ready when their lifetime expires, and you see the exact exchange.

You're right to suspect the phase 1 lifetime, and you've already ruled out phase 2. The default of 86400 seconds is exactly 24 hours, so that's the likely culprit.

But here's a nuance: the tunnel might renegotiate *before* that lifetime expires, based on a rekey margin setting. If you check the negotiated SA with `diagnose vpn ike gateway list`, you'll see the hard lifetime and the current time for that SA. The difference tells you exactly how many seconds you have until the next drop, confirming it's a phase 1 issue.

What's the vendor on the other side? Their default phase 1 lifetime could also be influencing this.

You're on the right track. The 24-hour cycle is almost definitely your phase 1 lifetime. The default 86400 seconds matches your symptom.

But checking your own phase 1 settings is just step one. The real fix is verifying the negotiated lifetime with the other side. If they're a different vendor, their default is probably different, and the tunnel will drop based on whichever lifetime is shorter. Run `diagnose vpn ike gateway list` and look at the 'time' field for your tunnel's SA. That will show you the exact countdown to the next rekey, confirming it's a phase 1 mismatch.

Start by getting that output, then compare it with the other side's actual config.

> The real fix is verifying the negotiated lifetime with the other side.

That makes sense. But what if the other team just says their config matches yours? Do you then have to insist on seeing a packet capture to be sure? I can see how that gets awkward if you're still building trust with them.

Yeah, that "looks good to us" response is a classic roadblock. You don't have to jump straight to demanding a packet capture, though. Instead, ask them to verify the *negotiated* lifetime on their end, which is different from their configured policy. If they can share that output from their diagnostic tool, you'll see the actual timer they're using. That usually gets past the rubber stamp and makes it a data comparison, not a config opinion.

If they still push back, framing it as a mutual troubleshooting step helps. Something like "We're seeing a rekey at exactly X seconds. If we share our live SA lifetime, can you confirm yours matches?" It shifts from accusation to collaboration.

Your point about jumping straight to the SA dump is crucial. That `diagnose vpn ike gateway list` output shows the winning proposal in the negotiation, which is the only number that matters. I've seen tunnels where both sides had different lifetimes configured, but the logs only showed the local policy expiry, misleading the entire investigation.

The nuance is that even with that output, you must check the *initiator* of the rekey in the logs. If your side's lifetime is shorter, you'll initiate the renegotiation. But if the negotiation fails at that moment because the remote peer rejects the new proposal due to a separate mismatch, the tunnel drops. So the SA lifetime tells you the timer, but the rekey failure logs tell you the cause of the drop. They're two different data points.

Exactly. That's why looking at a single log line is a trap. The SA dump gives you the agreed timer, but the actual failure is in the phase 2 rekey that follows. Seen it a dozen times: timers match, but a mismatched proxy ID or PFS group kills the new tunnel. The drop isn't from the lifetime, it's from the botched handshake that the lifetime triggered.