"Packet is dropped because there is no valid SA" log when Cluster drops packets
In the IPSO cluster and Check Point cluster environment, there can be a Quick Mode SA initiated also from the cluster side to the VPN client station and not just from the client side to the cluster.
Even though there is already an active IPSec SA, established by the client, the Check Point cluster sometimes wants to establish its own, corresponding IPSec SA. The SA is initiated when a return packet is handled by another cluster member than the one that handled the initial client IKE connection.
The Quick Mode SA from the cluster side is not necessarily established immediately, or automatically when the VPN client station connects. Whether the cluster initiates any Quick Mode SA, and the time when it happens, depends on the client traffic, and how the client sessions are allocated between the cluster members.
If the SA negotiation initiated from the cluster side fails for some reason, a situation can arise where part of the connections to the encryption domain work properly, but some of the connections fail. In this case, the logs show packets being dropped with the above error message.
If packets get dropped in an IPSO cluster, even though the VPN client connections have been properly established and are active, you should verify that there is nothing in the cluster configuration that blocks the outgoing Quick Mode negotiations.
Failures with the Quick Mode negotiations have been observed in the following situations:
- Rule base prevents outgoing connections from cluster. Check that the Implied Rules allow outgoing IKE connections. If the clients come over a NATed connection, check also the option "Accept outgoing packets originating from Gateway" in the Security Gateway Global Properties menu. With NATed connections, the source port in the client IKE session may vary, and when the cluster side initiates the IKE negotiation to the client port, the session is not matched with the implied IKE rule. Checking the option "Accept outgoing packets originating from Gateway" will let the IKE negotiation go through in this situation.
- NAT mapping expired in NAT device between the client and cluster. If the client address is NATed on the way to the cluster, the NAT mapping may already have expired in the NAT device, when the cluster initiates the Quick Mode negotiation. In this case, it is not possible to route the Quick Mode packet to the client and the packets will be discarded. To fix the problem, check the "Enable back connections" option in the Global Properties / Remote Access menu and update the site in the VPN client station. This option will maintain the NAT mapping of the client IKE session in the NAT device.
- Outgoing and incoming packets via different interface. When initiating the Quick Mode negotiation from the cluster side, packets may be routed via a different interface than the one through which the VPN client connections came (e.g VPN client connects via DMZ network to external cluster address, but the Quick Mode negotiation from cluster goes out with the DMZ cluster address, as the source address). Check that the source address in the cluster that initiated IKE Quick Mode packets is the same as the address which the VPN client stations connect to. If necessary, set the "ipsec_main_if_nat" property in objects_5_0.C to force the outgoing IKE packets to be sourced with the cluster main IP address.
It should be noted that the outgoing Quick Mode negotiations won't always fail in the above situations. The negotiation may succeed if the IKE udp virtual session, initiated by the VPN client station, is still active when the cluster initiates its Quick Mode negotiation (default 40 seconds).
Depending on the traffic pattern and how the sessions are assigned between the cluster members, the cluster initiated Quick Mode negotiation may sometimes succeed and sometimes fail, causing the packets to be dropped in a seemingly random fashion.
Imported from Nokia support database