should i be worried about a key install to an unknown ip from the firewall?

[kb1]

So we had 2 vpn key installs that were successful from the same firewall to different ips (one from mongolia and one from china), should i be worried about that? because all i see in the logs are just the key installs so just 2 logs and no other logs, no exchange of information to those ips,etc. Do i have to investigate something else?

That is how the log looks like, the other key install is also the same but with a different destination ip.

Thanks and Regards.

[PhoneBoy]

You’ll notice it also says “No Proposal Chosen.”
Which means no key was actually installed.

This could be a configuration error on the remote end but I suppose it could also be a reconnaissance attempt by a remote party (portscan or similar).
Something to keep an eye on for sure.

[kb1]

thank you

[tavi0906]

what does it mean " key install " ? 

[PhoneBoy]

It's when symmetric encryption keys are (attempted to be) negotiated between VPN peers.

[Timothy_Hall]

This has been brought up before at CheckMates, basically all UDP 500 traffic is allowed by the firewall and sent to the process vpnd on the gateway which is where all IKE negotiations occur.  You'll see random Internet IPs trying to start IKE negotiations with a "Key Install" log but they won't get anywhere since they are not a defined peer. 

IKEv1 Phase 1 does things in kind of a messed up order of operations by design which is not Check Point's fault.  IKEv1 Phase 1 performs the following three tasks in this order:

• Agree on algorithms to form an SA
• Compute a secret key with Diffie-Hellman
• Authenticate the negotiating peers

The fact that lots of negotiation and a computationally expensive Diffie-Hellman calculation is performed before the peers even authenticate each other should raise alarm bells.  Because the peer has not been authenticated yet, it always possible they are hostile and trying to crash us with malformed or otherwise corrupt negotiations.  For that reason all IKE is handled in the vpnd process instead of the INSPECT/Firewall Worker which traditionally runs in the kernel.  If the vpnd process happens to crash, its parent process fwd simply respawns it immediately, no harm no foul.  However if IKE negotiations took place inside the kernel, a crash caused by the peer in there would cause the whole system to crash.  With the advent of USFW, it will be interesting to see if functions like this that are done for stability reasons in separate processes will end up getting integrated into the INSPECT/fwk/Firewall Worker when USFW is enabled.

IKEv2 resolves this design issue by authenticating the peers first before allowing any other operations.

[VenkateshM]

Hello,

I am documenting Key Install referenced in Harmony Connect logs. Basically, this is one of the reasons for unsuccessful connection between the SD-WAN device and Harmony Connect Secure Web Gateway. Could anyone please explain in simple terms what Key Install is?

[PhoneBoy]

I believe it relates to when the IKE SAs are successfully negotiated between VPN peers (ie they have negotiated their symmetric key used for bulk encryption).

[doom]

hello! could I ask you. how I can block all this unwanted "key installs" from particular ip addresses or networks or countries?

[PhoneBoy]

Yes, see: https://community.checkpoint.com/t5/Security-Gateways/Block-VPN-Traffic-by-Country/m-p/172695

[Lesley]

if you are not using implied rules you just can make a firewall rule. In this firewall rule block ESP (50) and Ike (500). And and make rule that allows the traffic from trused public IP's (remote VPN endpoints)