action:Key Install Missing in SmartLog for Quantum Spark, am i crazy?

[Thomas_Eichelbu]

Hello team, 

i am wondering how this is possible.
i have a bunch of Quantum Sparks 1535 running, latest firmware "fw1_vx_dep_R81_10_10_996002945.img"
when i search in SmartLog for VPN activity i see no more "action:KeyInstall" and origin:GATEWAY.

for Full GAiA yes of course ... this still works.
but Quantum Spark, no.

take a look:

yes sure logging works!

so i suspect with some kind of firmware version this stopped to work.
with all my 1430 running this works just fine ...
i also saw this on other customer running Quantum Spark 15XX and "fw1_vx_dep_R81_10_10_996002945.img" or earlier ...

what is going on here?

[Lesley]

Maybe this is usefull

https://sc1.checkpoint.com/documents/SMB_R81.10.X/CLI/EN/Content/Topics/set-vpn-site-to-site-log-vpn...

Not sure if it works if it is central mgmt. 

[Thomas_Eichelbu]

Hello Lesley, 

oh thank you very much to enlighten me ... lets check my (default) values

XXXXXXX> show vpn site-to-site advanced-settings
sync-sa-with-other-cluster-members:200000
period-before-crl-valid: 7200
delete-tunnel-sas-on-tt-fail: true
harmony-connect-residency:
udp-encapsulation-for-firewalls-and-proxies:true
copy-diff-serv-from-ipsec-packet:false
dpd-triggers-new-ike-negotiation:true
tunnel-test-from-internal: false
outgoing-rulebase-match: false
harmony-connect-ha-timeout-sec:30
ike-dos-protection-known-sites:none
enable-link-selection: true
limit-open-sas: 20
is-static-misp-role: false
copy-diff-serv-to-ipsec-packet:true
keep-dont-fragment-flag-on-packet:false
vpn-down-summary-interval: 1_Hour
period-after-crl-not-valid: 1800maximum-concurrent-vpn-tunnels:10000

log-vpn-packet-handling-errors:log

life-sign-transmitter-interval:10
delete-ike-sas-from-a-dead-peer:true
vpn-tunnel-sharing: subnets
vpn-configuration-and-key-exchange-errors:log
ikev2-key-type: KEY_ID
reply-from-incoming-interface:false
bypass-psl-inspection: false
resolver-Session-interval: 25
no-local-dns-encrypt: false
is-admin-access-agnostic: true
keep-ikesa-keys: auto-mode
vpn-down-max-notification: 5
life-sign-timeout: 120
is-Passthrough-Active: false
reply-from-same-ip: true
collect-hb-monitoring-info: true
local-conns-from-internal: false
ike-dos-protection-unknown-sites:none
vpn-dns-resolver-interval: 30
harmony-connect-check-branch-used:false
maximum-concurrent-ike-negotiations:200

log-vpn-outgoing-link: nonepermanent-tunnel-down-track: log
permanent-tunnel-up-track: log
log-vpn-successful-key-exchange:log
log-notification-for-administrative-actions:log

timeout-for-an-rdp-packet-reply:10
check-validity-of-ipsec-reply-packets:false
perform-ike-using-cluster-ip: true
harmony-connect-check-subnet: false
ike-use-largest-possible-subnets:true
no-local-conns-encrypt: false
delete-ipsec-sas-on-ikes-delete:false

so yes it seems all the required log actions are set to true and always on true by default .. .nonetheless i have no logs.
so if the log action is set to log, but it doesnt log, i consider this a bug.
at least iam happy, removing vital logs is not made on purpose... i was afraid Check Point was giving way to the cancel culture by avoiding unfriendly logs!

[Alex-]

Probably a bug, I don't see this with centrally managed Spark running lower versions than R81.10.10 - which by the way is not yet recommended as per sk179615.

[Thomas_Eichelbu]

Hello, 

yes TAC case opened ... lets see what we find out.

[Thomas_Eichelbu]

Hi, 

investigation by TAC is still ongoing, with not much output so far.
Iam running all appliances which do not show "Action:Key Install" logs, on: R81.10.10 (996002945)
and one working one on: R81.10.08 (996001608)

TAC advised me to downgrade one to: R81.10.08 (996001750).
Iam not happy with downgrading. Because if R81.10.08 (996001750) makes it work, TAC will close the ticket and when we upgrade to R81.10.10 again in the future, the issue could strike again, its just delaying ... 

is anybody running R81.10.08 (996001750) and still see "action:Key Install" in the log?