<div dir="ltr">Hi Tobias,<div>Thanks for this analysis. </div><div><br></div><div>Following your comment, it seems the issue comes first for "Hide.me" which is not answering correctly to the "<span style="font-size:12.800000190734863px">CREATE_CHILD_SA" request. Unfortunately, I cannot have access to their log but I can raise a ticket to their support.</span></div><div><span style="font-size:12.800000190734863px">   - Does it mean that if they fix this issue, I will not lose anymore the connection on my side?</span><br></div><div><br></div><div>If it is not possible for them to change the behaviour of their VPN, you mentioned I may handle it on my side by fixing the route when the virtual IP is created. Can you provide more details?</div><div><br></div><div>Will this modification also prevent the communication to be destroyed?  Indeed, if my example, I mentioned only one lost of connection and the creation of a new one but this issue is an infinite loop (Means each 2-3 minutes, connection is not working anymore).</div><div><br></div><div>Regards,</div><div>Gilles</div><div><br></div><div><br></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 5, 2018 at 10:06 AM, Tobias Brunner <span dir="ltr"><<a href="mailto:tobias@strongswan.org" target="_blank">tobias@strongswan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Gilles,<br>
<br>
> Mon, 2018-06-04 23:04 09[KNL] received a XFRM_MSG_ACQUIRE<br>
> Mon, 2018-06-04 23:04 09[KNL]   XFRMA_TMPL<br>
> Mon, 2018-06-04 23:04 09[KNL]   XFRMA_MARK<br>
> Mon, 2018-06-04 23:04 09[KNL] creating acquire job for policy <a href="http://192.168.0.30/32[udp/ipsec-nat-t]" rel="noreferrer" target="_blank">192.168.0.30/32[udp/ipsec-nat-<wbr>t]</a> === <a href="http://5.79.71.212/32[udp/ipsec-nat-t]" rel="noreferrer" target="_blank">5.79.71.212/32[udp/ipsec-nat-<wbr>t]</a> with reqid {1}<br>
<br>
This triggers a CREATE_CHILD_SA exchange, which the other peer never<br>
answers (check the log there to find out why), eventually causing the<br>
destruction of the SA:<br>
<br>
> Mon, 2018-06-04 23:04 09[ENC] <VPN|1> generating CREATE_CHILD_SA request 7 [ SA No KE TSi TSr ]> ...<br>
> Mon, 2018-06-04 23:07 04[IKE] <VPN|1> giving up after 5 retransmits<br>
> ...<br>
> Mon, 2018-06-04 23:07 04[IKE] <VPN|1> IKE_SA VPN[1] state change: ESTABLISHED => DESTROYING<br>
<br>
Then due to dpdaction=restart the SA is recreated.  Actually, two<br>
CHILD_SAs are created (because of the queued CREATE_CHILD task).<br>
Strangely, the peer now responds to this additional CREATE_CHILD_SA<br>
request, but your updown script can't actually handle this duplicate<br>
CHILD_SA properly.<br>
<br>
To avoid the unnecessary and problematic acquire you have to fix the<br>
routes (or iptables rules) so that the source address is correct once<br>
the virtual IP is installed (as you can see above the physical IP is<br>
used for some packets routed via VTI device and that triggers an acquire<br>
because the IPsec policy is only for the virtual IP).<br>
<br>
Regards,<br>
Tobias<br>
</blockquote></div><br></div>