Sophos XG IPsec tunel unstable

Hey Pablo Rudo,

Thank you for reaching out to the community, so are you using the default pre-defined IPsec polices for the IPsec or the customized IPsec polices for the IPsec tunnel?
And both HQ & BQ are SFOS ? 

I tried pre-defined and customized policies and the outcome is the same, remote site is NSX-t Edge. The tunnel to NSX runs fine with the same settings on the Fortigate. I don't mind changing to Tunnel interface but I'm not sure how to implement this on the NSX.

What is the frequency of traffic not passing or tunnel going down ?
And who is the initiator NSX or SFOS ?  

Vivek, it's roughly 20-30 minutes, SFOS is the initiator, I'm using 28800/3600 key lifetime, DPD 30s, re-initiate

docs.vmware.com/.../GUID-2FDA8948-148B-4600-BA10-69C2BEF6D3C4.html

Can you enable the debug for the strongswan service on SFOS from the advance shell...
enable/disable: service strongswan:debug -ds nosync

And then collect the log during the time of disconnection: tail -f /log/strongswan.log 

Vivek, thanks for the commands, below is the output. For whatever reason seems that SAs do not match after some time. Rem GW is 22.22.22.22

2022-05-27 11:32:36Z 13[ENC] <NSX-1|38> generating CREATE_CHILD_SA request 1204 [ SA No KE TSi TSr ]
2022-05-27 11:32:36Z 13[NET] <NSX-1|38> sending packet: from 11.11.11.11[500] to 22.22.22.22[500] (560 bytes)
2022-05-27 11:32:36Z 04[NET] sending packet: from 11.11.11.11[500] to 22.22.22.22[500]
2022-05-27 11:32:36Z 03[NET] received packet: from 22.22.22.22[500] to 11.11.11.11[500] on Port2
2022-05-27 11:32:36Z 03[NET] waiting for data on sockets
2022-05-27 11:32:36Z 05[NET] <NSX-1|38> received packet: from 22.22.22.22[500] to 11.11.11.11[500] (80 bytes)
2022-05-27 11:32:36Z 05[ENC] <NSX-1|38> parsed CREATE_CHILD_SA response 1204 [ N(NO_PROP) ]
2022-05-27 11:32:36Z 05[IKE] <NSX-1|38> received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built
2022-05-27 11:32:36Z 05[CFG] <NSX-1|38> configured proposals: ESP:AES_CBC_256/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ, ESP:AES_CBC_256/AES_CBC_192/AES_CBC_128/HMAC_SHA2_512_256/HMAC_SHA2_384_192/HMAC_SHA2_256_128/AES_XCBC_96/NO_EXT_SEQ
2022-05-27 11:32:36Z 05[DMN] <NSX-1|38> [GARNER-LOGGING] (child_alert) ALERT: the received CHILD_SA proposals did not match: ESP:AES_CBC_256/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ, ESP:AES_CBC_256/AES_CBC_192/AES_CBC_128/HMAC_SHA2_512_256/HMAC_SHA2_384_192/HMAC_SHA2_256_128/AES_XCBC_96/NO_EXT_SEQ
2022-05-27 11:32:36Z 05[IKE] <NSX-1|38> creating CHILD_SA failed, trying again in 61 seconds
2022-05-27 11:32:36Z 05[IKE] <NSX-1|38> queueing CHILD_CREATE task (delayed by 61s)
2022-05-27 11:32:36Z 05[CHD] <NSX-1|38> CHILD_SA NSX-1{153116} state change: CREATED => DESTROYING
2022-05-27 11:32:36Z 05[IKE] <NSX-1|38> activating new tasks
2022-05-27 11:32:36Z 05[IKE] <NSX-1|38> nothing to initiate
2022-05-27 11:32:36Z 07[IKE] <NSX-1|38> activating new tasks
2022-05-27 11:32:36Z 07[IKE] <NSX-1|38>   activating CHILD_CREATE task
2022-05-27 11:32:36Z 07[IKE] <NSX-1|38> establishing CHILD_SA NSX-1{10}
2022-05-27 11:32:36Z 07[CFG] <NSX-1|38> configured proposals: ESP:AES_CBC_256/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ, ESP:AES_CBC_256/AES_CBC_192/AES_CBC_128/HMAC_SHA2_512_256/HMAC_SHA2_384_192/HMAC_SHA2_256_128/AES_XCBC_96/NO_EXT_SEQ

Yup Pablo Rudo,

"received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built" <- Remote peer is refusing our Phase 1 proposals

The problem appears to be a mismatch between Phase 1 acceptable proposals between the two peers.

Encryption, Authentication, and DH group must match in order for the VPN to come up, peer IP must also match.

You have to investigate the configuration on both peers and make sure they match the settings. If they match the settings, the remote peer administrator has to investigate the problem on his side, since the remote firewall is refusing the connection.

verify that Encryption/Authentication and DH group for Phase 2 match between the two peers. If they do, the remote appliance administrator has to investigate the logs on the remote appliance to identify why it's reporting the NO_PROPOSAL_CHOSEN.

Thanks, I found the issue was on the NSX side, the encryption was set to AES128 for both P1 and P2. How on earth this tunnel was established in the first place.