Hi Harri,
On 5/14/21 11:06 AM, Harald Dunkel wrote: > Hi folks, > > I have a few road warriors (3 out of ~140) having severe problems to > connect via IKEv2. Within the last 4 weeks they had >1000 problems > during IKE SA init each, e.g.: > > May 12 09:55:28 18[NET1] <92244> received packet: from 192.168.1.177[61416] > to 10.0.0.17[500] (432 bytes) > May 12 09:55:28 18[ENC1] <92244> parsed IKE_SA_INIT request 0 [ SA KE No > N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ] > May 12 09:55:28 18[IKE0] <92244> 192.168.1.177 is initiating an IKE_SA > May 12 09:55:28 18[IKE2] <92244> IKE_SA (unnamed)[92244] state change: > CREATED => CONNECTING > May 12 09:55:28 18[CFG1] <92244> selected proposal: > IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048 > May 12 09:55:28 18[IKE1] <92244> remote host is behind NAT > May 12 09:55:28 18[IKE2] <92244> sending strongSwan vendor ID > May 12 09:55:28 18[IKE1] <92244> sending cert request for "C=DE, O=example > AG, CN=ws-CA" > May 12 09:55:28 18[IKE1] <92244> sending cert request for "C=DE, O=example > AG, OU=example Certificate Authority, CN=root-CA" > May 12 09:55:28 18[IKE1] <92244> sending cert request for "C=DE, ST=NRW, > O=example AG, OU=TI, CN=ipsec-ca" > May 12 09:55:28 18[ENC1] <92244> generating IKE_SA_INIT response 0 [ SA KE No > N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(CHDLESS_SUP) N(MULT_AUTH) V ] > May 12 09:55:28 18[NET1] <92244> sending packet: from 10.0.0.17[500] to > 192.168.1.177[61416] (541 bytes) > May 12 09:55:58 31[JOB1] <92244> deleting half open IKE_SA with 192.168.1.177 > after timeout > May 12 09:55:58 31[IKE2] <92244> IKE_SA (unnamed)[92244] state change: > CONNECTING => DESTROYING > > Obviously there is a 30sec timeout on the IPsec gateway. Is there > a chance to increase this timeout (using stroke, ie. ipsec.conf)? > https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection > mentions only the DPD timeout (150 sec per default) and the inac- > tivity timeout (child sa only, as it seems). What you're looking for is not a part of the swanctl.conf or ipsec.conf. It's part of the strongswan.conf (/etc/strongswan.conf) and documented at [1]. Use the keyword 'half_open_timeout' in the 'charon' section: <snip> charon { half_open_timeout = 42 } <snap> If it takes your RW peers more than 30 seconds to respond one would assume that the response got lost along the way. Normally in such a case the initiator would retransmit the request. That's not part of the responders job. > > Would it be wise to resend the IKE_SA_INIT response (lets say) 3 > times? As mentioned above, you may check your RWs configuration to retransmit the request. > > Every helpful comment is highly appreciated > > Harri Cheers, Thomas [1] https://wiki.strongswan.org/projects/strongswan/wiki/strongswanconf