[Swan] Fwd: Problem with random rekey failures
Miguel Ponce Antolin
mponce at paradigmadigital.com
Wed Jun 16 06:54:44 UTC 2021
Hi and thank you so much Paul for your answer.
We were thinking to upgrade it, so we are going to try it. Thanks for the
binary compiled, I had just compiled it yesterday but I prefer this way.
Some questions that came to me with the upgrade option,
- Is it still needed to separate the rightsubnets? And do you create them
on different files? I have understood that you create them on the same conf
- The ikelifetime and salifetime for rekeying is still a problem on version
4.4-1?, I think it is recommended anyway.
El mar, 15 jun 2021 a las 17:40, Paul Wouters (<paul at nohats.ca>) escribió:
> On Tue, 15 Jun 2021, Miguel Ponce Antolin wrote:
> > I have been suffering a random problem with libreswan v3.25 when
> connecting an AWS EC2 Instance running Libreswan and a Cisco ASA on the
> other end.
> Is it possible to test v4.4 ? We have rpms build on
> Specifically, with the many subnets you are likely needing this fix from
> * IKEv2: Connections would not always switch when needed [Andrew/Paul]
> But the changelog between 3.25 and 4.4 is huge. There might be other
> items you need too.
> Alternatively, you can try and split up your subnetS into different
> conns, eg:
> conn vpn
> # use auto=ignore, will be read in via also= statements
> # no rightsubnet= here
> # dont use this with more than one subnet...
> conn vpn-1
> conn vpn-2
> conn vpn-18
> This uses a slightly different code path to get all the tunnels loaded and
> > We tried to "force" to reconnect using the ping command to an IP in
> various rightsubnets but when the problem is active we continously are
> seeing this
> > kind of logs:
> That would be hacky and not really solve race conditions.
> > Jun 11 11:17:25.795153: "vpn/1x15" #221: message id deadlock? wait
> sending, add to send next list using parent #165 unacknowledged 1 next
> > id=63 ike exchange window 1
> Note that this is a bit of a concern. You can only have one IKE message
> outstanding, and this indicates that the Cisco might not be answering
> that outstanding message, and so the only thing libreswan can do is
> wait longer or restart _everything_ related to that IKE SA, so that
> means all tunnels. We did reduce the change of message id deadlock
> some point in the past with our pending() code, so again tetsing
> with an upgraded libreswan would be a useful test.
> > Is there any troubleshooting we could do in order to know where the
> rekey request is lost or why is not trying to rekey at all when this
> problem is
> > active?
> Depending on what the issues are, you can try to ensure either libreswan
> or Cisco is always the rekey initiator by tweaking the ikelifetime and
> salifetime. Eg try ikelifetime=24h with salifetime=8h and most likely
> Cisco will trigger all the rekeys. Or use ikelifetime=2h and
> salifetime=1h to make libreswan likely always initiate the rekeys.
[image: Logo Especialidad]
*Miguel Ponce Antolín.*
Sistemas · +34 670 360 655
[image: Logo Paradigma] · paradig.ma <https://www.paradigmadigital.com/>
· contáctanos <https://www.paradigmadigital.com/contacto> · [image:
Twitter] <https://twitter.com/paradigmate> [image: Youtube]
<https://www.youtube.com/user/ParadigmaTe?feature=watch> [image: Linkedin]
<https://www.linkedin.com/company/paradigma-digital/> [image: Instagram]
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Swan