The ticket
Priya → 10.20.30.41:443 fails. Chat: “NAT,” “IPS,” “cluster,” “Windows firewall.” Sixty seconds in SmartLog beats sixty minutes of theory.
Filter the 5-tuple in Logs & Monitor. The drop line’s Blade tells you which lesson to open next (Access, NAT, TP, HTTPS, IA). Rule tells you first match. If there is no line, either Track is none or the packet never reached the logged path — then fw monitor / SecureXL.
SMS sms-lab 10.10.10.5 · cluster VIP 10.10.10.1 (cp-gw-01 10.10.10.2 / cp-gw-02 10.10.10.3) · external 203.0.113.25 · internal LAN 10.20.30.0/24 · HR PC 10.20.30.80 TECHCLICK\priya.hr · HR app 10.20.30.41 hr.techclick-lab.in. Not a live customer.
What a log line is
One connection (or one drop) from one origin gateway. Fields you must be able to point at:
- Action — Accept / Drop / Reject / Encrypt / Inspect
- Rule — number and name (or implied / TP protection)
- Blade — Firewall, Threat Prevention, HTTPS Inspection, Identity…
- Origin — which member logged it
- Xlate — NAT happened or not
- Source User — IA mapping or empty
SmartLog vs zdebug vs fw monitor
| Tool | When | Cost |
|---|---|---|
| Logs & Monitor | Always first | Low |
| fw monitor | Need positions / NAT in path | Medium |
| fw ctl zdebug + drop | Drop with no useful log | High CPU — short |
Query
Search runbook
Side A — time box
Ask Priya to click once now. Search last 5 minutes, not last 7 days.
Side B — 5-tuple
Source 10.20.30.80 dest 10.20.30.41 service https. Open the drop (or the unexpected accept).
Side C — branch
Blade Firewall + cleanup → rulebase lesson. Blade TP → lesson 9. Empty user → lesson 7. No hit → lessons 11–12.
fw log -n -l | grep 10.20.30.80 # Still read Action / rule. Do not guess from grep noise.
Four log failures
1 · Track is None
The matching rule does not log. You think there is no traffic. Turn Log on that rule (or a temporary log) for the window.
2 · Wrong origin
You filtered member 2. Traffic is on member 1. Search the cluster or both origins.
3 · Looking at Accept, missing later Drop
Layer 1 Accept, layer 2 / TP Drop. Sort by time, read both blades.
4 · Log server full / forwarding broken
Gateway has local logs. SMS SmartLog empty. fw log on the member.
How to prove it
1) You pasted one log line (or “no log”) into the ticket. 2) Blade + rule named. 3) Next lesson matches that blade. 4) You did not reboot anything yet.
Traps
| Symptom | Log story | First proof | Wrong fix |
|---|---|---|---|
| No log at all | Track none or pre-VM drop | Enable log / fw monitor | Rebuild policy |
| Wrong member | Origin filter | cphaprob + Origin | Reset SIC |
| Two lines, opposite actions | Two blades/layers | Timestamps | Ignore the drop |
Knowledge check
Judgment items. One best answer. Reasons send you back to the matching section.
Check Point class series: Architecture · Gaia first day · SIC reset · Objects + first match · Policy layers · Hide vs Static NAT · Identity Awareness · HTTPS Inspection · Threat Prevention · Find the drop · fw monitor · SecureXL · ClusterXL · VPN Community · Policy install lock · vs PA vs Forti · CCSA / CCSE interview
Sources
- SmartConsole — Logs & Monitor / SmartLog user guide for your train.
- CLI:
fw logon the gateway when SMS log view is empty.
Related: Check Point evidence desk · session factory · next lesson in the series above.