Remote Access VPN & Site-to-Site tunnels broken (“invalid cookie” / SA desync) after upgrade

[MrDazanaCom]

Appliance Type: Quantum Spark (locally managed)
Previous version: R81.10.15 – stable
Upgraded to: R81.10.17 
Deployment Mode: Locally Managed

---

Issue Summary

After upgrading from R81.10.15 → R81.10.17, both Remote Access VPN (Mobile Access clients) and Site-to-Site VPNs began repeatedly dropping and re-negotiating.
Reverting back to R81.10.15 immediately restores stable operation.

Typical loop seen in the logs:

VPN tunnel test failure caused a tunnel deletion on peer <SITE> (xxx.xxx.xxx.xxx) Phase1 Received Notification from Peer: invalid cookie A VPN tunnel is created on <SITE> (xxx.xxx.xxx.xxx)

The same pattern repeats every few seconds.
Remote Access users cannot complete Phase 1 — they hang during IKE negotiation.

Suspected Related Changes in R81.10.17

1. SMBGWY-17136 – CRL/OCSP validation updated to HTTP/1.1

   “Updated CRL and OCSP validation in Remote Access VPN, Site-to-Site VPN, and HTTPS Inspection to use HTTP/1.1 instead of HTTP/1.0. Ensures compatibility with DigiCert’s new requirements and prevents certificate validation failures.”

    Possible impact:

   • If outbound HTTP/1.1 traffic to CRL/OCSP responders (e.g. DigiCert) is blocked, proxied, or inspected, certificate validation may fail.

   • The gateway aborts IKE Phase 1, logs ‘invalid cookie’, and restarts negotiation.

2. SMBGWY-12630 – IKE SA handling change

   “IKE SA information is now stored in the kernel only after the authentication exchange completes.”

   Possible impact:

   • Stricter SA state tracking can expose peers that expect pre-auth SA behavior.

   • Half-open or resumed connections (common for mobile clients) now fail → “invalid cookie” or SA desync messages.

3. SMBGWY-16556 – Third NTP Server Option

   • May introduce time skew if new NTP source (time.google.com) differs from existing ones → invalid cert validity or OCSP responses.

4. SMBGWY-16544 – VIP/Cluster IP Advertising

   • Could briefly advertise physical IPs after reboot, confusing VPN peers.

---

Environment

• Remote Access: Check Point Mobile 

• Site-to-Site: AES-128 SHA256

• No proxy – direct Internet connectivity

• NTP verified correct before upgrade

---

Tests Performed

• Verified PSK / certs unchanged.

• Cleared all SAs via gui

• No upstream inspection or NAT changes.

• Full stability restored immediately upon rollback to R81.10.15.

---

Questions for the Community

1. Has anyone else seen Remote Access VPN fail after the HTTP/1.1 revocation-check change (SMBGWY-17136) ?

2. Are there any known hotfixes or SKs addressing “invalid cookie” / SA desync after upgrading to R81.10.17 ?

3. Is there a way to disable CRL/OCSP validation temporarily in locally managed mode for testing?

4. Would a full SA flush on both peers be sufficient to adapt to the new IKE SA handling logic, or is configuration alignment required?

---

Workaround

• Rolling back to R81.10.15 restores stable RA and S2S VPN operation.

• On R81.10.17, even after clearing all SAs and re-initiating, tunnels continue to flap with “invalid cookie.”

---

Request

If anyone has:

• encountered similar RA/S2S breakage post-upgrade,

• applied a fix or hotfix, or

• has insight into SMBGWY-17136 / 12630 behavior in R81.10.17,

please share your findings or any relevant SK article references (e.g. sk183884 or related).

thanks