UTM9 => Checkpoint IPSec S2S VPN

Hi,
I established an IPSec Site2Site VPN between our UTM and a Checkpoint Firewall. 
Both sides are using networks (not hosts) to be encrypted.
local: 10.33.86.0/24  remote: 172.20.250.0/24
The tunnel works, I can reach IPs in remote network 172.20.250.0/24
but the remote network can't reach IP's in my local network 10.33.86.0/24

This is the corresponding error message:

2013:01:03-18:14:38 fw-1 pluto[24905]: "S2S_1" #12: cannot respond to IPsec SA request because no connection is known for 10.33.86.5/32===***.***.x.2[***.***.***.2]...***.***.***.4[***.***.***.4]===172.20.250.10/32
2013:01:03-18:14:38 fw-1 pluto[24905]: "SS2S_1" #12: sending encrypted notification INVALID_ID_INFORMATION to ***.***.***.4:500

To work around this issue I added the host 10.33.86.5/32 to our local networks and 172.20.250.10/32 to the remote networks. As result, all IPs in 10.33.86.0/24 were reachable from remote side.
We compared everything 10 times. Tunnels between 2 Astaro UTMs are working as expected.
Does anybody have an idea about this?
Cheers
Thomas

This seems to be the usual Checkpoint problem.

Checkpoint has it's own philosophy how to include the defined networks into the requested SAs

I have the problem that some of our customers (networks 10.xx.yy.0/24) try to open an SA with 10.0.0.0/8 or with 10.xx.yy.zz/32
The SA only connects when the request comes from my side.

I myself don't know Checkpoint, but some specialists told me, this unwanted sub-/superneting can only be repaired with command line scripts.

Please tell me which IP is your local and remote gateway IPs?

I'm facesing same problem as you and adding local and remote networks does not help me [:(]

I only added 10.33.86.5/32, which is the UTM's internal interface IP, to the policy. So there are now 10.33.86.0/24 and 10.33.86.5/32 entered.
Regards
Thomas

Hi everyone,

I´m new on this community so excuse me if I post something wrongly.

I´m finding the same issue discussed on this thread of several years ago and I´m really interested on finding a solution.

The remote device is a Checkpoint and the problem is that remote hosts can´t reach local hosts, like for someone at the begining of this thread. Let me show some screenshots:

And from the remote side:

About the INVALID_MESSAGE_ID, this is an example of several days ago:

2019:08:06-09:54:54 asg220 pluto[16211]: "S_VPN_xxx_yyy" #97425: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x61462fd7 (perhaps this is a duplicated packet)

2019:08:06-09:54:54 asg220 pluto[16211]: "S_VPN_xxx_yyy" #97425: sending encrypted notification INVALID_MESSAGE_ID to 217.x.y.65:500

Many thanks in advance and best regards,

Antonio

Hola Antonio and welcome to the UTM Community!

Your IKE Phase 1 timeout is different than the selection on the Checkpoint, 21600 vs. 360.

You presently have both DPD and NAT-T disabled.  It's rare that you don't want NAT-T enabled.  Try with both enabled.  These selections in the UTM should match those in the Checkpoint.

Just looking at two lines from the IPsec log is too few.  Since all 120 IPsec SAs are established, I'm confused about what problem you're seeing.

Cheers - Bob