Почему происходит разрыв/переподключение IPsec туннеля на 2 фазе?

Question

[Sergx0]

Здравствуйте!

С моей стороны имеется шлюз:

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

С другой стороны, из того что мне известно:

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

Согласовали с администратором удаленного шлюза настройки, подняли IPsec в туннельном режиме, настройки соединения с моей стороны:

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

Сети друг дуга видят, пакеты бегают, всё работает:

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

Далее каждые 35 секунд (dpddelay=35s) в 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
...

Спустя 5 минут (dpdtimeout=300s) 2 фаза прерывается, несмотря на заданный keylife=3600s. Соединение моментально поднимается. Для служб вроде RDP не критично, дело до таймаута не доходит, но если происходит копирование файла между подсетями, то соответственно копирование прерывается.

В логе так же присутствует "gate charon: 10[IKE] no matching CHILD_SA config found", т.е. насколько я понимаю демон ругается на то, что какие то настройки между клиентом и сервером не совпадают, не понятно тогда почему 5 минут соединение держится.

Ниже по ссылке syslog с полным циклопом от запуска IPsec до разрыва.
Пожалуйста, укажите в какую сторону копать!
https://pastebin.com/UCjZtukD

Comments

[rionnagel]

Версия чекпоинта выше 80.10?

[Sergx0]

rionnagel, Сейчас установлена версия прошивки 75.20.50. На днях должны обновиться на более новую 77 (насколько я понял это последняя доступная прошивка под данное устройство).

Answer 1

[CityCat4]

то, что expires in 48 seconds - это так и должно быть? Чему равно policy? strict, obey? Могу еще посоветовать отрубить нахрен dpd - у меня от него толку не было от слова совсем.

Ну и вот я сразу ошибку вижу:
received NO_PROPOSAL_CHOSEN error notify

Если это лог, снятый с Вашей стороны, то та сторона сообщает Вам, что нет у нее шифронаборов, соответствующих хотя бы одному из тех, что есть у вас в предложении (proposal). Настройте соединение так, чтобы принять настройки которые отдаст та сторона - и шифронаборы и время соединения - хотя бы чтобы убедиться, что с этим чекпойнтом вообще в принципе возможно увязаться.

Comments

[Sergx0]

то, что expires in 48 seconds - это так и должно быть?

Да, установлен 1 час, просто копипаста такая получилась.

Ну и вот я сразу ошибку вижу:
received NO_PROPOSAL_CHOSEN error notify

Нюанс с несоответствием алгоритмов шифрования уже решен, данная ошибка больше не появляется, не в ней дело.

Чему равно policy? strict, obey?

Вот тут можно по подробнее, где посмотреть? На Strongswan wiki ничего толкового не нашел. Если речь о "strictcrlpolicy", то по идее равен "no" раз явно не указан.

В одном из обращений на вики strongswan'a вычитал:

It is well known that IKEv1 main mode with PSK authentication just does not work in NAT situations! Please switch to IKEv2 if the peer supports it or use certificate-based authentication.

Поэтому закралась мысль, что в iptables чего-то не хватает для корректной работы ikev1.

Answer 2

[Sergx0]

Сейчас пообщался с администратором чекпоинта, как выяснилось статус соединения с с текущей прошивкой (75.20) "Не подключено", при этом мою сеть он видит. Ранее тестировали туннель с другим чекпоинтом на 77 прошивке и там такого бага не было. Я так полагаю, чекпоинт в рамках установленных таймингов (dpd) пытается соединиться (хотя соединение уже установлено), дропает через 5 минут, соединяется и все по кругу. К тому же вчера поднял туннель с теми же настройками strongswana до домашнего роутера, все работает идеально. Видимо нужно ждать когда обновят чекпоинт.

Comments

[Sergx0]

Обновили чекпоинт до последней из доступных версий, что и решило все проблемы.