Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Thomas_Eichelbu
Advisor
Advisor
Jump to solution

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

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:

NO_LOG.PNG

yes sure logging works!

SOME_LOG.png

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?

0 Kudos
2 Solutions

Accepted Solutions
Thomas_Eichelbu
Advisor
Advisor

wow,  finally TAC made it work ..
iam quite ashamed by this solution, perhaps rebooting the appliance would also have helped 🙂

run:
vpn iked disable
sfwd_restart
and Key Install Logs are back!

View solution in original post

Thomas_Eichelbu
Advisor
Advisor

Hello folks, 

as TAC promised, the new SMB firmware R81.10.10.15 finally fixed this issue!
Key Install Log is back now!

https://support.checkpoint.com/results/sk/sk182438

View solution in original post

8 Replies
Lesley
Leader Leader
Leader

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. 

-------
If you like this post please give a thumbs up(kudo)! 🙂
0 Kudos
Thomas_Eichelbu
Advisor
Advisor

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!

0 Kudos
Alex-
Leader Leader
Leader

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.

0 Kudos
Thomas_Eichelbu
Advisor
Advisor

Hello, 

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

0 Kudos
Thomas_Eichelbu
Advisor
Advisor

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?

0 Kudos
Thomas_Eichelbu
Advisor
Advisor

wow,  finally TAC made it work ..
iam quite ashamed by this solution, perhaps rebooting the appliance would also have helped 🙂

run:
vpn iked disable
sfwd_restart
and Key Install Logs are back!

Thomas_Eichelbu
Advisor
Advisor

Hello folks, 

as TAC promised, the new SMB firmware R81.10.10.15 finally fixed this issue!
Key Install Log is back now!

https://support.checkpoint.com/results/sk/sk182438

Thomas_Eichelbu
Advisor
Advisor

Hello a new update ...

R81.10.15 Build 996003913 is still not 100% working, it still needs a 
vpn iked disable
sfwd_restart
to show key Install logs. but this action at least survives any further reboots.

TAC gave me a special version, which is not yet available: fw1_vx_dep_R81_10_15_996003920.img
this really helped!

now its mission accomplished!

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events