It turns out that the Cisco ASA has a bug CSCue42170 with open status that prevents multiple traffic selectors from being supported in one child SA in IKEv2.
For more information: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCue42170/?reffering_site=dumpcr Known affected releases: 8.6(1), 9.1(7.13), 9.4(3.6) On Wed, May 12, 2021 at 7:44 PM Денис Давыдов <dyna...@gmail.com> wrote: > Finally solved! Tried TS one after another. To put it mildly, I'm > surprised. it turns out that the equipment on the remote side is configured > in such a way that for each TS I had to set up a separate connection. This > configuration working fine now: > > ikev2 crypto-primary active esp \ > from 10.21.139.8/30 to 2.2.2.2 \ > 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 "*****" > > ikev2 crypto-primary active esp \ > 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 "*****" > > Tobias, thanks for your time and attention to my problem. > > On Wed, May 12, 2021 at 3:36 PM Денис Давыдов <dyna...@gmail.com> wrote: > >> Tobias, >> >> I replaced the OpenBSD with the same configuration: >> -> % uname -r -p >> 6.9 amd64 >> >> Now, with this configuration: >> >> ikev2 crypto-primary active esp \ >> from any to any \ >> 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 "*****" >> >> I got NO_PROPOSAL_CHOSEN: https://pastebin.com/Puhx41DZ >> >> And with the original configuration, which was agreed with the provider: >> >> 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 "*****" >> >> I still got TS_UNACCEPTABLE: https://pastebin.com/nw0usUJi >> >> I don't know where to dig anymore. The remote side is not responding yet. >> I contacted another provider who shared their configuration from the same >> Cisco model ASA 5585 (IKEv2 works with that hardware without problems). The >> only difference is that they have no these two options (although, I am not >> an expert in Cisco IKEv2 configuration either): >> >> crypto map outside_map 2470 set connection-type answer-only >> crypto map outside_map 2470 set reverse-route >> >> I understand that everyone is already tired of this topic. I will be in >> close contact with this provider. If I can connect to their equipment, I'll >> write what the problem was. Most likely the problem is in their >> configuration, rather than the problem in iked itself. I am sorry for the >> time wasted. >> >> Oh! One more question: Can iked work with the same TS but different peers >> at the same time? Am I correct in understanding that this is not possible? >> The remote side just offers the same settings for two public IP addresses >> from their side (they have two different crypto peers). So far, I just >> commented out the configuration with the second peer. >> >> >> On Wed, May 12, 2021 at 12:33 PM Tobias Heider <tobias.hei...@stusta.de> >> wrote: >> >>> On Wed, May 12, 2021 at 12:06:21PM +0300, Денис Давыдов wrote: >>> > 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) >>> >>> This looks like you're running < 6.9 where any doesn't work for traffic >>> selectors. Either try using 0.0.0.0/0 instead or even better update >>> to the latest version. >>> >>> > >>> > 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. >>> > > > > >>> > > >>> >>
