Hi Anurag,
We have added reauth=no to the ipsec.conf and retested our scenario
once. We could observe from the tcpdump on the node triggering the
traffic that even now an INFORMATIONAL message (with Next Payload:
Delete) is sent just before IKE_SA re-keying [behaviour is same as
was with
Hi Tobias,
We agree with you that this delete may be for the CHILD_SA. We have tested a
couple of times again and it looks like the redundant CHILD_SA are not getting
created anymore. :)
We would still want to understand that what happens if I want the reauth to
happen [reauth=yes] each time
Hi Anurag,
We would still want to understand that what happens if I want the
reauth to happen [reauth=yes] each time for the IKE_SA. In such a
case there is always a possibility that during the downtime of the
IKE_SA, traffic matching the installed policies will trigger a new
CHILD_SA to be
Hi Tobias,
We have added reauth=no to the ipsec.conf and retested our scenario once. We
could observe from the tcpdump on the node triggering the traffic that even now
an INFORMATIONAL message (with Next Payload: Delete) is sent just before IKE_SA
re-keying [behaviour is same as was with
Hi Tobias,
Provided below is the ipsec.conf file used during one of the runs [in case it
helps in analysing the issue better]. As per the below conf file I assume that
reauth is set to yes, even though I do not set it explicitly. Can you please
confirm this?
# ipsec.conf
config setup
Hi Anurag,
As per the below conf file I assume that reauth is set to yes, even
though I do not set it explicitly. Can you please confirm this?
Yes, reauth=yes is currently the default. And by using auto=route you
created the same problem as recently discussed on this mailing list with
Anand
Hi Tobias,
Thanks a lot for the response.
We are looking into the possibilities of upgrading to the latest charon version
but it looks unlikely until we are able establish that the issue is really
linked to old the charon version.
In the mean time we have analysed the charon logs and have an
Hi,
We have encountered some issues while using StrongSwan charon on our Linux
server and would request you to help us out on this.
Setup:
1) We are using StrongSwan charon [Linux strongSwan 4.3.1] on our server
[we call it NODE A] to establish an IKEv2 IPSec tunnel with a Cisco
Hi Anurag,
1) We are using StrongSwan charon [Linux strongSwan 4.3.1]
Just let me tell you that we don't really like to support such old
releases. It would great if you could try if this issue is still
present in 4.6.2.
3) After around 600 sec. from the start, IKE_SA re-keying
