Hi Gilles, > Mon, 2018-06-04 23:04 09[KNL] received a XFRM_MSG_ACQUIRE > Mon, 2018-06-04 23:04 09[KNL] XFRMA_TMPL > Mon, 2018-06-04 23:04 09[KNL] XFRMA_MARK > Mon, 2018-06-04 23:04 09[KNL] creating acquire job for policy > 192.168.0.30/32[udp/ipsec-nat-t] === 5.79.71.212/32[udp/ipsec-nat-t] with > reqid {1}
This triggers a CREATE_CHILD_SA exchange, which the other peer never answers (check the log there to find out why), eventually causing the destruction of the SA: > Mon, 2018-06-04 23:04 09[ENC] <VPN|1> generating CREATE_CHILD_SA request 7 [ > SA No KE TSi TSr ]> ... > Mon, 2018-06-04 23:07 04[IKE] <VPN|1> giving up after 5 retransmits > ... > Mon, 2018-06-04 23:07 04[IKE] <VPN|1> IKE_SA VPN[1] state change: ESTABLISHED > => DESTROYING Then due to dpdaction=restart the SA is recreated. Actually, two CHILD_SAs are created (because of the queued CREATE_CHILD task). Strangely, the peer now responds to this additional CREATE_CHILD_SA request, but your updown script can't actually handle this duplicate CHILD_SA properly. To avoid the unnecessary and problematic acquire you have to fix the routes (or iptables rules) so that the source address is correct once the virtual IP is installed (as you can see above the physical IP is used for some packets routed via VTI device and that triggers an acquire because the IPsec policy is only for the virtual IP). Regards, Tobias