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

# sk39180 - Why does Phase II renegotiation sometimes fail between Netscreen and Check Point VPNs?

| Property | Value |
|----------|-------|
| Solution ID | sk39180 |
| Date Created | 2009-04-14 |
| Last Modified | 2010-12-29 |
| Technical Level | General |

## Symptoms

- You have a site to site VPN with a Netscreen firewall. The VPN works correctly until Phase II is renegotiated, after Phase II the VPN no longer works. A temporary workaround to the problem is setting up a continuous ping from one of the servers on the remote site to one of the local servers, this works correctly because Phase II is not renegotiated.   

<br />

<br />

Running packet captures on the servers on both sites shows that without the ping, after Phase II is renegotiated, the rem

## Solution

RFC2408 defines the use of the Commit bit in VPN communications.

C(ommit Bit) (1 bit) - This bit is used to signal key exchange synchronization. It is used to ensure that encrypted material is not received prior to completion of the SA establishment. The Commit Bit can be set (at anytime) by either party participating in the SA establishment, and can be used during both phases of an ISAKMP SA establishment. However, the value MUST be reset after the Phase I negotiation. If set, the entity which did not set the Commit Bit MUST wait for an Informational Exchange containing a Notify payload (with the CONNECTED Notify Message) from the entity which set the Commit Bit. In this instance, the Message ID field of the Informational Exchange MUST contain the Message ID of the original ISAKMP Phase II SA negotiation. This is done to ensure that the Informational Exchange with the CONNECTED Notify Message can be associated with the correct Phase IISA. The receipt and processing of the Informational Exchange indicates that the SA establishment was successful and either entity can now proceed with encrypted traffic communication. In addition to synchronizing key exchange, the Commit Bit can be used to protect against loss of transmissions over unreliable networks and guard against the need for multiple re-transmissions.  

<br />

NOTE: It is always possible that the final message of an exchange can be lost. In this case, the entity expecting to receive the final message of an exchange would receive the Phase II SA negotiation message following a Phase I exchange or encrypted traffic following a Phase II exchange. Handling of this situation is not standardized, but we propose the following possibilities. If the entity awaiting the Informational Exchange can verify the received message (i.e. Phase II SA negotiation message or encrypted traffic), then they MAY consider the SA was established and continue processing. The other option is to retransmit the last ISAKMP message to force the other entity to retransmit the final message. This suggests that implementations may consider retaining the last message (locally) until they are sure the SA is established.

The key to the problem seems to be a mismatch in the commit bit in Phase II of the VPN negotiation which may be due to a bug in the Netscreen. This is implied at the following page:

<http://www.isp-planet.com/technology/vpn/netscreen_eval2.html>

Where it is mentioned that to correctly configure a VPN between Netscreen and Nokia, it was necessary to "change commit bit handling to pair with Nokia."  

<br />

<br />

You may try the following 2 commands on the Netscreen device and retest the traffic:

**unset ike responder-set-commit
unset ike initiator-set-commit**

This has resolved the issue for some other customers.  

<br />

<br />

What these command do:  

<br />

<br />

**initiator-set-commit** : When the security device performs as an IKE initiator, sets the commit bit in the ISAKMP header. The party who sends the last message in the exchange does not use the new IPSec SA until it receives confirmation from the other party.  

<br />

<br />

**responder-set-commit** : Directs the security device to set the commit bit in the ISAKMP header when the device acts as an IKE responder. The peer that sends the last message in the exchange does not use the new IPSec SA until it receives information from the other peer.  

<br />

<br />

Root Cause:   

<br />

<br />

1. When commit-bit is set, Netscreen only installs the incoming key but not outgoing key when negotiation succeeds. The outgoing key is wrongly marked as active.  

<br />

<br />

2. Netscreen expects to receive connected notify but responder didn't send it, and Netscreen keeps resending the last packet.  

<br />

<br />

3. The Netscreen's outgoing key is wrong, to be active but the time not refreshed so it is regarded as expired. When expired, Netscreen marks the incoming key to be inactive as well.  

<br />

<br />

4. When resending the last packet it reaches the maximum retry number, Netscreen install the saved outgoing key. So we would see there is outgoing key active, incoming key all zero.

Juniper may have patches for the Netscreen products so that the above commands are not necessary.

---

# 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