Strongswan VPN не работает, если ping out вручную

Мы успешно настроили vpn strongswan в нашей сети для связи с Google Cloud VPN.

Иногда мы оставляем его без дела на какое-то время, скажем, на ночь, и тогда возникает проблема. Если я пытаюсь пинговать из Google в нашу сеть, это не работает, пакеты не передаются. Если я пытаюсь выполнить пинг с нашей стороны в Google, он работает, а затем пинг, который был заблокирован на стороне Google, начинает работать нормально.

Похоже, StrongSwan переходит в спящий режим на нашей стороне и просыпается только тогда, когда я вручную отправляю эхо-запрос, а не при получении пакетов. Но я не могу найти в документе ни одной опции, чтобы исправить это, есть ли у кого-нибудь эта проблема и как-то ее исправляли?

РЕДАКТИРОВАТЬ: на нашей стороне нет брандмауэра, который мог бы объяснить это поведение, а на стороне Google мы можем только установить диапазон IP-адресов, разрешенный для прохода через брандмауэр, и больше ничего.Но поскольку он использует свой собственный VPN-сервис для связи с нашим сервером strongswan, я сильно сомневаюсь, что он исходит от них.

Вот что возвращает статус ipsec перед проблемой на нашей стороне:

net-net[72]: ESTABLISHED 113 minutes ago, 79.xxx.xxx.xxx[79.xxx.xxx.xxx]...146.xxx.xxx.xxx[146.xxx.xxx.xxx]     
net-net{255}:  INSTALLED, TUNNEL, reqid 24, ESP SPIs: c5xxxxxx 4exxxxxx     
net-net{255}:   192.168.0.0/24 192.168.17.0/24 === 10.132.0.0/20

Вот что возвращает ipsec statusall после:

Status of IKE charon daemon (strongSwan 5.3.5, Linux 4.4.0-64-generic, x86_64):  
uptime: 22 days, since Feb 27 15:21:33 2017  
malloc: sbrk 2568192, mmap 0, used 370288, free 2197904  
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 11  
loaded plugins: charon aes agent attr connmark constraints dnskey fips-prf gcm md4 openssl pem pgp pkcs1 pkcs12 pkcs7 pkcs8 pubkey rc2 resolve revocation sshkey test-vectors x509 xcbc sha1 sha2 md5 gmp random nonce hmac stroke kernel-netlink socket-default updown

Listening IP addresses:  192.168.17.205  79.xxx.xxx.xxx
Connections:     
    net-net:  79.xxx.xxx.xxx...146.xxx.xxx.xxx  IKEv2, dpddelay=30s     
    net-net:   local:  [79.xxx.xxx.xxx] uses pre-shared key authentication     
    net-net:   remote: [146.xxx.xxx.xxx] uses pre-shared key authentication     
    net-net:   child:  192.168.17.0/24 192.168.0.0/24 === 10.132.0.0/20 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):     
    net-net[72]: ESTABLISHED 2 hours ago, 79.xxx.xxx.xxx[79.xxx.xxx.xxx]...146.xxx.xxx.xxx[146.xxx.xxx.xxx]     
    net-net[72]: IKEv2 SPIs: 0fd4efxxxxxx 17ed000axxxxxx*, pre-shared key reauthentication in 108 minutes     
    net-net[72]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048     
    net-net{255}:  INSTALLED, TUNNEL, reqid 24, ESP SPIs: c5b822fe_i 4ed83bd8_o     
    net-net{255}:  AES_GCM_16_128, 3916 bytes_i (47 pkts, 1020s ago), 3956 bytes_o (47 pkts, 1020s ago), rekeying in 7 hours     
    net-net{255}:   192.168.0.0/24 192.168.17.0/24 === 10.132.0.0/20

И ipsec.conf:

config setup

conn %default
        ikelifetime=24h
        keylife=8h
        rekeymargin=9m
        keyingtries=1
        authby=psk
        keyexchange=ikev2
        mobike=no
        esp=aes128gcm16-modp2048!
        dpdaction=restart
conn net-net
        left=79.xxx.xxx.xxx
        leftsubnet=192.168.17.0/24,192.168.0.0/24
        leftid=79.xxx.xxx.xxx
        leftfirewall=yes
        leftdns=xxx....
        right=146.xxx.xxx.xxx
        rightsubnet=10.132.0.0/20
        rightid=146.xxx.xxx.xxx
        auto=start

И в журналах со стороны Google я заметил, что в тот момент, когда я отправляю тест ping, он отправляет несколько запросов на воссоздание CHILD_SA:

"creating rekey job for CHILD_SA ESP/0xxxxxxxxx/79.xxx.xxx.xxx"  
...

Как только CHILD_SA устанавливается с его SPI, проверка связи проходит. Хотя ESP SPI не изменился ни до, ни после. Я также вижу смену ключей через 7 часов на ipsec statusall. Может быть проблема в том, что ночью нет активности более 7 часов?

Вот журнал харона:

Mar 22 07:56:43 vpn07 charon: 11[ENC] parsed CREATE_CHILD_SA request 223 [ N(REKEY_SA) SA No KE TSi TSr ]
Mar 22 07:56:43 vpn07 charon: 11[IKE] CHILD_SA net-net{255} established with SPIs c5b8xxxxxxx_o and TS 192.168.0.0/24 192.168.17.0/24 === 10.132.0.0/20
Mar 22 07:56:43 vpn07 charon: 11[ENC] generating CREATE_CHILD_SA response 223 [ SA No KE TSi TSr ]
Mar 22 07:56:43 vpn07 charon: 05[IKE] received DELETE for ESP CHILD_SA with SPI 7dd6xxxx
Mar 22 07:56:43 vpn07 charon: 05[IKE] closing CHILD_SA net-net{254} with SPIs ce7xxxx (95264 bytes) 7ddxxxxx (4885433 bytes) and TS 192.168.0.0/24 192.168.17.0/24 === 10.132.0.0/20
Mar 22 07:56:43 vpn07 charon: 05[IKE] sending DELETE for ESP CHILD_SA with SPI ce75xxxxx
Mar 22 07:56:43 vpn07 charon: 05[IKE] CHILD_SA closed

И журналы Google:

D  sending DPD request 
D  CHILD_SA closed 
D  received DELETE for ESP CHILD_SA with SPI cexxxxx 
D  parsed INFORMATIONAL response 224 [ D ] 
D  received packet: from 79.xxx.xxx.xxx[500] to 146.xxx.xxx.xxx[500] (76 bytes) 
D  sending packet: from 146.xxx.xxx.xxx[500] to 79.xxx.xxx.xxx[500] (76 bytes) 
D  generating INFORMATIONAL request 224 [ D ] 
D  sending DELETE for ESP CHILD_SA with SPI 7dxxxxxx
I  closing CHILD_SA vpn_79.xxx.xxx.xxx{33} with SPIs 7dxxxxx (5073648 bytes) cexxxxxx (95264 bytes) and TS 10.132.0.0/20 === 192.168.0.0/24 192.168.17.0/24  
I  CHILD_SA vpn_79.xxx.xxx.xxx{34} established with SPIs 4exxxxxx c5xxxxxx and TS 10.132.0.0/20 === 192.168.0.0/24 192.168.17.0/24  
D  handling HA CHILD_SA vpn_79.xxx.xxx.xxx{34} 10.132.0.0/20  === 192.168.0.0/24 192.168.17.0/24  (segment in: 1*, out: 1*) 
D  parsed CREATE_CHILD_SA response 223 [ SA No KE TSi TSr ] 
D  received packet: from 79.xxx.xxx.xxx[500] to 146.xxx.xxx.xxx[500] (476 bytes) 
D  sending packet: from 146.xxx.xxx.xxx[500] to 79.xxx.xxx.xxx[500] (620 bytes) 
D  generating CREATE_CHILD_SA request 223 [ N(REKEY_SA) SA No KE TSi TSr ] 
I  establishing CHILD_SA vpn_79.xxx.xxx.xxx{1} 
D  creating rekey job for CHILD_SA ESP/0xxxxxxx/79.xxx.xxx.xxx 
D  parsed INFORMATIONAL response 222 [ ] 
D  received packet: from 79.xxx.xxx.xxx[500] to 146.xxx.xxx.xxx[500] (76 bytes) 
D  sending packet: from 146.xxx.xxx.xxx[500] to 79.xxx.xxx.xxx[500] (76 bytes) 
D  generating INFORMATIONAL request 222 [ ] 
D  sending DPD request