Tobias, The remote side gave me their Cisco ASA 5585 settings and they showed the logs:
object network Svc_2_2_2_2 host 2.2.2.2 object network Svc_3_3_3_3 host 3.3.3.3 crypto ipsec ikev2 ipsec-proposal ESP-AES256-SHA2 protocol esp encryption aes-256 protocol esp integrity sha-256 object-group network Customer description Customer network-object 10.21.139.8 255.255.255.252 object-group network ISP-to-Customer description ISP-to-Customer network-object object Svc_2_2_2_2 network-object object Svc_3_3_3_3 access-list outside_cryptomap_2470 extended permit ip object-group ISP-to-Customer object-group Customer crypto ipsec ikev2 ipsec-proposal ESP-AES256-SHA2 crypto map outside_map 2470 match address outside_cryptomap_2470 crypto map outside_map 2470 set pfs group14 crypto map outside_map 2470 set connection-type answer-only crypto map outside_map 2470 set peer 1.1.1.1 crypto map outside_map 2470 set ikev2 ipsec-proposal ESP-AES256-SHA2 crypto map outside_map 2470 set nat-t-disable crypto map outside_map 2470 set reverse-route crypto ikev2 policy 100 encryption aes-256 integrity sha group 21 20 19 24 14 5 2 prf sha lifetime seconds 28800 tunnel-group 1.1.1.1 type ipsec-l2l tunnel-group 1.1.1.1 general-attributes default-group-policy GroupPolicy-Def-IKE2 tunnel-group 1.1.1.1 ipsec-attributes ikev1 pre-shared-key ***** ikev2 remote-authentication pre-shared-key ***** ikev2 local-authentication pre-shared-key ***** ikev2 local-authentication pre-shared-key ***** asa-8m-a5-820-l2l/sec/act# sh logg | i 1.1.1.1 May 11 2021 13:35:11: %ASA-7-609001: Built local-host outside:1.1.1.1 May 11 2021 13:35:11: %ASA-6-302015: Built inbound UDP connection 1392894457 for outside:1.1.1.1/500 (1.1.1.1/500) to identity:7.7.7.7/500 ( 7.7.7.7/500) May 11 2021 13:35:11: %ASA-7-713906: IKE Receiver: Packet received on 7.7.7.7:500 from 1.1.1.1:500 May 11 2021 13:35:11: %ASA-5-750002: Local:7.7.7.7:500 Remote:1.1.1.1:500 Username:Unknown IKEv2 Received a IKE_INIT_SA request May 11 2021 13:35:11: %ASA-7-713906: IKE Receiver: Packet received on 7.7.7.7:500 from 1.1.1.1:500 May 11 2021 13:35:11: %ASA-5-750007: Local:7.7.7.7:500 Remote:1.1.1.1:500 Username:1.1.1.1 IKEv2 SA DOWN. Reason: application initiated May 11 2021 13:35:11: %ASA-4-113019: Group = 1.1.1.1, Username = 1.1.1.1, IP = 1.1.1.1, Session disconnected. Session Type: LAN-to-LAN, Duration: 0h:05m:00s, Bytes xmt: 0, Bytes rcv: 0, Reason: IKE Delete May 11 2021 13:35:11: %ASA-5-750006: Local:7.7.7.7:500 Remote:1.1.1.1:500 Username:1.1.1.1 IKEv2 SA UP. Reason: New Connection Established May 11 2021 13:35:11: %ASA-6-113009: AAA retrieved default group policy (GroupPolicy-Def-IKE2) for user = 1.1.1.1 P.S. This is strange, but with another provider, which has the Cisco ASA 5585-SSP10, there are no such problems. -- Sincerely, Denis On Fri, May 7, 2021 at 1:10 PM Tobias Heider <tobias.hei...@stusta.de> wrote: > On Fri, May 07, 2021 at 12:17:35PM +0300, Денис Давыдов wrote: > > Hello all, > > > > I can't understand why I got SA_INIT timeout: > > May 5 13:18:54 crypto-gw2 iked[65530]: spi=0x73bcd531eb2e8899: sa_free: > > SA_INIT timeout > > > > 1.1.1.1 (crypto-gw2) - my host > > 7.7.7.7 - our isp provider (some of cisco devices) > > > > /etc/iked.conf (on 1.1.1.1): > > > > ikev2 crypto-primary active esp \ > > from 10.21.139.8/30 to 2.2.2.2 \ > > from 10.21.139.8/30 to 3.3.3.3 \ > > peer 7.7.7.7 \ > > ikesa auth hmac-sha2-256 enc aes-256 prf hmac-sha2-256 group > modp2048 > > \ > > childsa auth hmac-sha2-256 enc aes-256 group modp2048 \ > > ikelifetime 86400 lifetime 28800 \ > > psk "secret" > > > > The remote side claims to have the same settings. > > > > crypto-gw2# ikectl sh sa | grep 7.7.7.7 > > iked_sas: 0xb0e1878b7d0 rspi 0x2d606f017d098928 ispi 0xd0497626849535cd > > 1.1.1.1:500->7.7.7.7:500<IPV4/217.118.86.15>[] AUTH_SUCCESS i nexti 0x0 > pol > > 0xb0e9b38d000 > > > > Why CHILD_SA is not being created? I tried to figure it out from the logs > > but couldn't. > > > It looks like the peer sends its IKE_AUTH reply without SA payload but > with a TS_UNACCEPTABLE notification. > The most likely cause is that your "from ... to ..." configuration is > incompatible with the configuration of your peer. > > Thanks for the report, I will see how I can make this error more obvious > in the logs. >
