[Swan] Libreswan to Fortigate | Failing with state transition 'Respond to CREATE_CHILD_SA IPsec SA Request' failed

Blue Aquan blueaquan at zuwissen.com
Sun Jan 3 07:50:08 UTC 2021


Hi Paul	Thank you for your quick reply. I've set the values as
suggested by you and here are the results. 

# /etc/ipsec.d/EURO-FORT.conf - Europa-Fortigate Centos 8 Libreswan
IPsec configuration file#conn SUBNETS        also=EURO-
FORT        leftsubnet=10.10.128.0/20        leftsourceip=10.10.128.1  
      rightsubnet=192.168.2.0/24        rightsourceip=192.168.2.1      
  auto=startconn EURO-
FORT        type=tunnel        left=1.2.3.4        right=6.7.8.9       
 authby=secret        ikev2=yes        pfs=no        ike=aes256-
sha2_512+sha2_256-dh21        esp=aes256-sha2_512
+sha1+sha2_256;dh21        dpddelay=5        dpdtimeout=120        dpda
ction=restart        encapsulation=yes
When "systemctl restart ipsec" is issued
Jan  3 12:57:17.407404: loading secrets from "/etc/ipsec.secrets"Jan  3
12:57:17.407603: "SUBNETS" #1: initiating IKEv2 connectionJan  3
12:57:17.407616: "SUBNETS": local IKE proposals (IKE SA initiator
selecting KE): Jan  3 12:57:17.407635: "SUBNETS":   1:IKE=AES_CBC_256-
HMAC_SHA2_512+HMAC_SHA2_256-HMAC_SHA2_512_256+HMAC_SHA2_256_128-
ECP_521Jan  3 12:57:17.419500: "SUBNETS" #1: sent IKE_SA_INIT
requestJan  3 12:57:17.476885: "SUBNETS": local ESP/AH proposals (IKE
SA initiator emitting ESP/AH proposals): Jan  3 12:57:17.476908:
"SUBNETS":   1:ESP=AES_CBC_256-
HMAC_SHA2_512_256+HMAC_SHA1_96+HMAC_SHA2_256_128-NONE-DISABLEDJan  3
12:57:17.476947: "SUBNETS" #1: sent IKE_AUTH request {auth=IKEv2
cipher=AES_CBC_256 integ=HMAC_SHA2_512_256 prf=HMAC_SHA2_512
group=DH21}Jan  3 12:57:17.520722: "SUBNETS" #2: IKEv2 mode peer ID is
ID_IPV4_ADDR: '6.7.8.9'Jan  3 12:57:17.520800: "SUBNETS" #1:
authenticated using authby=secretJan  3 12:57:17.555688: "SUBNETS" #2:
negotiated connection [10.10.128.0-10.10.143.255:0-65535 0] ->
[192.168.2.0-192.168.2.255:0-65535 0]Jan  3 12:57:17.555712: "SUBNETS"
#2: IPsec SA established tunnel mode {ESPinUDP=>0x32560773 <0x959c9061
xfrm=AES_CBC_256-HMAC_SHA2_512_256 NATOA=none NATD=6.7.8.9:4500
DPD=active}


When  "ipsec whack --rekey-ipsec --name SUBNETS" is issued
193 "SUBNETS" #3: sent CREATE_CHILD_SA request to rekey IPsec SA010
"SUBNETS" #3: STATE_V2_REKEY_CHILD_I1: retransmission; will wait 0.5
seconds for response002 "SUBNETS" #3: rekeyed #2
STATE_V2_REKEY_CHILD_I1 and expire it remaining life 28494.626646s002
"SUBNETS" #3: negotiated connection [10.10.128.0-10.10.143.255:0-65535
0] -> [192.168.2.0-192.168.2.255:0-65535 0]004 "SUBNETS" #3: IPsec SA
established tunnel mode {ESPinUDP=>0x32560774 <0xdae31207
xfrm=AES_CBC_256-HMAC_SHA2_512_256 NATOA=none NATD=6.7.8.9:4500
DPD=active}002 "SUBNETS" #2: deleting state
(STATE_V2_ESTABLISHED_CHILD_SA) aged 306.453605s and sending
notification005 "SUBNETS" #2: ESP traffic information: in=0B out=0B


It looks alright at the moment, will wait another day and let you know
the final results.

Thanks, BestBA



On Thu, 2020-12-31 at 12:24 -0500, Paul Wouters wrote:
> On Thu, 31 Dec 2020, Blue Aquan wrote:
> > With a slight modification of IP and authentication method(Pre-
> > Shared key) , I tried adapting it to the Fortigate firewall.The
> > tunnel gets established perfectly fine, I am able to reach machines
> > behind the Fortigate as well, but since these aretestbed machine
> > there's no traffic flowing between them continuously and the tunnel
> > gets disconnected sometime during longhours of inactivity. Every
> > morning, I find the tunnel down, but it's restored with a simple
> > restart of "systemctl restartipsec". This stays on a the entire day
> > mostly and the next day it's down again... I am attaching the
> > config on the Linuxmachine; if you need the configuration on the
> > Fortigate, I can post it here, but it's running just the same
> > things I'veconfigured on CentOS.
> > conn SUBNETS
> > auto=start
> 
> With auto=start and libreswan 4.1, that should keep the tunnel up.
> Iwould be interested in seeing the logs to understand what is
> happening.
> > Dec 31 14:25:20.576958: "SUBNETS" #1: Received unauthenticated
> > INVALID_KE_PAYLOAD response to DH DH19; resending withsuggested DH
> > DH21
> 
> Maybe this is affecting rekey on the fortigate? Can you try setting
> anIKE line that only contains dh21 ? eg
>  	ike=aes256-sha2_512+sha2_256-dh21
> > Dec 31 06:19:31.846499: "SUBNETS" #10641: sent CREATE_CHILD_SA
> > request to rekey IPsec SADec 31 06:19:31.891736: "SUBNETS" #10641:
> > dropping unexpected CREATE_CHILD_SA message containing
> > NO_PROPOSAL_CHOSENnotification; message payloads: SK; encrypted
> > payloads: N; missing payloads: SA,Ni,TSi,TSr
> 
> So this is strange. We are rekeying the same proposal, so it
> shouldnever refuse the proposal we agreed on the first go. This looks
> likea fortigate bug.
> > Dec 31 06:36:49.918252: "SUBNETS" #10643: no local proposal matches
> > remote
> > proposals1:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_512_256;ESN=DISABLE
> > D
> 
> this is what you negotiated on the initial exchanges. So why refuse
> now?
> Perhaps it is an issue of pfs? Try adding pfs=no ?
> You can trigger a rekey without waiting an hour by:
>  	ipsec whack --rekey-ipsec --name SUBNETS
> you can also try adding the DH group to esp for PFS, eg:
>  	esp=aes256-sha2_512+sha1+sha2_256;dh21
> Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20210103/2c5b758b/attachment.html>


More information about the Swan mailing list