On Wed, 25 Nov 2020, Balaji Thoguluva wrote:
Yes I also saw that error message, not sure why it does not identify IKEv1 or
IKEv2.
I thought ikev2=yes parameter says this is ikev2.
well, before 3.28 connections could be either one or both. As of 3.28,
these are only ikev1 or ikev2. This is why I'm not so keen on
investigating this bug.
I am not sure if I will be able to move easily to the later version of
Libreswan.
That's unfortunate :/
Is there any workaround to get around this in 3.25 itelf?
Not that I know. As I said, I've never seen this bug before.
Paul
Thanks,
Balaji
On Wed, Nov 25, 2020 at 12:01 PM Paul Wouters <[email protected]> wrote:
On Wed, 25 Nov 2020, Balaji Thoguluva wrote:
> Thanks Paul. Attached is the pluto log. Given below is the
configuration.
hmm, that is 3.25. Can you use 3.32 or later?
This is weird:
2020-11-25T12:20:34.272611+00:00 [localhost] pluto[3575]: "radcert" #2:
STATE_V2_IPSEC_I: IPsec SA
established tunnel mode {ESP=>0xc0c0c1a6 <0xcb4f58fa
xfrm=AES_CBC_256-HMAC_SHA1_96 NATOA=none NATD=none
DPD=active}
2020-11-25T12:21:07.262946+00:00 [localhost] pluto[3575]: "radcert" #2:
Neither IKEv1 nor IKEv2 allowed:
ENCRYPT+TUNNEL
2020-11-25T12:25:34.263093+00:00 [localhost] pluto[3575]: "radcert" #2:
deleting state (STATE_V2_IPSEC_I)
and sending notification
Some how your connection is missing ikev1 and ikev2 ??
Paul
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
