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

[Paul Wouters]

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 are
> testbed machine there's no traffic flowing between them continuously and the tunnel gets disconnected sometime during long
> hours of inactivity. Every morning, I find the tunnel down, but it's restored with a simple restart of "systemctl restart
> ipsec". This stays on a the entire day mostly and the next day it's down again... I am attaching the config on the Linux
> machine; if you need the configuration on the Fortigate, I can post it here, but it's running just the same things I've
> configured on CentOS.

> conn SUBNETS

> auto=start

With auto=start and libreswan 4.1, that should keep the tunnel up. I
would 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 with
> suggested DH DH21

Maybe this is affecting rekey on the fortigate? Can you try setting an
IKE 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 SA
> Dec 31 06:19:31.891736: "SUBNETS" #10641: dropping unexpected CREATE_CHILD_SA message containing NO_PROPOSAL_CHOSEN
> notification; message payloads: SK; encrypted payloads: N; missing payloads: SA,Ni,TSi,TSr

So this is strange. We are rekeying the same proposal, so it should
never refuse the proposal we agreed on the first go. This looks like
a fortigate bug.

> Dec 31 06:36:49.918252: "SUBNETS" #10643: no local proposal matches remote proposals
> 1:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_512_256;ESN=DISABLED

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