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