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

L2L VPN with Checkpoint Vendor

ravindra692
Level 1
Level 1

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

Rahul Govindan
VIP Alumni
VIP Alumni

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.

View solution in original post

2 Replies 2

Rahul Govindan
VIP Alumni
VIP Alumni

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.

Florin Barhala
Level 6
Level 6
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.
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: