First monitor filter when SXL may be on?

Correct: a. Lesson 11 + official -e warning.

Check Point · Quantum R81.20 / R82 · Lesson 12 of 17

SecureXL drop: policy never shows

tcpdump on the NIC shows the SYN. Access log is empty. fw monitor with an old -e filter is empty. SecureXL handled (or dropped) the flow in the fast path. This lesson is acceleration vs the VM — and how to prove it without leaving fwaccel off forever.

Updated 2026-08-18·18 min read·L2 primary·Quiz at end

After this page you can

Say SecureXL is the acceleration path; the VM is the slow path.
Read fwaccel stat / fwaccel stats at a high level.
Explain empty policy logs on some accelerated drops.
Disable acceleration only for a tight test window.
Not confuse CoreXL (many FW instances) with SecureXL (fast path).

The ticket

Same HR SYN. NIC sees it. No Firewall blade log. Junior turns fwaccel off and the log suddenly appears (or the drop moves to the VM). They leave acceleration off. Throughput dies next Monday.

Quick interview answer

SecureXL is the fast path (and from R80.20 fw monitor can see it). Some drops and NATs happen before a classic policy log. Prove with fwaccel stat, -F fw monitor, then a short fwaccel off only if you must force the VM. Turn it back on.

Lab data · dummy only

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.

Fast path vs VM

SecureXL (SXL) tries to accelerate connections after the first packets are classified. CoreXL is multiple firewall instances on CPUs — different feature. fw ctl chain shows sxl_in / sxl_out around the VM.

If a packet is dropped or delivered in SXL, your “rule 40” log may never fire. That is not “policy disappeared.” That is path.

Leave on vs temporary off

Action	When
Keep SecureXL on	Default. Production.
fwaccel off for 2 minutes	To confirm the symptom follows the VM
Feature disable forever	Only with a TAC/SK reason

How you prove it

Side A — NIC vs log
tcpdump sees SYN. SmartLog empty. Suspect SXL or Track none (lesson 10).
Side B — status
fwaccel stat — Accelerator status on/off, which features accept acceleration.
Side C — controlled test
fw monitor -F … first. If still blind, fwaccel off, reproduce, fwaccel on. Never walk away with it off.

dummy

fwaccel stat
# Accelerator Status : on

fwaccel stats
# Look at accelerated vs F2F (forward to firewall) counters — numbers vary

# Tight test only
fwaccel off
# reproduce · watch SmartLog
fwaccel on
fwaccel stat   # must be on again

Four SecureXL failures

1 · Empty log, packet on wire

Accelerated drop or deliver. Use -F monitor / short off test.

2 · NAT or Cluster feature not accelerated

Some topologies force F2F. Not a bug. Read stat / SK for that feature.

3 · Left fwaccel off

CPU in VM spikes. Users slow. Always turn on.

4 · Blaming CoreXL

CoreXL instance imbalance is another ticket. Do not fwaccel off to “fix CoreXL.”

How to prove it

Close the ticket only when

1) You know if the flow is accelerated. 2) SecureXL is ON at the end. 3) The real drop has a name (rule, TP, or SXL reason). 4) Nobody “optimized” by leaving accel off.

Traps

Symptom	Story	Wrong fix
tcpdump yes, log no	SXL or no Track	fwaccel off forever
High CPU after “fix”	Accel left off	Add cores only
Monitor -e empty	Accel + INSPECT filter	Reboot cluster

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

R81 Performance Tuning / Quantum Gateway guides — SecureXL, fwaccel, F2F.
R81 fw monitor page — SecureXL visibility from R80.20; sxl_in/sxl_out in fw ctl chain.

Related: Check Point evidence desk · session factory · next lesson in the series above.