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.
>> > > > >
>> > >
>>
>
