[Swan] Libreswan to Fortigate | Failing with state transition 'Respond to CREATE_CHILD_SA IPsec SA Request' failed
Blue Aquan
blueaquan at zuwissen.com
Mon Jan 4 13:29:09 UTC 2021
Hi Paul The tunnel remains connected now, the logs has nothing in
particular except this message. The last line however, still says
information message from Fortigate, "message response has no
corresponding IKE SA". But otherwise the VPN is working as expected
with all services.
Jan 4 17:32:17.120117: "SUBNETS" #42: initiate rekey of IKEv2
CREATE_CHILD_SA IKE RekeyJan 4 17:32:17.131274: "SUBNETS" #43: sent
CREATE_CHILD_SA request to rekey IKE SAJan 4 17:32:17.303648:
"SUBNETS" #43: rekeyed #42 STATE_V2_REKEY_IKE_I1 and expire it
remaining life 937.812965sJan 4 17:32:17.303764: "SUBNETS" #43:
established IKE SA {auth=IKEv2 cipher=AES_CBC_256
integ=HMAC_SHA2_512_256 prf=HMAC_SHA2_512 group=DH21}Jan 4
17:32:18.305011: "SUBNETS" #42: deleting state
(STATE_V2_ESTABLISHED_IKE_SA) aged 2663.301907s and sending
notificationJan 4 17:32:18.362454: packet from 6.7.8.9:4500:
INFORMATIONAL message response has no corresponding IKE SA
Appreciate your quick help. Thank you once again.
BA
On Sun, 2021-01-03 at 13:20 +0530, Blue Aquan wrote:
> 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
> dpdaction=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=DISAB
> > > LED
> >
> > 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/20210104/555b755e/attachment.html>
More information about the Swan
mailing list