IKEv2 policy based VPN with Check Point peer

steverust · ‎07-24-2018

I'm in the process of setting up a new IKEv2 VPN from a Check Point device, terminating on a 1921 router running 15.4(3)M3. This VPN already has an IKEv2 VPN configured to an Azure VPN gateway, which is working without issue, but I'm having issues with the VPN from the Check Point and I'm struggling to understand why that is. Relevant config (where I've changed the information to hide possibly sensitive information, I've added <> around the value):

crypto ikev2 keyring vpn-keyring
 peer <1.1.1.1>
  address <1.1.1.1>
  pre-shared-key <1234>
 
crypto ikev2 proposal vpn-proposal
 encryption aes-cbc-256
 integrity sha256
 group 14
 
crypto ikev2 profile vpn-profile
 match address local <2.2.2.2>
 match identity remote address <1.1.1.1> 255.255.255.255
 authentication remote pre-share
 authentication local pre-share
 keyring local vpn-keyring

crypto ikev2 policy vpn-policy
 proposal vpn-proposal

crypto ipsec transform-set vpn-transform esp-aes 256 esp-sha256-hmac
 mode tunnel
 
ip access-list extended vpn-acl
 permit ip <10.10.10.0 0.0.0.255 3.3.3.0 0.0.0.31>
 permit ip <10.10.11.0 0.0.0.255 3.3.3.0 0.0.0.31>
 permit ip <10.10.12.0 0.0.0.255 3.3.3.0 0.0.0.31>
 permit ip <10.10.13.0 0.0.0.255 3.3.3.0 0.0.0.31>
 permit ip <10.10.14.0 0.0.0.255 3.3.3.0 0.0.0.31>
 permit ip <10.10.15.0 0.0.0.255 3.3.3.0 0.0.0.31>

crypto map VPN 3 ipsec-isakmp
 set peer <1.1.1.1>
 set transform-set vpn-transform
 set pfs group14
 match address vpn-acl
 
interface GigabitEthernet0/0
 description External Interface
 ip address <2.2.2.2> 255.255.255.248
 ip nat outside
 ip virtual-reassembly in
 duplex auto
 speed auto
 crypto map VPN

There's no NAT configured on the device (so ignore the NAT statement from the interface config), and the connection itself isn't traversing any NAT devices.

debug crypto ikev2 packet/internal/error/default - this is what I see in the logs (I've removed everything related to the other VPN):

Jul 24 18:20:15 CEST: IKEv2:Got a packet from dispatcher

Jul 24 18:20:15 CEST: IKEv2:Processing an item off the pak queue

Jul 24 18:20:19 CEST: IKEv2:Got a packet from dispatcher

Jul 24 18:20:19 CEST: IKEv2:Processing an item off the pak queue

Jul 24 18:20:20 CEST: IKEv2:Got a packet from dispatcher

Jul 24 18:20:20 CEST: IKEv2:Processing an item off the pak queue

Jul 24 18:20:20 CEST: IKEv2:New ikev2 sa request admitted
Jul 24 18:20:20 CEST: IKEv2:Incrementing incoming negotiating sa count by one 

Jul 24 18:20:20 CEST: IKEv2:Received Packet [From 1.1.1.1:500/To 2.2.2.2:500/VRF i0:f0] 
Initiator SPI : 73740891450E73D9 - Responder SPI : 0000000000000000 Message id: 0
IKEv2 IKE_SA_INIT Exchange REQUEST
Jul 24 18:20:20 CEST: IKEv2:Next payload: SA, version: 2.0 Exchange type: IKE_SA_INIT, flags: INITIATOR Message id: 0, length: 560 
Payload contents: 
 SA  Next payload: KE, reserved: 0x0, length: 48
  last proposal: 0x0, reserved: 0x0, length: 44
  Proposal: 1, Protocol id: IKE, SPI size: 0, #trans: 4    last transform: 0x3, reserved: 0x0: length: 12
    type: 1, reserved: 0x0, id: AES-CBC
    last transform: 0x3, reserved: 0x0: length: 8
    type: 2, reserved: 0x0, id: SHA256
    last transform: 0x3, reserved: 0x0: length: 8
    type: 3, reserved: 0x0, id: SHA256
    last transform: 0x0, reserved: 0x0: length: 8
    type: 4, reserved: 0x0, id: DH_GROUP_2048_MODP/Group 14
 KE  Next payload: N, reserved: 0x0, length: 264
    DH group: 14, Reserved: 0x0
 N  Next payload: NOTIFY, reserved: 0x0, length: 24

Jul 24 18:20:20 CEST: IKEv2:Parse Notify Payload: NAT_DETECTION_SOURCE_IP NOTIFY(NAT_DETECTION_SOURCE_IP)  Next payload: NOTIFY, reserved: 0x0, length: 28
    Security protocol id: Unknown - 0, spi size: 0, type: NAT_DETECTION_SOURCE_IP

Jul 24 18:20:20 CEST: IKEv2:NOTIFY Type NAT_DETECTION_SOURCE_IP already received  

Jul 24 18:20:20 CEST: IKEv2:Failed to parse the packet: Detected an invalid value in the packet
Jul 24 18:20:20 CEST: IKEv2:Send error response
Jul 24 18:20:20 CEST: IKEv2:Construct Notify Payload: INVALID_SYNTAX 

Jul 24 18:20:20 CEST: IKEv2:Sending Packet [To 1.1.1.1:500/From 2.2.2.2:500/VRF i0:f0] 
Initiator SPI : 73740891450E73D9 - Responder SPI : 24874B68B134E4AE Message id: 0
IKEv2 IKE_SA_INIT Exchange RESPONSE
Jul 24 18:20:20 CEST: IKEv2:Next payload: NOTIFY, version: 2.0 Exchange type: IKE_SA_INIT, flags: RESPONDER MSG-RESPONSE Message id: 0, length: 36 
Payload contents: 
 NOTIFY(INVALID_SYNTAX)  Next payload: NONE, reserved: 0x0, length: 8
    Security protocol id: IKE, spi size: 0, type: INVALID_SYNTAX
 
          
Jul 24 18:20:20 CEST: IKEv2:SM Trace-> SA: I_SPI=73740891450E73D9 R_SPI=24874B68B134E4AE (R) MsgID = 0 CurState: IDLE Event: EV_DELETE
Jul 24 18:20:20 CEST: IKEv2:Action: Action_Null
Jul 24 18:20:20 CEST: IKEv2:SM Trace-> SA: I_SPI=73740891450E73D9 R_SPI=24874B68B134E4AE (R) MsgID = 0 CurState: EXIT Event: EV_ABORT
Jul 24 18:20:20 CEST: IKEv2:SM Trace-> SA: I_SPI=73740891450E73D9 R_SPI=24874B68B134E4AE (R) MsgID = 0 CurState: EXIT Event: EV_CHK_PENDING_ABORT
Jul 24 18:20:20 CEST: IKEv2:Negotiating SA request deleted
Jul 24 18:20:20 CEST: IKEv2:Decrement count for incoming negotiating
Jul 24 18:20:20 CEST: IKEv2:SM Trace-> SA: I_SPI=73740891450E73D9 R_SPI=24874B68B134E4AE (R) MsgID = 0 CurState: EXIT Event: EV_UPDATE_CAC_STATS
Jul 24 18:20:20 CEST: IKEv2:Abort exchange
Jul 24 18:20:20 CEST: IKEv2:Deleting SA
Jul 24 18:20:21 CEST: IKEv2:Got a packet from dispatcher

Jul 24 18:20:21 CEST: IKEv2:Processing an item off the pak queue

Jul 24 18:20:25 CEST: IKEv2:Got a packet from dispatcher

Jul 24 18:20:25 CEST: IKEv2:Processing an item off the pak queue

Jul 24 18:20:27 CEST: IKEv2:Got a packet from dispatcher

Jul 24 18:20:27 CEST: IKEv2:Processing an item off the pak queue

Jul 24 18:20:29 CEST: IKEv2:Got a packet from dispatcher

Jul 24 18:20:29 CEST: IKEv2:Processing an item off the pak queue

Jul 24 18:20:31 CEST: IKEv2:Got a packet from dispatcher

Jul 24 18:20:31 CEST: IKEv2:Processing an item off the pak queue

Jul 24 18:20:33 CEST: IKEv2:Got a packet from dispatcher

Jul 24 18:20:33 CEST: IKEv2:Processing an item off the pak queue

Jul 24 18:20:35 CEST: IKEv2:Got a packet from dispatcher

Jul 24 18:20:35 CEST: IKEv2:Processing an item off the pak queue

This shows that the peer end is sending the right information based on what I've configured, but I can't find any useful information as to what the issue might be from what's being shown in the debugs.

"IKEv2:NOTIFY Type NAT_DETECTION_SOURCE_IP already received" I've looked around for and can't find anything of value.

I currently can't log this with Cisco (as there's no support on the device, I've taken this up with the people responsible) otherwise obviously I'd have done so but in the meantime any help would be appreciated - I have management of both ends here so I can do whatever debugging necessary. I'm at a bit of a loss with the information that I have to hand.

omz · ‎07-24-2018

how about logs from CheckPoint?

what are you / other side seeing in the logs?

steverust · ‎07-25-2018

All the Check Point shows is the message that the IOS router is sending: invalid syntax. Same is seen through the debugs on the Check Point side:

Notify Payload

Critical:		No
Length:			8
Next payload:		None
Protocol:		IKE
Type:			Invalid syntax
spisize:		0

:(

dhgoel · ‎07-25-2018

Hey Steve,

This is a known issue between the IOS and Checkpoint device. Currently, IOS report such error because it receives multiple NAT_DETECTION_SOURCE_IP Payload which is not handled properly by this IOS version . Try the latest version of IOS which will fix this issue.

Jul 24 18:20:20 CEST: IKEv2:Parse Notify Payload: NAT_DETECTION_SOURCE_IP NOTIFY(NAT_DETECTION_SOURCE_IP)  Next payload: NOTIFY, reserved: 0x0, length: 28
    Security protocol id: Unknown - 0, spi size: 0, type: NAT_DETECTION_SOURCE_IP

Jul 24 18:20:20 CEST: IKEv2:NOTIFY Type NAT_DETECTION_SOURCE_IP already received  

Jul 24 18:20:20 CEST: IKEv2:Failed to parse the packet: Detected an invalid value in the packet

This is the bug reported for ASA, however, the same patch was done for IOS devices as well.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCun31725/?reffering_site=dumpcr

Hope this helps.

Regards

Dhruv

steverust · ‎07-25-2018

Thanks for this - I had found information around the ASA but I wasn't sure if it would be relevant in this instance.

Are you able to confirm that upgrading to 15.6.3M4 MD (the latest suggested release) would include this fix? I've searched through the release notes and can't find anything so I wanted to make sure I'm upgrading to a patched version before I go to the customer and arrange for a maintenance window.

Thanks in advance

dhgoel · ‎07-25-2018

Well this bug got fixed in 15.4(03)M04 as per the internal bug. So you can upgrade to 15.4.3M9 Maintenance Deployment (MD) or the latest one which you mentioned.

Dennis Mink · ‎07-25-2018

on another note, are your local and remote PSKs the same? I see only 1 PSK in your config

Please remember to rate useful posts, by clicking on the stars below.

steverust · ‎07-25-2018

Thanks for confirming the version that's needed. I should be able to arrange with the customer to get it installed over the next few days.

To answer your other question, I've tried this keyring config with both a single PSK line as well as separate lines with the local/remote identifiers. I don't think it's possible to define asymmetric keys on the Check Point side (there's certainly no place in the UI for it) so the key would be identical either way.