Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
kb1
Collaborator

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

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?

 

key1.PNG

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

 

Thanks and Regards.

0 Kudos
7 Replies
PhoneBoy
Admin
Admin

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.

0 Kudos
kb1
Collaborator

thank you

0 Kudos
tavi0906
Participant

what does it mean " key install " ? 

0 Kudos
PhoneBoy
Admin
Admin

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

0 Kudos
Timothy_Hall
Champion
Champion

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.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
VenkateshM
Employee
Employee

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?

0 Kudos
PhoneBoy
Admin
Admin

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).

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events