[strongSwan] problems with charon in 4.4.1
schuldei+strongswan at spotify.com
Thu May 26 12:51:44 CEST 2011
On Wed, May 25, 2011 at 8:49 AM, Andreas Schuldei
<schuldei+strongswan at spotify.com> wrote:
> now i uploaded new logs from taylor and aldona. the two dropped their
> SA sometimes after 2011-05-24T21:48:21 (that is the last good SA
> negotiation i can see in the logs) and didnt manage to establish a new
> could someone please look at the logs and tell me if i can do anything
> about this failure (by choosing different config options)? The
> configuration files are unchanged since my first mail.
> please find the log files at
> they are smaller this time, and the timestamp might make it easier, too. :-)
yesterday i changed (per the suggestions on irc) the ipsec.conf to say
reauth=no, to make the connections less prone to reauthentication
isssues (and also switched to transport mode). Then i restarted
everything and also extended the testbed a little, so that we have 23
machines sending random traffic to each other through ipsec
continuously. (->253 host-to-host connections :-)
i uploaded new log files of a failure now, which centers around fiona.
aldona, alejandra, alvina, amber and annmarie failed to re-establish
their SAs to fiona. annmarie for example set up its last SA at 21:37
and then stopped talking to fiona altogether. other traffic to other
hosts goes on as before.
please check out
as well as their IPsec config files that are now generated with this template:
plutostart=no # pluto is used for IKEv1
ikelifetime=3h # strongSwan default
lifetime=1h # strongSwan default
margintime=9m # strongSwan default
keyingtries=%forever # strongSwan default
mobike=no # mobike is used for NAT traversal
type=transport # should work just as good as tunnel, but
reauth=no # recommended so that SAs are rekeyed, not
# Begin connection section
# For all connections, the peer with the host name
# that is first in a lexicographical sorting
# is selected as the initiator of the connection.
#for $peer in $peers
rightid="C=SE, O=Spotify, CN=$peer.name"
regarding the remnants of xfrm policy after /etc/init.d/ipsec stop: is
that a sign for the cleanup of charon at shutdown gone wrong? i also
see that the xfrm kernel modules are still heavily used (with a usage
count of ~60, on some machines) when charon was stopped and no SAs are
active any more. how can i see with lsof (or similar tools) what
userspace (or kernel) stuff uses it?
More information about the Users