[solved] Need help with IKEv2 IPsec to Cisco ASA

[Colani1200]

Im am currently migrating a bunch of IPsec tunnels from a different platform to OPNsense. I am having trouble with one particular tunnel to a customer running a Cisco ASA (with current firmware 9.14.2-15). The tunnel is using IKEv2 with multiple Phase 2 entries. Symptoms look like this:

- After a fresh boot of OPNsense, the tunnel usually comes up fine with all phase 2 entries. Phase 2 entries disconnect after a while when there is no relevant traffic. In the log, it looks like this:

Code: [Select]

Jun 01 21:26:17 zzz.zzz.zzz.zzz charon[76496]: 09[IKE] <con3|2> sending DELETE for ESP CHILD_SA with SPI c2e6e74f
Jun 01 21:26:17 zzz.zzz.zzz.zzz charon[76496]: 09[ENC] <con3|2> generating INFORMATIONAL request 32 [ D ]
Jun 01 21:26:17 zzz.zzz.zzz.zzz charon[76496]: 09[NET] <con3|2> sending packet: from xxx.xxx.xxx.xxx[500] to yyy.yyy.yyy.yyy[500] (80 bytes)
Jun 01 21:26:17 zzz.zzz.zzz.zzz charon[76496]: 09[NET] <con3|2> received packet: from yyy.yyy.yyy.yyy[500] to xxx.xxx.xxx.xxx[500] (80 bytes)
Jun 01 21:26:17 zzz.zzz.zzz.zzz charon[76496]: 09[ENC] <con3|2> parsed INFORMATIONAL response 32 [ D ]
Jun 01 21:26:17 zzz.zzz.zzz.zzz charon[76496]: 09[IKE] <con3|2> received DELETE for ESP CHILD_SA with SPI cc1b7fcb
Jun 01 21:26:17 zzz.zzz.zzz.zzz charon[76496]: 09[IKE] <con3|2> CHILD_SA closedAfterwards, it is possible to initiate the phase 2 in question from the OPNsense side by sending traffic, but not the other way round. Usually the OPNsense log stays completely silent, or you'll find something like this:

Code: [Select]

Jun 11 16:53:39 zzz.zzz.zzz.zzz charon[57826]: 15[IKE] <con9|1> traffic selectors aaa.aaa.aaa.aaa/32 bbb.bbb.bbb.bbb/24 === ccc.ccc.ccc.ccc/32 ddd.ddd.ddd.ddd/24 unacceptable(Trying to ping from ccc.ccc.ccc.ccc/32 on the Cisco side to aaa.aaa.aaa.aaa/32 on the OPNsense side. bbb.bbb.bbb.bbb/24 is the left side and ddd.ddd.ddd.ddd/24 the right side in the phase 2 definition)

- When no traffic at all from either side is sent, the tunnel will disconnect completely. Afterwards it takes multiple tries to get it up again by sending traffic. During connection attempts, the log shows something like this:

Code: [Select]

Jun 16 09:17:26 zzz.zzz.zzz.zzz charon[69339]: 11[IKE] <con9|5> retransmit 1 of request with message ID 1
Jun 16 09:17:26 zzz.zzz.zzz.zzz charon[69339]: 11[NET] <con9|5> sending packet: from xxx.xxx.xxx.xxx[4500] to yyy.yyy.yyy.yyy[4500] (304 bytes)
Jun 16 09:17:26 zzz.zzz.zzz.zzz charon[69339]: 11[MGR] <con9|5> checkin IKE_SA con9[5]
Jun 16 09:17:26 zzz.zzz.zzz.zzz charon[69339]: 03[NET] sending packet: from xxx.xxx.xxx.xxx[4500] to yyy.yyy.yyy.yyy[4500]
Jun 16 09:17:26 zzz.zzz.zzz.zzz charon[69339]: 11[MGR] <con9|5> checkin of IKE_SA successful
Jun 16 09:17:33 zzz.zzz.zzz.zzz charon[69339]: 11[MGR] checkout IKEv2 SA with SPIs d658a65316b4cd4a_i 1f37e0b747a28c00_r
Jun 16 09:17:33 zzz.zzz.zzz.zzz charon[69339]: 11[MGR] IKE_SA con9[5] successfully checked out
Jun 16 09:17:33 zzz.zzz.zzz.zzz charon[69339]: 11[IKE] <con9|5> retransmit 2 of request with message ID 1
Jun 16 09:17:33 zzz.zzz.zzz.zzz charon[69339]: 11[NET] <con9|5> sending packet: from xxx.xxx.xxx.xxx[4500] to yyy.yyy.yyy.yyy[4500] (304 bytes)
Jun 16 09:17:33 zzz.zzz.zzz.zzz charon[69339]: 11[MGR] <con9|5> checkin IKE_SA con9[5]
Jun 16 09:17:33 zzz.zzz.zzz.zzz charon[69339]: 03[NET] sending packet: from xxx.xxx.xxx.xxx[4500] to yyy.yyy.yyy.yyy[4500]
Jun 16 09:17:33 zzz.zzz.zzz.zzz charon[69339]: 11[MGR] <con9|5> checkin of IKE_SA successful
Jun 16 09:17:46 zzz.zzz.zzz.zzz charon[69339]: 11[MGR] checkout IKEv2 SA with SPIs d658a65316b4cd4a_i 1f37e0b747a28c00_r
Jun 16 09:17:46 zzz.zzz.zzz.zzz charon[69339]: 11[MGR] IKE_SA con9[5] successfully checked out

Any idea how to get this going? Is there a way to force keeping the tunnel up even when there is no traffic (preferrably without ping workaround)? Once it is up it seems to work fine...

[atom]

I had the same problem with IKEv2 and Cisco.
The SAs were automatically closed after ~30 minutes.
So I set the lifetime for each SA to 1800.

[Colani1200]

After a lot of painful research, try and error, I found the solution: Set "disable dpd" and “vpn-idle-timeout none” on the Cisco side. I hope this will help anybody with the same problem.