Hi Paul, Thanks for the info - I suspect the remote peer is badly configured - It is a StrongSwan instance where that we've had trouble with in the past.
Thanks for the response and I'll have a chat with the other party. Joe. -----Original Message----- From: Paul Wouters <p...@nohats.ca> Sent: 23 August 2018 17:55 To: Madden, Joe <joe.mad...@mottmac.com> Cc: swan@lists.libreswan.org Subject: Re: [Swan] Memory Leak / LibreSwan instability On Mon, 20 Aug 2018, Madden, Joe wrote: > Sorry, the logs seems to have gone a bit nuts in the email below, I'd added > it to paste in for you. > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpas > tebin.com%2Fraw%2FY1ZCFcQk&data=01%7C01%7CJoe.Madden%40mottmac.com > %7C0738850bd82c40d0e7e608d609193e5e%7Ca2bed0c459574f73b0c2a811407590fb > %7C0&sdata=dJhUSRtCeal55FtGKp64DOvlyc%2BPOv4eDWXZJB%2B7M0k%3D& > reserved=0 You seem to have (too) many instances of the same connection trying and failing. eg: ssl-iptrafficsig-1-subnet-[12]. There should not be more then one of those. The error path seems to be the cause of the leak as well, eg: Aug 20 08:27:35 hal-internal-firewall pluto[23477]: leak: 177 * msg_digest, item size: 4152 Aug 20 08:27:29 hal-internal-firewall pluto[23477]: leak: 15 * saved received dcookie, item size: 24 Seeing that you got a dcookie, the other end seems to think its load is too high or you are an attacker. So it wants you to do the additional proof of source ip by sending you a dcookie. Do you ever see an established connection? I think the dcookies on their end and the misconfiguration that is likely the problem causing retries is whats ultimate ending up in the libreswan failure path code, which seems to additionally cause these leaks. So while we need to fix these leaks, you need to fix your configuration with the remote peer. Paul _______________________________________________ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
