[Swan] Memory Leak / LibreSwan instability

[Madden, Joe]

It's maybe an outcome of what we had to do to get strongswan to work:

Our configuration looks like this:

/bin/touch /etc/ipsec.d/ssl-iptrafficsignals.conf
conn ssl-iptrafficsig-1-subnet-1
        authby=                 secret
        auto=                   start
        type=                   tunnel
        forceencaps=            no
        rekeymargin=            3m
        keyingtries=            %forever
        salifetime=             8h
        ikelifetime=            24h
        ikev2=                  insist
        initial-contact=        yes
        send_vendorid=          yes

        #RTT
        left=           10.59.31.49
        leftsubnet=     10.1.0.0/16
        leftid=         leftsubnet1 at nrts.com
        leftnexthop=    10.59.31.54

        #SAA
        right=          52.48.93.253
        rightid=        rightsubnet1 at nrts.com
        rightsubnet=    10.199.0.0/28
        ike=            aes256-sha2_512;modp2048
        phase2=         esp
        phase2alg=      aes256-sha2_512;modp2048
        pfs=            yes
        sha2_truncbug=  no

        #Dead Peer Detection
        dpdaction=      restart


conn ssl-iptrafficsig-1-subnet-2
        authby=                 secret
        auto=                   start
        type=                   tunnel
        forceencaps=            no
        rekeymargin=            3m
        keyingtries=            %forever
        salifetime=             8h
        ikelifetime=            24h
        ikev2=                  insist
        initial-contact=        yes
        send_vendorid=          yes

        #RTT
        left=           10.59.31.49
        leftsubnet=     10.2.0.0/16
        leftid=         leftsubnet2 at nrts.com
        leftnexthop=    10.59.31.54

        #SAA
        right=          52.48.93.253
        rightid=        rightsubnet2 at nrts.com
        rightsubnet=    10.199.0.0/28
        ike=            aes256-sha2_512;modp2048
        phase2=         esp
        phase2alg=      aes256-sha2_512;modp2048
        pfs=            yes
        sha2_truncbug=  no

        #Dead Peer Detection
        dpdaction=      restart


conn ssl-iptrafficsig-1-subnet-3
        authby=                 secret
        auto=                   start
        type=                   tunnel
        forceencaps=            no
        rekeymargin=            3m
        keyingtries=            %forever
        salifetime=             8h
        ikelifetime=            24h
        ikev2=                  insist
        initial-contact=        yes
        send_vendorid=          yes

        #RTT
        left=           10.59.31.49
        leftsubnet=     172.21.12.0/22
        leftid=         leftsubnet3 at nrts.com
        leftnexthop=    10.59.31.54

        #SAA
        right=          52.48.93.253
        rightid=        rightsubnet3 at nrts.com
        rightsubnet=    10.199.0.0/28
        ike=            aes256-sha2_512;modp2048
        phase2=         esp
        phase2alg=      aes256-sha2_512;modp2048
        pfs=            yes
        sha2_truncbug=  no

        #Dead Peer Detection
        dpdaction=      restart"

So we should have three SA/s with one child each - We had to do this to work around the strongswan child AS issue where it would only work with one subnet.

I wonder if this is the cause?

Joe.

-----Original Message-----
From: Paul Wouters <paul at nohats.ca> 
Sent: 28 August 2018 20:45
To: Madden, Joe <Joe.Madden at mottmac.com>
Cc: swan at lists.libreswan.org
Subject: RE: [Swan] Memory Leak / LibreSwan instability

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