Ok, thanks for the clarification! On Fri, May 21, 2021 at 12:30 PM csszep <css...@gmail.com> wrote:
> Hi! > > Not only Cisco ASA. Checkpoint, Fortinet, Juniper only support single set > of subnets per CHILD_SA too. > > https://wiki.strongswan.org/projects/strongswan/wiki/Checkpoint > https://wiki.strongswan.org/projects/strongswan/wiki/Fortinet > https://wiki.strongswan.org/projects/strongswan/wiki/Juniper > https://wiki.strongswan.org/projects/strongswan/wiki/CiscoInteroperability > > Unfortunately the workaround does not always work. IKED established multiple > IKE SA to the same peer if set up separate connection per subnet. > > For example Strongswan drop multiple IKE SA from the same peer if > uniqueid=yes (default setup): > > *Uniqueness* of an IKE_SA, used to drop multiple connections with one peer. > > Of course, for Strongswan, this is not a problem because it handles multiple > SAs per CHILD SA, but other implementation this can be a problem. > > > > > > > Денис Давыдов <dyna...@gmail.com> ezt írta (időpont: 2021. máj. 21., P, > 10:02): > >> 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. >> >>> > > > > >> >>> > > >> >>> >> >> >> >
