Hi Mike,
> ikelifetime=6m
> margintime=3m
Not ideal as that, depending on rekeyfuzz and the randomization, could
result in rekeying getting disabled (see the formula on the ExpiryRekey
page).
> If I change reauth=yes to reauth=no
You definitely have to disable reauth to use rekeying
Hi Emeric,
> To sum up, for compatibility reason, as soon as there is something other than
> an IP address, we have to activate the
> "i_dont_care_about_security_and_use_aggressive_mode_psk" option?
The charon daemon, since 5.5.2, does a config lookup based on the IP
addresses and then searches
On 6/26/2017 10:46, Tobias Brunner wrote:
> Hi Karl,
>
>> StrongSwan never gets this packet. I assume the problem here is the
>> length mismatch, but not certain. What is certain is that StrongSwan
>> never sees it; no matter how far up I turn the logging I never see any
>> evidence of it being
Hi Tobias,
I see now in the log that when StrongSwan attempts to rekey the IKEv2 SA there
seems to be some problem with the choice of the DH group:
01[JOB] got event, queuing job for execution
01[JOB] next event in 179s 999ms, waiting
05[MGR] checkout IKEv2 SA with SPIs 64c0f2607e106b9d_i 1631568
Hi Tobias,
Indeed I was able to get StrongSwan to rekey the IKEv2 SA by adding
ike=3des-sha1-modp1024
as in
conn %default
ikelifetime=12m
lifetime=1h
margintime=3m
keyexchange=ikev2
authby=secret
reauth=no
rekey=yes
ike=3de
