Invalid ke means wrong DH group on the IKE or ESP option. It can also mean a 
wrong pfs=yes|no option. “Wrong” is based on the remote peer. See what they 
configured / expect. The INVALID_KE payload should contain a list of acceptable 
KE values but you might need plutodebug=all to see that.

Sent using a virtual keyboard on a phone

> On Aug 25, 2022, at 08:01, Peter Viskup <[email protected]> wrote:
> 
> 
> Still not able to bring up them together.
> Just found https://libreswan.org/wiki/IKEv2_Child_SA page and according to it 
> the connection is hanging on "sent IPSec Child req wait response".
> That's clear enough, but can anybody tell what's going on and maybe what's 
> needed to change to make it work as expected?
> 
> 003 "sp1" #94: dropping unexpected CREATE_CHILD_SA message containing 
> INVALID_KE_PAYLOAD notification; message payloads: SK; encrypted payloads: N; 
> missing payloads: SA,Ni,TSi,TSr
> 
> Peter
> 
> Dňa ut 23. 8. 2022, 14:06 Paul Wouters <[email protected]> napísal(a):
>>> On Aug 23, 2022, at 05:05, Peter Viskup <[email protected]> wrote:
>>> 
>>> 
>>> Just went trough the FortiGate cookbook which mention the requirement of 
>>> different SPI's for both subnets for Cisco ASA.
>>> How to configure the libreswan to use different SPI for every subnet? Not 
>>> able to find it in man pages.
>> 
>> Currently that is the only supported method.
>> 
>> Paul
>> 
>>> 
>>> https://docs.fortinet.com/document/fortigate/6.2.3/cookbook/666100/ipsec-vpn-between-a-fortigate-and-a-cisco-asa-with-multiple-subnets
>>> 
>>>> On Mon, Aug 22, 2022 at 6:40 PM Peter Viskup <[email protected]> 
>>>> wrote:
>>>> Thank you for quick response.
>>>> The output I just sent was just after the tunnel sp2 was established with 
>>>> the same configuration, just with another rightsubnet.
>>>> # ipsec auto --up sp2
>>>> 002 "sp2" #92: initiating v2 parent SA
>>>> 133 "sp2" #92: STATE_PARENT_I1: initiate
>>>> 002 "sp2" #92: local IKE proposals for sp2 (IKE SA initiator selecting 
>>>> KE): 
>>>> 1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=ECP_384
>>>> 133 "sp2" #92: STATE_PARENT_I1: sent v2I1, expected v2R1
>>>> 002 "sp2" #92: local ESP/AH proposals for sp2 (IKE SA initiator emitting 
>>>> ESP/AH proposals): 
>>>> 1:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;DH=NONE;ESN=DISABLED
>>>> 134 "sp2" #93: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 
>>>> cipher=aes_256 integ=sha256_128 prf=sha2_256 group=DH20}
>>>> 002 "sp2" #93: IKEv2 mode peer ID is ID_IPV4_ADDR: '1.2.3.4'
>>>> 003 "sp2" #93: Authenticated using authby=secret
>>>> 002 "sp2" #93: negotiated connection [100.64.7.0-100.64.7.255:0-65535 0] 
>>>> -> [10.20.20.0-10.20.20.255:0-65535 0]
>>>> 004 "sp2" #93: STATE_V2_IPSEC_I: IPsec SA established tunnel mode 
>>>> {ESP/NAT=>0x6d6a23ce <0x19a1226c xfrm=AES_CBC_256-HMAC_SHA2_256_128 
>>>> NATOA=none NATD=1.2.3.4:4500 DPD=active}
>>>> 
>>>> And I am able to reach both ends of VPN tunnel.
>>>> 
>>>>> On Mon, Aug 22, 2022 at 6:20 PM Paul Wouters <[email protected]> wrote:
>>>>> On Mon, 22 Aug 2022, Peter Viskup wrote:
>>>>> 
>>>>> > [root@prd01a ipsec.d]# ipsec auto --up sp1
>>>>> > 002 "sp1" #94: local ESP/AH proposals for sp1 (ESP/AH initiator 
>>>>> > emitting proposals):
>>>>> > 1:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;DH=ECP_384;ESN=DISABLED
>>>>> > 139 "sp1" #94: STATE_V2_CREATE_I: sent IPsec Child req wait response
>>>>> > 003 "sp1" #94: dropping unexpected CREATE_CHILD_SA message containing 
>>>>> > INVALID_KE_PAYLOAD notification; message payloads: SK; encrypted 
>>>>> > payloads: N;
>>>>> > missing payloads: SA,Ni,TSi,TSr
>>>>> 
>>>>> Looks like your other end does not like your PFS or DH group size?
>>>> It does - as I was able to initiate the first tunnel. Even this tunnel can 
>>>> be establised when tried as the first.
>>>>  
>>>>> 
>>>>> > Configuration is similar to this (rightsubnets):
>>>>> > conn sp1
>>>>> >         hostaddrfamily=ipv4
>>>>> >         clientaddrfamily=ipv4
>>>>> >         right=1.2.3.4
>>>>> >         rightsubnet=10.10.10.0/24
>>>>> >         #rightsubnets={10.10.10.0/24 10.20.20.0/24}
>>>>> >         left=100.64.7.8
>>>>> >         leftsubnet=100.64.7.0/24
>>>>> >         #ikev2
>>>>> >         leftauth=secret
>>>>> >         rightauth=secret
>>>>> >         ikev2=insist
>>>>> >         ike=aes256-sha256;dh20
>>>>> >         esp=aes256-sha256;dh20
>>>>> 
>>>>> Does the other end not like dh20?
>>>>> Does the other end not like pfs=yes? Try pfs=no to see what happens
>>>>> then?
>>>> Getting the same error with pfs=no and no dh20 in ike/esp.
>>>> 
>>>> 002 "sp1" #95: local ESP/AH proposals for sp1 (ESP/AH initiator emitting 
>>>> proposals): 1:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;ESN=DISABLED
>>>> 139 "sp1" #95: STATE_V2_CREATE_I: sent IPsec Child req wait response
>>>> 003 "sp1" #95: dropping unexpected CREATE_CHILD_SA message containing 
>>>> INVALID_KE_PAYLOAD notification; message payloads: SK; encrypted payloads: 
>>>> N; missing payloads: SA,Ni,TSi,TSr
>>>>  
>>>> And this is just prove the sp1 is working either (after taking down sp2), 
>>>> both do not work at the same time.
>>>> 
>>>> # ipsec auto --up sp1
>>>> 002 "sp1" #101: initiating v2 parent SA
>>>> 133 "sp1" #101: STATE_PARENT_I1: initiate
>>>> 002 "sp1" #101: local IKE proposals for sp1 (IKE SA initiator selecting 
>>>> KE): 
>>>> 1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=ECP_384
>>>> 133 "sp1" #101: STATE_PARENT_I1: sent v2I1, expected v2R1
>>>> 002 "sp1" #101: local ESP/AH proposals for sp1 (IKE SA initiator emitting 
>>>> ESP/AH proposals): 
>>>> 1:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;DH=NONE;ESN=DISABLED
>>>> 134 "sp1" #102: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 
>>>> cipher=aes_256 integ=sha256_128 prf=sha2_256 group=DH20}
>>>> 002 "sp1" #102: IKEv2 mode peer ID is ID_IPV4_ADDR: '1.2.3.4'
>>>> 003 "sp1" #102: Authenticated using authby=secret
>>>> 002 "sp1" #102: negotiated connection [100.64.7.0-100.64.7.255:0-65535 0] 
>>>> -> [10.10.10.0-10.10.10.255:0-65535 0]
>>>> 004 "sp1" #102: STATE_V2_IPSEC_I: IPsec SA established tunnel mode 
>>>> {ESP/NAT=>0x4f986552 <0x5990fe61 xfrm=AES_CBC_256-HMAC_SHA2_256_128 
>>>> NATOA=none NATD=1.2.3.4:4500 DPD=active}
>>>> 
>>>> ...able to reach both ends of the established tunnel (ICMP and TCP too).
>>>> 
>>>>> 
>>>>> > The multinet testconfigurations have the "ikev2=no"
>>>>> > libreswan/east.conf at main · libreswan/libreswan · GitHub 
>>>>> 
>>>>> Likely just because it was an IKEv1 test and we kept it the same. There
>>>>> should be an equivalent ikev2 test, or we should add one :)
>>>>> 
>>>>> Paul
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan

Reply via email to