[strongSwan] Charon fails after recovering from crash

[Brian Sanders]

I have multiple strongswan machines, and I randomly have noticed all
tunnels on them have failed.  Running ipsec statusall shows everything
looks normal, but no SA's are built.  I have tried changing the auto=start,
auto=route, and some dpd settings hoping to make them recover with no luck.

Looking back at logs, it seems to have died at some point (received signal
11) and been restarted automatically.  Problem being that after being
restarted it errors and can not build SA's.  Therefore when the tunnels
time out, they never come back.

I have found this post from 2011 that seems to explain exactly my same
problem.  Problem being the only reply was asking him to run 4.5.3 and
attach GDB

https://lists.strongswan.org/pipermail/users/2011-August/006521.html

As this post suggests, doing a kill -11 on the process can exactly
replicate my problem.  The process dies, and is re-started.  Once this
happens no new SA's will be created (even though the current ones will be
used for the time being).  I have tried running an ipsec reload, and that
appears to allow new SA's at first, but I have seen this not work or fail
after a short time.  So far I have been doing a full ipsec restart to
rectify the situation.  So now I have a process watching for this error and
restarting strongswan.  That guarantees a few dropped packets as the old
tunnels are destroyed and new ones created.  This is really not what I
want, but it is the best I have right now.

My version reported from ipsec is:
Linux strongSwan U4.5.2/K3.2.0-29-generic

I see that 5.03 is available, but this is the version in my package
management system already.  If someone knows that a newer version has fixed
this issue (either the segfault OR the inability to operate after
restarting) I could try upgrading.

If anyone has had this issue, or found a fix, I would greatly appreciate
any assistance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20130726/529bf2e3/attachment.html>