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

MrDazanaCom — Sun, 19 Oct 2025 21:00:13 GMT

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

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.
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.
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.
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

Has anyone else seen Remote Access VPN fail after the HTTP/1.1 revocation-check change (SMBGWY-17136) ?
Are there any known hotfixes or SKs addressing “invalid cookie” / SA desync after upgrading to R81.10.17 ?
Is there a way to disable CRL/OCSP validation temporarily in locally managed mode for testing?
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

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

_Val_ — Mon, 27 Oct 2025 13:01:59 GMT

Best is to open a support ticket with TAC.

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