Table of Contents
Scenario 1: Site to Site VPN between Check Point and Cisco fails with "encryption failure: no response from peer"
Scenario 2: Traffic over VPN tunnel stops passing intermittently due to incorrect Static NAT configuration
Scenario 3: VPN between Check Point Security Gateway and Cisco ASA/PIX fails: "No valid SA"
There are quite a number of scenarios, in which you may encounter the "Encryption failure: no response from peer" error. The scenarios that we have encountered and dealt with are detailed below.
Title: Site to Site VPN between Check Point and Cisco fails with "encryption failure: no response from peer"
OS: Gaia, SecurePlatform
- SmartView Tracker shows the error message: "Encryption failure: No response from peer" when Check Point Security Gateway initiates a ping, or sends other traffic to the Cisco encryption domain.
- Both parties are getting a ping timed out error when they ping their peer's encryption domain.
- Cisco side is able to initiate traffic and get a successful response from Check Point firewall.
- tcpdump on the external interface (interface leading to the Internet) of the Check Point Security Gateway shows: "X.X.X.X tell Y.Y.Y.Y where X.X.X.X is the IP of the Cisco Peer and Y.Y.Y.Y is the IP of the Check Point external interface"
Note: This scenario solution deals with a specific situation which sometimes occurs when a user makes a common mistake while creating a static route on the Check Point VPN gateway.
The most relevant symptom is the last one, where it describes seeing ARP requests leaving the Check Point gateway trying to resolve a MAC address of the Cisco peer's IP. Seeing this is how you know the Check Point gateway has an incorrect static route in its routing table. It should not ARP for the Cisco device's IP at all, as it is not on the Check Point gateway's local subnet.
Wrong routing configuration on the Check Point Security Gateway.
For example, the networks for the Cisco encryption domain are configured to use the external interface of the Check Point Security Gateway as a gateway, instead of as a Next Hop to the Check Point Security Gateway.
When adding a static route in GAIA, you have two choices under "add gateway": "IP Address" or "Network Interface"
- Choosing "IP Address" and typing an IP address tells the system that in order to reach the destination and subnet of the route, send the traffic to this IP address.
- Choosing "Network Interface" and selecting one of the gateway's interfaces from the drop-down list, tells the gateway that this network is local to the interface selected, so that in order to reach the destination and subnet of the route, do not route the traffic, ARP for it instead.
This scenario is trying to describe the situation where the problem is that the Check Point admin added a route to the Cisco peer and/or to the Cisco Peer's VPN domain and for next hop he did #2 above, when he should have done #1 and specified his Internet router's IP as the next hop gateway for the route.
Verify the routing on the Check Point Security Gateway. Make sure that the routes are pointing to the Next Hop gateway instead of the interface.
- Run either the netstat -rn (Expert mode) or show route (clish mode) command to see the route configuration.
Title: Traffic over VPN tunnel stops passing intermittently due to incorrect Static NAT configuration
- Traffic over VPN tunnel stops passing intermittently.
- SmartView Tracker logs show:
- encryption failure: no response from peer
- encryption fail reason: Packet is dropped because there is no valid SA
- Kernel debug ('
fw ctl debug -m fw + conn drop nat link') shows that Security Gateway was not able to create a symbolic link in the Connections Table for the IKE packets (UDP port 500) due to a previous existing link. As a result, IKE packets are dropped:
[-- Stateful VM outbound: Entering (.) --];
;Before VM: <X.X.X.X:500 -> Y.Y.Y.Y:500 IPP 17> ...
;fw_xlate_match: conn=<X.X.X.X:500 -> Y.Y.Y.Y:500 IPP 17>;
;fw_xlate_match: cache hit!;
;fwconn_init_links: Creating links (outbound). One way links=0, Replies from any=0;
;fwconn_set_links_outbound: create link srs_i <dir 0, Y.Y.Y.Y:500 -> X.X.X.X:500 IPP 17> -> <dir 1, X.X.X.X:500 -> Y.Y.Y.Y:500 IPP 17>(0x6);
;h_slink: link already exists;
;fwconn_set_link: failed to set the link (-3);
;fwconn_set_link: Not overriding previous link (previous entry is not a closing TCP conn nor a dynamic routing conn);
;FW-1: fwconn_set_links_outbound: fwconn_set_link(srs_i) failed <dir 0, Y.Y.Y.Y:500 -> X.X.X.X:500 IPP 17> -> <dir 1, X.X.X.X:500 -> Y.Y.Y.Y:500 IPP 17>;
;FW-1: fwconn_init_links: Failed to set server-side links;
;FW-1: fw_conn_post_inspect: fwconn_init_links failed. Dropping packet;
;fw_log_drop: Packet proto=17 X.X.X.X:500 -> Y.Y.Y.Y:500 dropped by fw_conn_post_inspect Reason: fwconn_init_links (OUTBOUND) failed;
;After VM: <X.X.X.X:500 -> Y.Y.Y.Y:500 IPP 17> (len=...) ;
;VM Final action=DROP;
A symbolic link in the Connections Table was created in regards to the Static NAT that had been configured. When external VPN connections are attempted, they are dropped because there already exists a symbolic link.
Review the configuration in SmartDashboard for any Static Network Address Translation (NAT) that has been configured for the Security Gateway's IP Address / Cluster's Virtual IP Address.
Upon finding the relevant Static NAT configuration, either change this to an IP address other than the Security Gateway's IP Address / Cluster's Virtual IP Address, or change from a Static NAT to Hide NAT.
Title: VPN between Check Point Security Gateway and Cisco ASA/PIX fails: "No valid SA"
- "Packet is dropped because there is no valid SA - please refer to solution sk19423 in SecureKnowledge Database for more information" log in SmartView Tracker.
- VPN between Check Point Security Gateway and Cisco Pix fails.
- SmartView Tracker logs may display the following error messages:
- "No valid SA"
- "Encryption failure: packet is dropped as there is no valid SA"
- "Encryption failure: No response from peer"
- "No proposal chosen"
- Unable to delete IPSec SA (to reset the tunnel) using "vpn tu". Rebooting the gateway does not correct this issue.
During IKE Quick Mode Exchange, the VPN daemon negotiates IPSec Security Associations (SAs) with the VPN partner site. If negotiations fail and the exchange does not complete, the VPN daemon has no IPSec SAs to send to the VPN kernel. When VPN kernel waiting for IPsec SA expires (usually 60 seconds) this error message is sent.
VPN between Check Point Security Gateway and Cisco Pix may fail because Cisco Tunnel Sharing is configured for host based VPN, while Check Point Tunnel Sharing is usually configured for network based VPN.
VPN between Check Point Security Gateway and Cisco Pix may also fail due to a mismatch in the settings between the two devices. For instance, if the Check Point Security Gateway proposes a network of 192.168.1.X/24, but the Cisco Access list is setup for traffic from 192.168.X.X/16, the connection will fail.
To resolve the issue where Cisco Tunnel Sharing is configured for host based VPN, while Check Point Tunnel Sharing is configured for network based VPN, proceed as follows:
- At the Cisco end, check the Crypto Map settings. Find out from the ACLs, if there is a host based VPN setup or a network based VPN setup.
- On SmartDashboard, edit the Cisco Interoperable Device object defined on SmartDashboard. Select 'Network Objects > Others > Interoperable Device > VPN > Advanced'. Uncheck 'Support key exchange for subnets'.
Note: For NGX R60 and higher, select 'Network Objects > Interoperable Devices > IPSec VPN > VPN Advanced'. Under "VPN Tunnel Sharing", select "Custom Settings" and specify "One VPN tunnel per each pair of hosts".
- After completing this procedure, initiate traffic from the source PC. You should be able to see an encrypt in SmartView Tracker.
To resolve the issue due to a mismatch in the settings between the two devices, proceed as follows:
- Use the 'Tunnel Management' option in the VPN community (under 'Manage > VPN Communities... > (Meshed/Star) Community Properties'). Make sure the VPN Tunnel Sharing options are set correctly for the specific scenario.
- Additionally, modify the Cisco Access List to reflect what the Check Point Security Gateway is proposing.
To resolve the issue of being unable to delete IPSec SA using tunnelutil or vpn tu
- Change the encryption method to "IKEv1" only.
For more detailed information on various issues related to interoperability of Check Point NGX Gateways with the VPN solutions of other vendors, please refer to the VPN-1 VPN Interoperability guide.
- This SK aggregates sk100656, sk101306, and sk31803