> Source: [sk143512](https://support.checkpoint.com/results/sk/sk143512)

# sk143512 - VPN tunnels to 3rd party VPN client experience intermittent outages

| Property | Value |
|----------|-------|
| Solution ID | sk143512 |
| Date Created | 2018-12-27 |
| Last Modified | 2022-04-05 |
| Technical Level | General |
| OS | Gaia |

## Symptoms

- * An IKE v1 VPN tunnel is established with a native VPN client of a Windows 2008R2 server. However, at some point the tunnel stops passing traffic. Then, after a 5 minute outage renegotiates, passing traffic again.
* A VPN debug shows that that Check Point gateway initiates a tunnel key renegotiation (IKE Phase 2) that the remote peer agrees to. The remote peer immediately sends an SPI delete notification, and initates a new tunnel key renegotiation, that the Check Point peer agrees to. After that, there is a traffic outage.
* TCPdump shows that the Check Point peer sends packets encrypted with the SPI that was renegotiated during the first renegotiation, while the remote peer is not responding to the traffic.
* In *vpnd.elg* you might see error messages similar to:

  <br />

  `[vpnd PID ...]@hostname[DATE TIME] fwisakmp_delete_peer_sa: no 10.10.10.10,7542335e in outbound_SPI `

  `[vpnd PID ...]@hostname[DATE TIME] fwisakmp_delete_my_sa: 7542335e not found in inbound_SPI `

  (Where `10.10.10.10` is the IP of the remote peer, and `7542335e` is the SPI ID that was negotiated during the Check Point peer initiated tunnel key renegotiation)

## Cause

Following an SPI renegotiation, the Check Point gateway delays using the newly negotiated SPI for 300 ms to account for network lag. If an SPI delete notification is received in that window (between SPI being negotiated and SPI starting to be used), SPI delete has no effect. As a result, from the Check Point peer perspective, now there are two SPIs that are negotiated to the remote peer, while from the perspective of the remote host, there is only one.

The Microsoft 2008R2 server will only trust the SPIs that it proposed, which is what causes it to immediately send an SPI delete and re-negotiate the SPI.

Additionally, according to Microsoft support, "*for security reasons*", the Windows 2008R2 server does not send any notifications about unknown SPIs back to the originator, so there is no information available for the Check Point peer to select a different SPI.

## Solution

[Contact Check Point Support](https://www.checkpoint.com/support-services/contact-support/) to get a Hotfix for this issue.   
A Support Engineer will make sure the Hotfix is compatible with your environment before providing the Hotfix.   
For faster resolution and verification please collect [CPinfo](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk92739) files from the Security Management and Security Gateways involved in the case.

---

# Agent Instructions

This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products.

## Navigating This Knowledge Base

- **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt)
- **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml)
- **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}`
- **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content