Why does the IPsec tunnel break/reconnect on phase 2?

Question

VPN

Hello!

On my side there is a gateway:

Ubuntu 14.04.6 LTS (GNU/Linux 3.13.0-170-generic x86_64)
Linux strongSwan U5.1.2/K3.13.0-170-generic
Интернет: белый статический IP адрес XXX.XXX.XXX.XXX на eth0
Локалка: 192.168.1.0/24 на eth1

On the other hand, from what I know:

Шлюз Check Point
Интернет: Белый статический IP адрес YYY.YYY.YYY.YYY
Локалка: 192.168.2.0/24

Agreed with the administrator of the remote gateway settings, raised IPsec in tunnel mode, connection settings on my part:

ipsec.conf

# ipsec.conf - strongSwan IPsec configuration file

# basic configuration

config setup
  # strictcrlpolicy=yes
  # uniqueids = no
        charondebug="cfg 2, dmn 2, ike 2, net 2"


conn XXX-YYY
      ikelifetime=86400s
      keylife=3600s
      keyexchange=ikev1
      dpdaction=restart
      dpddelay=35s
      dpdtimeout=300s
      fragmentation=yes
      left=XXX.XXX.XXX.XXX
      leftsubnet=192.168.1.0/24
      leftsourceip=XXX.XXX.XXX.XXX
      leftid=XXX.XXX.XXX.XXX
      right=YYY.YYY.YYY.YYY
      rightsubnet=192.168.2.0/24
      rightsourceip=YYY.YYY.YYY.YYY
      rightid=YYY.YYY.YYY.YYY
      ike=aes128-aes256-modp2048
      esp=md5
      aggressive=no
      type=tunnel
      authby=secret
      auto=start

ipsec.secrets

%any %any : PSK "asdasdasdasdasdasdasdasdasdasdasd"

iptables-save

*mangle
:PREROUTING ACCEPT [4822648:2854366635]
:INPUT ACCEPT [3219152:1821493584]
:FORWARD ACCEPT [1603049:1032789622]
:OUTPUT ACCEPT [3546772:1745389895]
:POSTROUTING ACCEPT [5104463:2775353165]
COMMIT
# Completed on Tue Feb 18 13:18:20 2020
# Generated by iptables-save v1.4.21 on Tue Feb 18 13:18:20 2020
*nat
:PREROUTING ACCEPT [179552:15735267]
:INPUT ACCEPT [208160:10860138]
:OUTPUT ACCEPT [80640:4841663]
:POSTROUTING ACCEPT [12:677]
-A PREROUTING ! -d 192.168.1.0/24 -i eth1 -p tcp -m multiport --dports 80 -j REDIRECT --to-ports 3128
-A PREROUTING ! -d 192.168.1.0/24 -i eth1 -p tcp -m multiport --dports 443 -j REDIRECT --to-ports 3129
-A PREROUTING -p tcp -m tcp --dport 1194 -j DNAT --to-destination 192.168.1.52:1194
-A PREROUTING -p tcp -m tcp --dport 3389 -j DNAT --to-destination 192.168.2.225:3389
-A PREROUTING -p tcp -m tcp --dport 934 -j DNAT --to-destination 192.168.1.1:934
-A PREROUTING -p tcp -m tcp --dport 1723 -j DNAT --to-destination 192.168.1.2:1723
-A POSTROUTING -s 192.168.1.0/24 -o eth0 -m policy --dir out --pol ipsec -j ACCEPT
-A POSTROUTING -s 192.168.1.0/24 ! -d 192.168.1.0/24 -j SNAT --to-source XXX.XXX.XXX.XXX
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Tue Feb 18 13:18:20 2020
# Generated by iptables-save v1.4.21 on Tue Feb 18 13:18:20 2020
*filter
:INPUT DROP [72256:7049702]
:FORWARD DROP [35554:2221204]
:OUTPUT ACCEPT [3546772:1745391766]
-A INPUT -i eth0 -p icmp -j ACCEPT
-A INPUT -p esp -j ACCEPT
-A INPUT -p udp -m udp --dport 4500 -j ACCEPT
-A INPUT -p udp -m udp --dport 500 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 934 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -j DROP
-A INPUT -i eth0 -p tcp -m tcp --dport 81 -j DROP
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m multiport --dports 80 -j ACCEPT
-A INPUT -p tcp -m multiport --dports 3128:3130 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -s 127.0.0.1/32 -j ACCEPT
-A INPUT -s 192.168.1.1/32 -j ACCEPT
-A INPUT -s 192.168.1.0/24 -i eth1 -p tcp -m multiport --dports 53 -m conntrack --ctstate NEW -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j ACCEPT
-A INPUT -s 192.168.1.0/24 -i eth1 -p tcp -m multiport --dports 934 -m conntrack --ctstate NEW -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j ACCEPT
-A INPUT -s 192.168.1.0/24 -i eth1 -p icmp -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 1194 -j ACCEPT
-A INPUT -i eth1 -p tcp -m tcp --dport 3389 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 934 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 1723 -j ACCEPT
-A INPUT -j ULOG
-A FORWARD -s 192.168.1.0/24 -p icmp -j ACCEPT
-A FORWARD -s 192.168.1.120/32 -j DROP
-A FORWARD -s 192.168.1.102/32 -j DROP
-A FORWARD -s 192.168.1.103/32 -j DROP
-A FORWARD -s 192.168.1.60/32 -j DROP
-A FORWARD -s 192.168.1.67/32 -j DROP
-A FORWARD -s 192.168.1.81/32 -j DROP
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -p tcp -m tcp --dport 1194 -j ACCEPT
-A FORWARD -p tcp -m tcp --dport 3389 -j ACCEPT
-A FORWARD -p tcp -m tcp --dport 934 -j ACCEPT
-A FORWARD -p tcp -m tcp --dport 1723 -j ACCEPT
-A FORWARD -i eth0 -o eth1 -p tcp -m multiport --dports 25,110,143,465,631,993,995,5121,6900 -j ACCEPT
-A FORWARD -i eth1 -o eth0 -p tcp -m multiport --dports 25,110,143,465,631,993,995,5121,6900 -j ACCEPT
-A FORWARD -i eth0 -o eth1 -p udp -m multiport --dports 25,53,110,143,465,631,993,995,5121 -j ACCEPT
-A FORWARD -i eth1 -o eth0 -p udp -m multiport --dports 25,53,110,143,465,631,993,995,5121 -j ACCEPT
-A FORWARD -s 192.168.1.101/32 -o eth0 -j ACCEPT
-A FORWARD -s 192.168.1.101/32 -o eth0 -j ACCEPT
-A FORWARD -s 192.168.1.7/32 -o eth0 -j ACCEPT
-A FORWARD -s 192.168.1.7/32 -o eth0 -j ACCEPT
-A FORWARD -s 192.168.1.2/32 -o eth0 -j ACCEPT
-A FORWARD -s 192.168.1.2/32 -o eth0 -j ACCEPT
-A FORWARD -s 192.168.1.5/32 -o eth0 -j ACCEPT
-A FORWARD -s 192.168.1.5/32 -o eth0 -j ACCEPT
-A FORWARD -j ULOG
COMMIT

Networks see each other, packets run, everything works:

ipsec statusall

Status of IKE charon daemon (strongSwan 5.1.2, Linux 3.13.0-170-generic, x86_64):
  uptime: 59 minutes, since Feb 13 18:41:17 2020
  malloc: sbrk 2433024, mmap 0, used 352080, free 2080944
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 22
  loaded plugins: charon test-vectors aes rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints pkcs1 pkcs7 pkcs8 pkcs12 pem openssl xcbc cmac hmac ctr ccm gcm attr kernel-netlink resolve socket-default stroke updown eap-identity addrblock
Virtual IP pools (size/online/offline):
  YYY.YYY.YYY.YYY: 1/0/0
Listening IP addresses:
  XXX.XXX.XXX.XXX
  192.168.111.1
Connections:
     XXX-YYY:  XXX.XXX.XXX.XXX...YYY.YYY.YYY.YYY  IKEv1
     XXX-YYY:   local:  [XXX.XXX.XXX.XXX] uses pre-shared key authentication
     XXX-YYY:   remote: [YYY.YYY.YYY.YYY] uses pre-shared key authentication
     XXX-YYY:   child:  192.168.1.0/24 === 192.168.2.0/24 TUNNEL
Security Associations (1 up, 0 connecting):
     XXX-YYY[12]: ESTABLISHED 4 minutes ago, XXX.XXX.XXX.XXX[XXX.XXX.XXX.XXX]...YYY.YYY.YYY.YYY[YYY.YYY.YYY.YYY]
     XXX-YYY[12]: IKEv1 SPIs: d1a95eb5e2361ab3_i abddab29cc4424f4_r*, pre-shared key reauthentication in 23 hours
     XXX-YYY[12]: IKE proposal: AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_2048
     XXX-YYY{1}:  REKEYING, TUNNEL, expires in 48 seconds
     XXX-YYY{1}:   192.168.1.0/24 === 192.168.2.0/24

Then every 35 seconds (dpddelay=35s) the following messages are spammed in syslog:

...
charon: 03[NET] received packet: from YYY.YYY.YYY.YYY[500] to XXX.XXX.XXX.XXX[500]
charon: 10[NET] received packet: from YYY.YYY.YYY.YYY[500] to XXX.XXX.XXX.XXX[500] (188 bytes)
charon: 10[IKE] received retransmit of request with ID 995476868, but no response to retransmit
charon: 03[NET] waiting for data on sockets
...

After 5 minutes (dpdtimeout=300s) phase 2 is aborted despite keylife=3600s. The connection immediately rises. For services like RDP, it is not critical, it does not reach the timeout, but if a file is copied between subnets, then copying is interrupted accordingly.

The log also contains "gate charon: 10[IKE] no matching CHILD_SA config found", i.e. As far as I understand, the demon swears that some settings between the client and the server do not match, it is not clear then why the connection is kept for 5 minutes.

Below is a syslog link with a complete cyclops from IPsec start to break.
Please indicate in which direction to dig!
https://pastebin.com/UCjZtukD

Answer 1

that expires in 48 seconds - is this how it should be? What is policy? strict, obey? I can also advise you to cut off the fuck dpd - I had no sense from him from the word at all.
Well, I immediately see an error:
received NO_PROPOSAL_CHOSEN error notify
If this is a log taken from your side, then that side tells you that it does not have cipher suites corresponding to at least one of those that you have in your proposal (proposal). Configure the connection to accept the settings that the other side gives - both the cipher suites and the connection time - at least to make sure that it is generally possible to link with this checkpoint.

Answer 2

Now I talked with the checkpoint administrator, as it turned out the connection status with the current firmware (75.20) is "Not connected", while he sees my network. Previously, we tested a tunnel with another checkpoint on firmware 77 and there was no such bug. I believe that the checkpoint within the established timings (dpd) tries to connect (although the connection is already established), drops after 5 minutes, connects and everything is in a circle. In addition, yesterday I set up a tunnel with the same strongswana settings to my home router, everything works perfectly. Apparently you need to wait until the checkpoint is updated.