[Swan] multinet with ikev2 not working

Peter Viskup peter.viskup at gmail.com
Thu Aug 25 15:00:52 EEST 2022


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 <paul at nohats.ca> napísal(a):

> On Aug 23, 2022, at 05:05, Peter Viskup <peter.viskup at gmail.com> 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 <peter.viskup at gmail.com>
> 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 <paul at nohats.ca> wrote:
>>
>>> On Mon, 22 Aug 2022, Peter Viskup wrote:
>>>
>>> > [root at 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
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20220825/a423c6fc/attachment.htm>


More information about the Swan mailing list