Route-Based IKEv2 VPN Issue between Cisco FTD and CheckPoint

[afad]

Dear all,

In a customer environment, a problem occurred when establishing a route-based IKEv2 S2S IPsec tunnel between a Cisco Firepower Threat Defense (FTD) appliance running version 7.4.2.2 (FMC-managed) and a Checkpoint firewall.
The IPsec tunnel came up initially but was torn down every two minutes and re-established. Debug logs on both sides provided clear evidence of the issue:

Check Point debug logs showed:

PROCESS INCOMING MESSAGE
Config Payload::Decode: CFG_SET is not supported
Exchange::validateGeneralPayload: incoming Config payload is not OK.
Exchange::processPayloads: problem processing payload no. 1 of type Config payload
Exchange::setStatus: Changing status from: initial to: failure (final)

Cisco FTD debug logs indicated that during the IKEv2 INFORMATIONAL exchange the device sent an encrypted CFG (Configuration) payload:

Initiator SPI : xxx - Responder SPI : xxx Message id: 2
IKEv2 INFORMATIONAL Exchange REQUESTIKEv2-PROTO-5: Next payload: ENCR, version: 2.0 Exchange type: INFORMATIONAL, flags: INITIATOR
Payload contents:
ENCR: Next payload: CFG, reserved: 0x0, length: 68
IKEv2-PROTO-7: SM Trace-> SA: I_SPI=xxx R_SPI=xxx (I) MsgID = 00000002 CurState: INFO_I_BLD_INFO Event: EV_CHK_INFO_TYPE
IKEv2-PROTO-7: SM Trace-> SA: I_SPI=xxx R_SPI=xxx (I) MsgID = 00000002 CurState: INFO_I_WAIT Event: EV_NO_EVENT
IKEv2-PROTO-7: SM Trace-> SA: I_SPI=xxx R_SPI=xxx (I) MsgID = 00000002 CurState: INFO_I_WAIT Event: EV_RE_XMT
IKEv2-PROTO-4: Retransmitting packet

The root cause was that the FTD sent a Mode Config / CFG_SET message during the IKE handshake. Such messages are intended for remote-access VPN scenarios, not for site-to-site tunnels. Check Point does not support CFG payloads in this context and rejected the message. As a result, the IKE session was aborted and the tunnel reset.

The issue was particularly critical because on an FMC-managed FTD, Mode Config behavior cannot be disabled via configuration. This meant the problem could not be solved by tuning the settings.

Resolution:
After investigation, the FTD was upgraded to version 7.4.2.3. In this release, the FTD no longer sends CFG/Mode-Config payloads during site-to-site negotiations. The tunnel then came up successfully and remained stable.

I hope this helps someone, it took me a few hours to solve this.

[MHM Cisco World]

Thanks alot for sharing this info

MHM

[afad]

In my previous post/article, I concluded that a bug in Cisco FTD 7.4.2.2 caused the firewall to send unwanted Mode Config / CFG_SET payloads during IKEv2 negotiations, which Check Point does not support. Upgrading to version 7.4.2.3 initially appeared to fix the problem – the tunnel came up and remained stable for 27 hours.

However, after the tunnel was manually reset from the Check Point side, the issue reappeared: the FTD again started sending CFG payloads in the IKEv2 informational exchange, and the tunnel dropped repeatedly after about 2 minutes. 

The actual cause turned out to be a default setting in FMC that is poorly documented and misleading:
In FMC → Edit VPN Topology → Endpoints → Advanced Settings (per endpoint!)
There is an option: “Send virtual tunnel interface IP to the peer”
This option is enabled by default.

When enabled, the FTD automatically sends the VTI IP address to the peer during IKE negotiation by embedding it in a Mode Config (CFG_SET) payload. Once disabled, the FTD no longer sends any CFG payload during the IKE handshake.
After this change, the tunnel established cleanly and remained stable even after resets initiated from the Check Point side.

Hope this helps someone!