[strongSwan] problems with charon in 4.4.1

[Andreas Schuldei]

ipsec was started by puppet. that means that the connections are
initiated over an interval of about 30 min.
when i checked later on i discovered that some hosts did not get their
initial puppet trigger for some reason.
our physical nets are quite good, we dont see package loss or so
within our sites. between the sites (ash, lon, sto) we go through the
wild internet, and occasional connection issues could happen. they are
not the rule, though. all servers are "real" high powered servers,
none of them is to puny to get ipsec negotiations right on the first
try. :-)


On Mon, May 23, 2011 at 11:38 PM, Andreas Steffen
<andreas.steffen at strongswan.org> wrote:
> Hello Andreas,
>
> I just analyzed the first part of the alvina.ash.spotify.net log
> file and I see that of the 15 initiated IKE_SAs only 4 succeed in
> the first round. Are there connection problems to the other 11 hosts,
> are some of the peers not online yet or is the computing power of the
> hosts so small that they cannot handle more than 4 IKE_SAs without
> multiple retransmission rounds?
>
> Regards
>
> Andreas
>
> On 05/23/2011 08:14 PM, Andreas Schuldei wrote:
>> the charon log files for these four hosts are available for download here:
>> http://origin.scdn.co/u/wp/alvina.ash.spotify.net-charon.log.gz
>> http://origin.scdn.co/u/wp/annalise.ash.spotify.net-charon.log.gz
>> http://origin.scdn.co/u/wp/annmarie.ash.spotify.net-charon.log.gz
>> http://origin.scdn.co/u/wp/taylor.sto.spotify.net-charon.log.gz
>>
>>
>> On Mon, May 23, 2011 at 2:46 PM, Andreas Schuldei
>> <schuldei+strongswan at spotify.com> wrote:
>>> hi!
>>>
>>> I seem to be experiencing problems with charon in strongswan 4.4.1.
>>>
>>> One problem is that charon sometimes failes to reinitiate SAs once
>>> they expire. I set up a testbed with 17 hosts to reproduce and track
>>> down the issue, as it takes some time for it to manifest.
>>>
>>> since every host has several connections to the other peers in this
>>> ipsec setup, it is tricky to see what log entry is caused by which
>>> connection. how can single out the log entries from those
>>> affected/failing connections? how can i get a verbose status dump from
>>> charon showing what it thinks the status is of all the connections it
>>> keeps track of?
>>> i dont want to attache 16M of log files here. please advice what parts
>>> are useful, and i would appreciate tips on how to extract those.
>>>
>>> the hosts that i currenly see problems with are up:
>>>
>>> root at taylor:~# fping annalise.ash.spotify.net annmarie.ash.spotify.net
>>> alvina.ash.spotify.net
>>> annalise.ash.spotify.net is alive
>>> annmarie.ash.spotify.net is alive
>>> alvina.ash.spotify.net is alive
>>>
>>> but ipsec statusall has no SA for them. (see ipsec-statusall.txt)
>>>
>>> please also find attached annalises and taylors ipsec.conf. the other
>>> hosts' ipsec.conf is equivalent. there is always one initiator for
>>> each connection.
>>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.strongswan.org
>> https://lists.strongswan.org/mailman/listinfo/users
>
>
> --
> ======================================================================
> Andreas Steffen                         andreas.steffen at strongswan.org
> strongSwan - the Linux VPN Solution!                www.strongswan.org
> Institute for Internet Technologies and Applications
> University of Applied Sciences Rapperswil
> CH-8640 Rapperswil (Switzerland)
> ===========================================================[ITA-HSR]==
>