156-315.81.20 Performance Tuning (SecureXL/CoreXL) Practice Question
A security administrator is troubleshooting a Security Gateway that shows low throughput despite low CPU utilization. The administrator runs 'fwaccel stats -s' and observes that the 'Accelerated' packet count is extremely low, while 'F2F' (Forward to Firewall) packets are high. The administrator wants to understand why traffic is being sent to the Firewall path instead of being accelerated. Which of the following is the most likely reason for this behavior?
⚠ Common exam trap
The trap here is assuming that low CPU utilization always means SecureXL is working optimally, when in fact it could indicate that traffic is bypassing acceleration and being processed by the Firewall path.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The traffic is being processed by the Firewall path due to a feature that is not supported by SecureXL, such as IPsec VPN or NAT with port translation.
SecureXL accelerates only traffic that does not require complex processing. Features like IPsec VPN, NAT with port translation, and deep inspection force packets to the Firewall path, increasing F2F counts. The low accelerated count and high F2F count indicate that a significant portion of traffic is being handled by the Firewall. The administrator should review the rulebase and gateway configuration for such features.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The SecureXL templates are disabled, causing all packets to be forwarded to the Firewall path.
Why it's wrong here
Templates are a performance optimization within SecureXL, but disabling them does not cause all packets to be forwarded to the Firewall path. Templates allow faster creation of new connections, but their absence does not force every packet to be handled by the Firewall kernel. Other factors like unsupported features or outbound inspection would cause F2F, not just template status.
- ✓
The traffic is being processed by the Firewall path due to a feature that is not supported by SecureXL, such as IPsec VPN or NAT with port translation.
Why this is correct
SecureXL cannot accelerate certain traffic types, including IPsec VPN, NAT with port address translation, and connections requiring deep inspection. When such features are applied, packets are forwarded to the Firewall path (F2F) for processing. This results in low accelerated packet counts and high F2F counts, matching the observed statistics. The administrator should verify if any such features are enabled on the relevant rules.
- ✗
The SecureXL device driver is not loaded, so all packets are handled by the Firewall kernel.
Why it's wrong here
If the SecureXL device driver were not loaded, SecureXL would be completely disabled, and the 'fwaccel stats -s' command would not show any accelerated or F2F counts. The presence of F2F counts indicates that SecureXL is active but choosing to forward packets to the Firewall path. The issue is not a missing driver but rather the nature of the traffic or enabled features.
- ✗
The CoreXL firewall instances are not properly distributing traffic, causing a bottleneck on a single core.
Why it's wrong here
CoreXL distributes traffic across multiple firewall instances. If distribution were uneven, CPU utilization would be high on one core and low on others, but the question states low CPU utilization overall. Uneven CoreXL distribution does not directly cause packets to be sent to the Firewall path; it affects how the Firewall path processes packets after they are forwarded. The low accelerated count points to a different cause.
Visual reference
Quick reference
VPN Protocol Comparison
| Protocol | Port | Encryption | Authentication | Use Case |
|---|---|---|---|---|
| IKEv2 / IPsec | UDP 500 / 4500 | AES-256 | Certificates / PSK | Site-to-site & remote access |
| SSL / TLS VPN | TCP 443 | TLS 1.3 | Certificates / MFA | Clientless remote access |
| L2TP / IPsec | UDP 1701 | AES (IPsec) | PSK / Certificates | Legacy remote access |
| WireGuard | UDP 51820 | ChaCha20 | Public keys | Modern high-performance VPN |
| PPTP | TCP 1723 | MPPE (weak) | MS-CHAPv2 | Legacy — avoid in production |
PPTP is considered insecure. IKEv2/IPsec and SSL VPN are the current recommended options.
About these practice questions
Courseiva writes every 156-315.81.20 question from scratch — 210 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Check Point exam blueprint
This 156-315.81.20 practice question is part of Courseiva's free Check Point certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 156-315.81.20 exam.