On Tue, 28 Feb 2017, Andrew Cagney wrote:
Yes. And actually I think it would be good to have DHxx in general too.
Ideally, I would like dh2, dh5, etc to be aliases for modp but a
quick peek at the code seemed it was not a quick simple change to add.
So instead of MODP1024, it should list
So they are using the same PRF and DH, good (although I'm still mystified).
more thinking,
Andrew
On 28 February 2017 at 13:09, Erik Andersson wrote:
> * For IKEv2:
>
> IKEv2 algorithm newest:
> AES_CBC_128-AUTH_HMAC_SHA2_256_128-PRF_HMAC_SHA2_256-MODP2048
>
> ESP algorithm newest: AES_128-HMAC_
On 28 February 2017 at 13:10, Paul Wouters wrote:
> On Mon, 27 Feb 2017, Andrew Cagney wrote:
>
>>
>> First I should note that I'm as guilty as any for adding to the
>> problems here, more recently I've been dumping details into pluto.log
>> so hopefully I'm reformed :-)
>
>
> We are all guilty :)
On Mon, 27 Feb 2017, Andrew Cagney wrote:
First I should note that I'm as guilty as any for adding to the
problems here, more recently I've been dumping details into pluto.log
so hopefully I'm reformed :-)
We are all guilty :)
The output from:
$ ipsec auto --status
includes:
[algo lis
* For IKEv2:
IKEv2 algorithm newest:
AES_CBC_128-AUTH_HMAC_SHA2_256_128-PRF_HMAC_SHA2_256-MODP2048
ESP algorithm newest: AES_128-HMAC_SHA2_256; pfsgroup=
* For IKEv1:
IKE algorithm newest: AES_CBC_128-SHA2_256-MODP2048
ESP algorithm newest: AES_128-HMAC_SHA2_256; pfsgroup=
/Erik
On 2017-0
On 28 February 2017 at 10:30, Erik Andersson wrote:
> I can also add that when running with IKEv1 instead of IKEv2 the memory
> consumption doesn't seem to grow at all. Or very modest at least.
With IKEv1 vs IKEv2 was the negotiated crypto suite the same?
_
On 28 February 2017 at 10:41, Paul Wouters wrote:
> On Tue, 28 Feb 2017, Andrew Cagney wrote:
>
>>/* Clean up. */
>>free_any_symkey("sym_key", &sym_key);
>>
>> so from our POV the key was freed. However NSS has kept a handle on
>> that memory and will recycle it repeatedly.
>
>
> Why wou
On Tue, 28 Feb 2017, Andrew Cagney wrote:
/* Clean up. */
free_any_symkey("sym_key", &sym_key);
so from our POV the key was freed. However NSS has kept a handle on
that memory and will recycle it repeatedly.
Why would this be different between IKEv1 and IKEv2 though? Since the
report
Thanks for the replies.
This is the output of "ipsec status" when running pluto over night (25
MB memory consumption) described below:
000 Total IPsec connections: loaded 2, active 2
000
000 State Information: DDoS cookies not required, Accepting new IKE
connections
000 IKE SAs: total(4), ha
On 28 February 2017 at 09:28, D. Hugh Redelmeier wrote:
> NSS does its own memory allocation and is thus invisible to the leak
> detective. Anything NSS-related is thus suspect. Think: keys and
> related stuff. So you are probably on the right track.
>
> | ==2935== 5,095,216 bytes in 938 blocks
I think your rekey times are too fast and you create tunnels faster then we let
them linger. Run "ipsec status" and I bet you are seeing thousands of tunnels
waiting to get expired.
I do think we are keeping those around for far too long (an hour or so instead
of like 20s or so)
Paul
Sent fro
| From: Erik Andersson
(This is a quick reply, not a careful one.)
| I ran the tunnels for 6 days and recognized that the memory consumption of
| pluto was quite high. It started using around 8 MB and after six days it used
| around 140 MB on both hosts.
That's not good.
| The leak detective r
Hi,
I'm running libreswan 3.19 on two centos 7 machines. For debugging
purposes the ike and sa lifetimes are set very low, 90 and 70 seconds
respectively.
I'm running one gateway to gateway tunnel and one subnet to subnet
tunnel between "Host A" (10.48.28.60) and "Host B" (10.48.28.70).
ip
13 matches
Mail list logo
