We have successfully set up a strongswan vpn on our network to communicate with Google Cloud VPN.Sometimes we leave it idle for a while, let's say a night, that's when the issue appear.If I try to ping from Google to our network, it doesn't work, no packets are transmitted.If I try to ping from our side to Google, it works, and then the ping which was blocked on Google side starts working fine.It looks like StrongSwan enters in sleep mode on our side and wakes up only when I manually ping out, not when receiving packets.But I can't find any option in the doc to fix this, has anyone got this issue and fixed it somehow?EDIT: there is no firewall on our side which could explain this behaviour and on google side we can only set the IP range allowed to go through the firewall, nothing else. But since it uses their own VPN service to communicate with our strongswan server, I strongly doubt it comes from them. Here is what ipsec status returns before the issue on our side: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/20Here is what ipsec statusall returns after: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 updownListening IP addresses:  192.168.17.205  79.xxx.xxx.xxxConnections:         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=restartSecurity 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/20And the ipsec.conf:config setupconn %default        ikelifetime=24h        keylife=8h        rekeymargin=9m        keyingtries=1        authby=psk        keyexchange=ikev2        mobike=no        esp=aes128gcm16-modp2048!        dpdaction=restartconn 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=startAnd on the logs from the google side I noticed that at the moment I send the ping test, it sends some requests to recreate CHILD_SA:creating rekey job for CHILD_SA ESP/0xxxxxxxxx/79.xxx.xxx.xxx  ...Once the CHILD_SA is established with its SPI the ping goes through.Though the ESP SPI didn't change before and after.I also see rekeying in 7 hours on ipsec statusall. Could it be the issue that during the night there is no activity during more than 7 hours?Here is charon log: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/20Mar 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 7dd6xxxxMar 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/20Mar 22 07:56:43 vpn07 charon: 05[IKE] sending DELETE for ESP CHILD_SA with SPI ce75xxxxxMar 22 07:56:43 vpn07 charon: 05[IKE] CHILD_SA closedAnd google logs: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 7dxxxxxxI  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 
Strongswan VPN not working unless pinging out manually
vpn;google cloud;strongswan
It looks like your Strongswan VPN client is behind a firewall or a NAT device which, after a moment of inactivity, drops the connection (it's probably UDP here, the term connection is not a good choice). Any incoming data belonging to that connection is then considered as invalid and is dropped (you may have a line about this in your FW/NAT device logs). Later, when you ping Google from the inside, your connection is re-established and your firewall/NAT device now considers again incoming data as valid.The solution is to prevent your firewall/NAT device from dropping the connection by ensuring a regular data stream (one UDP message every minute may be enough). Search for any keep-alive mechanism built in Strongswan and activate it.