[strongSwan] "sending keep alive" seems breaking VPN connection

[Gilles Printemps]

Hi Tobias,
Thanks for this analysis.

Following your comment, it seems the issue comes first for "Hide.me" which
is not answering correctly to the "CREATE_CHILD_SA" request. Unfortunately,
I cannot have access to their log but I can raise a ticket to their support.
   - Does it mean that if they fix this issue, I will not lose anymore the
connection on my side?

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?

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).

Regards,
Gilles





On Tue, Jun 5, 2018 at 10:06 AM, Tobias Brunner <tobias at strongswan.org>
wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20180605/36fd51f1/attachment.html>