Anyone else having VPN tunnel stability issues with Quantum 700 series?

I have been conducting a long-term performance and stability evaluation of a Check Point Quantum 710 appliance deployed in a hub-and-spoke VPN topology, serving as the primary security gateway for three branch offices. The primary metric of concern has been tunnel stability, specifically the frequency of Internet Key Exchange (IKE) renegotiations and the resulting impact on stateful firewall connections. My findings indicate a pattern of instability that does not align with the expected behavior for a device in this class, and I am seeking to determine if this is a localized configuration issue or a more widespread observation.

My environment is configured as follows:
* **Appliance:** Quantum 710 running R81.20.
* **Topology:** A main site (Quantum 710) with three satellite sites (various other vendors).
* **Tunnel Configuration:** IKEv2 with AES-256-GCM for encryption, SHA384 for integrity, and Diffie-Hellman Group 20. Perfect Forward Secrecy is enabled.
* **Dead Peer Detection:** Configured with aggressive mode set to 'periodic' with a 10-second interval and a 3-retry threshold.

The observed issue manifests as spontaneous IKE phase 2 rekey events, which subsequently cause a reset of the IPsec Security Associations. While the tunnels themselves do not fully drop, the re-establishment process interrupts any stateful connections (e.g., HTTPS, database links) traversing the tunnel at that moment. From my logging and `vpn tu` output, I have documented the following pattern over a 72-hour monitoring period:

```bash
Sample from vpn tu -s:
Tunnel-ID: 1f3a | Peer: 203.0.113.10 | Status: Active | IKE-Rekeys: 24 | IPSec-Rekeys: 142
Tunnel-ID: 2b5c | Peer: 198.51.100.45 | Status: Active | IKE-Rekeys: 19 | IPSec-Rekeys: 138
Tunnel-ID: 3d9e | Peer: 192.0.2.78 | Status: Active | IKE-Rekeys: 27 | IPSec-Rekeys: 155
```

This averages to an IKE rekey approximately every 3 hours per tunnel, and an IPsec SA rekey nearly every 30 minutes, far exceeding the configured lifetime values of 86400 seconds (24 hours) for IKE and 3600 seconds for IPsec. The rekeys are not correlated with high traffic load or CPU/memory utilization on the appliance, which consistently remains below 40% across all cores.

My troubleshooting steps to date have included:
* Validating NTP synchronization across all endpoints to rule out time-skew issues.
* Adjusting Dead Peer Detection from 'periodic' to 'always-on' and modifying intervals, with no appreciable change in stability.
* Disabling all threat prevention and IPS blades for a test window to eliminate the possibility of a security policy interfering with keepalive packets.
* Conducting a packet capture on the external interface, which confirmed the IKE INITIATOR messages are originating from our Quantum gateway unexpectedly, not from the peer.

The financial and operational impact is non-trivial. Each rekey event results in approximately 800ms-1200ms of packet loss. For persistent TCP connections, this triggers retransmissions and latency spikes. In a FinOps context, this instability has forced us to maintain redundant, costly MPLS circuits at the branches for critical applications, negating a significant portion of the projected cost savings from migrating to an IPsec SD-WAN model. The man-hours invested in troubleshooting also contribute to the total cost of ownership.

I am particularly interested in feedback from others who may have deployed the Quantum 700 series in a similar capacity. Have you observed comparable tunnel stability metrics? Are there specific known issues with the cryptographic hardware acceleration or the IKE daemon in R81.20 that could precipitate this? Any detailed log analysis or `cpview` profiles highlighting similar behavior would be invaluable for comparison.