IPSec VPN between Checkpoint and Cisco ASA

[taib_charkaoui]

Hi All,

im having really tought time establishing inbound connectivity from a third party Cisco ASA to my perimeter Checkpoint firewall. I am using R.76 and not R.80

I have an existing VPN created that permits outbound access from my internal servers to a 3rd party server.

The source of the Outbound traffic (FROM internal server to 3rd Party server) is hidden behind a single static NAT IP address. This access works.

My issue is establishing traffic Inbound (FROM 3rd party server to local internal server).

Traffic from the 3rd party is destined for a hide address that i translate to the real IP address of my internal server.

I can see the VPN attempt to establish and then get an error : "encryption Fail Reason: Received a cleartext packet within an encrypted connection".

I've done the usual troubleshooting and this error usually means that the encryption domains on either side do not match, however from what i can see they do.

Under the topology section of the gateway i have the VPN domains manually defined and include all the subnets that will be permitted to go through the VPN from my side, including the NAT addresses.

And under the VPN settings for the destination i have the subnet of the destination 3rd party servers.

Is there something i am missing, below are the things i've tried:-

• checked encryption domains on both sides, they appear to match
• checked VPN tunnel sharing to "one vpn tunnel per subnet pair"
• checked VPN type to meshed

After each time i went on to the CLI of the gateway and cleared both IPSec and IKEs for the IPSec gateway and no change: outbound from us to them works, but they cannot initiate an inbound connection to a server i have control of.

any help is greatly appreciated, and i can provide additional detail if required.

thanks.

[PhoneBoy]

I would use a tcpdump or fw monitor to validate whether you are, in fact, receiving packets from the remote site in plaintext.

If you are, the misconfiguration is on the other side. 

See also: Debugging Site-to-Site VPN

While I'm not aware of any specific issues in R76 related to this, keep in mind R76 (unless it's R76SP) is no longer supported.

You should look at upgrading to a supported version.

[taib_charkaoui]

Thanks for the response.

if i do a TCP dump i can check that there is traffic coming from the source subnet (the 3rd party).

But there shouldnt be anything particularly complicated in configuring an IPSec VPN to allow Inbound as opposed to outbound only traffic right?

The issue is if i am going to go back to the 3rd party to tell them their config needs amending i need, to be sure.

thanks again

[PhoneBoy]

If you see anything in the tcpdump that looks like it comes from hosts behind the VPN Endpoint (e.g. SSH as shown in your log entry) that means the remote end is not encrypting the traffic.

That can only be fixed on the remote end.

[taib_charkaoui]

Hi Dameon - so i did the TCPDump and could see traffic coming in from the 3rd party peer, as per the existing encryption domain on my side, so that is what is confusing me:-

1. traffic is coming from 10.199.3.96/28 as per the encryption domain configured on under the VPN gateway on my checkpoint firewall.
2. the local VPN encryption domain includes both the NAT hide address the 3rd party is trying to get to and the real address of the server that the NAT hide address is being translated to.

below is the detail shown in the packet when the vpn is setting up.

And finally i've attached a picture of the order of packets taken from smartview tracker, with the packets marked with a padlock showing the setup of the VPN, and then the drop notification, and the repeat of this after each attempt

so it looks like the encryption domains are correct, 

appreciate the assistance Dameon

[PhoneBoy]

It would helpful if you pasted the exact output from tcpdump that you're seeing.

The only thing you should be seeing there is IKE and IPsec traffic from the peer.

[taib_charkaoui]

So below is the TCPdump capture, i see when i ask the 3rd party to initiate traffic.

The 10.199.3.97 address is the source address that the 3rd party is coming from (FYI this is also a nat'd address as we cannot see their real ip addresses)

The 10.199.2.11 address is the NAT address on my side that i have hidden the real ip address of my server behind.

[PhoneBoy · Accepted solution]

This is unencrypted traffic, as the error messages were suggesting.

(Well, ok, SSH is technically encrypted but it's not IPsec)

This means the problem is on the remote end.

[taib_charkaoui]

Hi Dameon, this is what i thought.

Potentially their end had different encryption domains and i was trying to match them by changing config on my side, but if they are not encrypting the traffic in the first place then there shouldnt be anything i can do.

I will get back to them and press for them to re-look at things. in the meantime i will mark your last answer as correct.

many thanks for your assistance.