Re: [Swan] Memory Leak / LibreSwan instability

[Madden, Joe]

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  
Sent: 23 August 2018 17:55
To: Madden, Joe 
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%2FY1ZCFcQkdata=01%7C01%7CJoe.Madden%40mottmac.com
> %7C0738850bd82c40d0e7e608d609193e5e%7Ca2bed0c459574f73b0c2a811407590fb
> %7C0sdata=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

Re: [Swan] one way ping

[Paul Wouters]

On Tue, 24 Jul 2018, John Crisp wrote:


Well, I swapped the dummy adaptor for a proper interface with the
virt_io driver just to be sure. However, ping was working even with the
dummy adaptor, so logically the networking was actually functioning.

You can ping happily from Libre -> Endian as soon as the tunnel is up.

You cannot ping from Endian -> Libre unless you have pinged the other
way first.


could this be due to a RELATED iptables rules that only allows replies ?

Paul
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan

Re: [Swan] Memory Leak / LibreSwan instability

[Paul Wouters]

On Tue, 28 Aug 2018, Madden, Joe wrote:


Subject: RE: [Swan] Memory Leak / LibreSwan instability

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.


I'm still interested in the logs to see why you got so many instances.
I'd like to ensure that is fixed, including the leaks it caused.

I had a look at the dcookie one, and I'm really surprised it leaks,
because delete_state() surely frees it. But your leaks didnt show me
leaks of other things on the state. So I'm a bit confused.

Paul
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan