I tried to specify an explicit parameter -T to disable NAT-Traversal
auto-detection and use `local' parameter. Also according to your advice
tried a configuration like this:

ikev2 crypto-primary active esp \
      from any to any \
      local 1.1.1.1 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"

And I got:

May 12 08:45:17 crypto-gw2 iked[17640]: ikev2_pld_payloads: decrypted
payload TSi nextpayload TSr critical 0x00 length 8
May 12 08:45:17 crypto-gw2 iked[17640]: ikev2_pld_tss: count 1 length 0
May 12 08:45:17 crypto-gw2 iked[17640]: ikev2_validate_ts: malformed
payload: too short for header (0 < 8)
May 12 08:45:17 crypto-gw2 iked[17640]: ikev2_validate_pld: malformed
payload: shorter than minimum header size (0 < 4)

Full log: https://pastebin.com/MLC4VXSs

P.S. Tried removing the ikelifetime and lifetime parameters as well. Did
not help, the same behavior.

On Tue, May 11, 2021 at 7:43 PM Tobias Heider <tobias.hei...@stusta.de>
wrote:

> From my limited understanding of cisco ASA configs i can't see any
> obvious problems.
>
> You could try setting 'from any to any' on your side to see how the server
> responds. If the server is configured to narrow traffic selectors, the
> handshake
> should succeed and the log will tell you the exact traffic selectors you
> need
> in your config (look for ikev2_pld_ts in the verbose log).
>
> On Tue, May 11, 2021 at 01:47:53PM +0300, Денис Давыдов wrote:
> > 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.
> > >
>

Reply via email to