cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
273
Views
0
Helpful
2
Replies
Beginner

L2L VPN with Checkpoint Vendor

Hello

 

I have a working VPN tunnel built between Cisco ASA firewall running ASA version 9.6 with one of our Vendor. The Vendor has checkpoint firewall on their end. We have recently added new traffic flows to this tunnel. When we are generating the traffic I can see the pkst encaps increasing on the ASA but the vendor is not seeing any traffic reaching their firewall.

 

Any help regarding this would be much appreciated.

 

ravi

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
VIP Advocate

Re: L2L VPN with Checkpoint Vendor

Apply a packet capture on the ASA's outside interface for ESP traffic. Ideally you should see traffic outbound to but nothing inbound from the peer ip address for the new SA (SPI should differ for each SA). This should prove that the ASA is not at fault. In many cases, vendor mis-configuration can send traffic into the wrong SA. The ASA should log this something similar to below:

 

%ASA-4-402116: IPSEC: Received an ESP packet (SPI= 0xAAAAAA, sequence number= 0x1F0) from x.x.x.x (user= testuser) to y.y.y.y.  The decapsulated inner packet doesn't match the negotiated policy in the SA.  The packet specifies its destination as z.z.z.z, its source as a.a.a.a, and its protocol as tcp.  The SA specifies its local proxy as y.y.y.y/255.255.255.255/udp/42246 and its remote_proxy as x.x.x.x/255.255.255.255/udp/0.

2 REPLIES 2
Highlighted
VIP Advocate

Re: L2L VPN with Checkpoint Vendor

Apply a packet capture on the ASA's outside interface for ESP traffic. Ideally you should see traffic outbound to but nothing inbound from the peer ip address for the new SA (SPI should differ for each SA). This should prove that the ASA is not at fault. In many cases, vendor mis-configuration can send traffic into the wrong SA. The ASA should log this something similar to below:

 

%ASA-4-402116: IPSEC: Received an ESP packet (SPI= 0xAAAAAA, sequence number= 0x1F0) from x.x.x.x (user= testuser) to y.y.y.y.  The decapsulated inner packet doesn't match the negotiated policy in the SA.  The packet specifies its destination as z.z.z.z, its source as a.a.a.a, and its protocol as tcp.  The SA specifies its local proxy as y.y.y.y/255.255.255.255/udp/42246 and its remote_proxy as x.x.x.x/255.255.255.255/udp/0.

Frequent Contributor

Re: L2L VPN with Checkpoint Vendor

Hi mate,
I ve been working with CP for a while now and I can tell you it can be very tricky in regard to 3rd party VPNs (as CP is calling this).

Packet capture on outside between your IP and VPN_CP_IP is a good start. We can resume onto the next step right after.