“If an IPSec Site-to-Site VPN drops every 3,600 seconds on the dot, the issue is not ISP internet congestion—it is an IKE Phase 2 lifetime or Perfect Forward Secrecy (PFS) re-keying mismatch. Multi-vendor VPNs require 100% cryptographic parameter alignment.”

In May 2015, during my tenure as Technical Specialist at Wipro, we were escalated a persistent P1 incident for a major financial client.

The client operated a critical cross-border site-to-site IPSec VPN tunnel connecting a Checkpoint R77.30 gateway at corporate headquarters with a partner financial clearinghouse running a Cisco ASA 5520 firewall.

The tunnel processed automated, continuous payment settlement transactions 24 hours a day.

And every single hour—exactly 3,600 seconds after establishing—the VPN tunnel dropped dead for 45 seconds.

---

The 3,600-Second Clockwork Outage

During the 45-second outage, active financial batch transmissions failed with "Connection Timed Out" errors.

Automated monitoring paged the security on-call team at 1:00 AM, 2:00 AM, 3:00 AM, and 4:00 AM every single night.

The client’s internal network operations team spent two weeks chasing ghost ISP packet loss. They opened escalation tickets with international telecom carriers, assuming intermediate internet routers were flapping.

The telecom carriers returned clean line tests. Internet routing was fine.

The clockwork 3,600-second timing of the drops proved it wasn’t a physical wire problem—it was a software cryptographic renegotiation failure.

---

The Mess: The SPI Mismatch Teardown

I logged into the Checkpoint Security Gateway CLI via Expert Mode and activated raw IKE debug logging:

# Activating Checkpoint Raw IKE Debugging
vpn debug ikeon
tail -f $FWDIR/log/ike.elg | grep -i "SPI\|mismatch\|rekey"

I waited for minute 60 of the connection cycle.

At 3,600 seconds, ike.elg recorded the failure sequence:

# Checkpoint ike.elg Debug Log Output at Minute 60:
[IKEv1] Initiating Phase 2 Rekeying for Peer 202.71.10.5 (SPI: 0x8f4a2100)
[IKEv1] Received Phase 2 Notification from Peer: Delete SA (SPI: 0x8f4a2100)
[IKEv1] Error: Remote Peer Rejected New Phase 2 Proposal (PFS Group Mismatch!)
[IKEv1] Tearing down IKE SA and re-establishing Phase 1 from scratch...

The root cause was a fundamental mismatch in how Checkpoint and Cisco ASA handled IKE Phase 2 Re-Keying:

1. Lifetime Mismatch: Checkpoint SmartDashboard was configured with a default Phase 2 (IPSec) lifetime of 3,600 seconds (1 hour), while the Cisco ASA was configured for an 8-hour lifetime (28,800 seconds).
2. PFS Group Mismatch: Checkpoint initiated Phase 2 re-keying at 3,600 seconds without specifying Perfect Forward Secrecy (PFS: Off), while the Cisco ASA enforced PFS Group 5 (1536-bit) on all Phase 2 proposal updates.

When Checkpoint generated a new Security Parameter Index (SPI) re-key request at minute 60, the Cisco ASA rejected the proposal because Checkpoint wasn’t offering PFS Group 5.

Instead of rejecting just the re-key request, the Cisco ASA issued a Delete SA command, tearing down both IKE Phase 1 and Phase 2 tunnels completely!

The 45-second outage was the time required for both gateways to negotiate IKE Phase 1 from scratch, re-exchange Diffie-Hellman keys, and re-establish Phase 2 SAs.

---

The Solution: 100% Cryptographic Parameter Synchronization

We permanently resolved the hourly drops by aligning all Phase 1 (ISAKMP) and Phase 2 (IPSec) parameters identically across both Checkpoint SmartDashboard and Cisco ASA ASDM.

# Multi-Vendor IPSec Cryptographic Parameter Matrix

| Parameter                | Phase 1 (ISAKMP SA)       | Phase 2 (IPSec SA)           |
| ------------------------ | ------------------------- | ---------------------------- |
| **Lifetime**             | 86,400 Seconds (24 Hours) | **28,800 Seconds (8 Hours)** |
| **Encryption Algorithm** | AES-256                   | AES-256                      |
| **Hash Algorithm**       | SHA-256                   | SHA-256                      |
| **Diffie-Hellman / PFS** | **Group 5 (1536-bit)**    | **Group 5 (1536-bit)**       |

Checkpoint SmartDashboard Configuration Fix

1. Open SmartDashboard -> Edit VPN Community -> Phase 2 Properties.
2. Set IPSec Security Association Lifetime to 28800 seconds.
3. Check Use Perfect Forward Secrecy (PFS) -> Set to Group 5 (1536-bit).

# Cisco ASA Matching Crypto Map Configuration
crypto map OUTSIDE_MAP 10 set ikev1 transform-set ESP-AES-256-SHA
crypto map OUTSIDE_MAP 10 set pfs group5
crypto map OUTSIDE_MAP 10 set security-association lifetime seconds 28800

Hitless In-Service Re-Keying

When both gateways match Phase 2 lifetimes (28,800s) and PFS Group 5:

• Checkpoint initiates Phase 2 re-keying at hour 7.5 (before the 8-hour timer expires).
• The Cisco ASA accepts the new SPI proposal seamlessly in the background.
• The new SPI becomes active before the old SPI is deleted—delivering 100% hitless, zero-downtime in-service re-keying.

---

The Impact

• Zero Periodic Outages: Completely eliminated the 3,600-second hourly VPN drops across the cross-border payment tunnel.
• Hitless Re-Keying: Achieved 100% hitless Phase 2 re-keying every 8 hours without packet drops or session resets.
• Zero 3:00 AM Pager Alerts: Restored 24/7 continuous payment processing stability for financial clearing operations.

Key Takeaway

Align IKE Phase 1 and Phase 2 Rekey Parameters Exactly Across VPN Gateways.

Never rely on default VPN parameters when connecting multi-vendor security gateways. Mismatched Phase 2 lifetimes and Perfect Forward Secrecy (PFS Groups) will cause the receiving gateway to reject SPI re-key requests and tear down active tunnels. Explicitly synchronize Phase 1 (86,400s) and Phase 2 (28,800s / PFS Group 5) settings across all endpoints.

---

Architecture and decisions: mine. Debugging sessions at odd hours: mine. AI assistance: structure, syntax, first draft. — Sachin