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= [email protected]
leftnexthop= 10.59.31.54
#SAA
right= 52.48.93.253
rightid= [email protected]
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= [email protected]
leftnexthop= 10.59.31.54
#SAA
right= 52.48.93.253
rightid= [email protected]
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= [email protected]
leftnexthop= 10.59.31.54
#SAA
right= 52.48.93.253
rightid= [email protected]
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 <[email protected]>
Sent: 28 August 2018 20:45
To: Madden, Joe <[email protected]>
Cc: [email protected]
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
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
