07-24-2018 09:40 AM
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.
07-24-2018 10:05 AM
how about logs from CheckPoint?
what are you / other side seeing in the logs?
07-25-2018 02:43 AM
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
:(
07-25-2018 04:17 AM - edited 07-25-2018 04:21 AM
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
07-25-2018 05:22 AM
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
07-25-2018 06:37 AM
07-25-2018 06:22 AM
on another note, are your local and remote PSKs the same? I see only 1 PSK in your config
07-25-2018 07:31 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide