Questions for the 156-587 were updated on : Dec 01 ,2025
VPNs allow traffic to pass through the Internet securely by encrypting the traffic as it enters the VPN
tunnel and decrypting the traffic as it exits. Which process is responsible for Mobile VPN
connections?
A
Explanation:
The Check Point process responsible for Mobile VPN connections, particularly those associated with
the Mobile Access Software Blade (which includes SSL VPN and clientless access), is cvpnd
(Connectra VPN Daemon).
Exact Extracts and Supporting Information:
Check Point CLI Reference Guide (for cvpnd_admin):
"cvpnd_admin. Description. Changes the behavior of the Mobile Access cvpnd process."
This command utility directly interacts with cvpnd for Mobile Access functionalities.
Check Point Daemon Lists (e.g., from "tech :: stuff - Checkpoint Daemons and Processes Explained" or
similar CCTE R81.20 documentation):
Under the "Mobile Access Blade" section, CVPND is typically listed as:"CVPND - Connectra VPN
Daemon. Main daemon for the Mobile Access Software Blade."
It's also often noted that the cpwd_admin list command (Check Point WatchDog) shows this process
as "CVPND".
Commands like cvpnstart and cvpnstop are used to manage this daemon.
Exam Preparation Materials (e.g., ExamTopics for 156-586):
A question directly asking "Which process is responsible for Mobile VPN connections?" with options
including cvpnd, vpnk, fwk, and vpnd, typically indicates cvpnd as the correct answer.
Explanation of other options:
B . fwk: This is a general suffix often related to firewall worker processes or kernel modules, not a
specific high-level daemon for Mobile VPN.
C . vpnd: This is the main VPN daemon, primarily responsible for site-to-site IPsec VPNs and some
traditional IPsec remote access clients. While it handles VPN functions, cvpnd is specialized for
Mobile Access.
D. vpnk: This refers to VPN kernel-level operations and modules (e.g., handling the actual
encryption/decryption of traffic processed by IPsec SAs). It is not the user-space daemon that
manages Mobile VPN sessions and policies.
Therefore, cvpnd is the specific process dedicated to managing Mobile VPN connections within the
Check Point architecture.
Reference (based on official Check Point documentation naming and functionality):
Check Point R81.20 CLI Reference Guide (details for cvpnd_admin).
Check Point R81.20 Administration Guides (sections discussing Mobile Access architecture and
daemons).
Commonly known Check Point process lists available in CCTE study materials.
Which kernel process is used by Content Awareness to collect the data from contexts?
C
Explanation:
The kernel component associated with Content Awareness and data collection from contexts (often
provided by the Context Management Infrastructure - CMI) is dlpda.
According to the Check Point R81.20 Quantum Security Gateway Administration Guide, within the
listing of kernel modules, dlpda is described as follows:
Exact Extract:
Module "dlpda" (Data Loss Prevention - Download Agent for Content Awareness)
Explanation:The dlpda module functions as a "Download Agent for Content Awareness." This role
involves collecting data necessary for the Content Awareness blade to inspect and understand the
content of traffic. The Content Awareness blade works in conjunction with the Context Management
Infrastructure (CMI), which provides the initial context about the traffic. The dlpda component then
uses these contexts to gather the relevant data for deeper inspection and to determine if the content
matches any defined data types or policies. While the guide lists it as a "Module," exam questions in
the CCTE context often refer to such components involved in kernel operations as "kernel processes."
The function described clearly aligns with collecting data for Content Awareness.
Options analysis:
A . PDP (Policy Decision Point): This process is primarily associated with Identity Awareness for
making access decisions based on user identity, not directly for Content Awareness data collection
from CMI contexts.
B . cpemd (Check Point Endpoint Management Daemon): This daemon is related to endpoint security
management and does not fit the role of a kernel process for gateway-level Content Awareness data
collection.
D . CMI (Context Management Infrastructure): CMI is an infrastructure that provides contexts to
various blades, including Content Awareness. It is the source of the contexts, not the kernel process
that collects data based on those contexts.
Therefore, dlpda is the kernel component specifically tasked with collecting data for Content
Awareness.
Reference:
Check Point R81.20 Quantum Security Gateway Administration Guide (The specific page number for
the module listing, e.g., page 360, as found in typical versions of this guide for R81.x releases).
RAD is initiated when Application Control and URL Filtering blades are active on the Security
Gateway. What is the purpose of the following RAD configuration file $FWDIR/conf/rad_settings.C?
C
Explanation:
The Resource Application Daemon (RAD) is a critical component in Check Point’s Application Control
and URL Filtering blades, responsible for processing and categorizing web traffic. The configuration
file $FWDIR/conf/rad_settings.C on the Security Gateway defines settings related to RAD’s operation.
Option A: Incorrect. The rad_settings.C file does not store entitlement information for Application
Control or URL Filtering. Entitlements are managed by the Security Management Server and stored
in licensing databases, not in this file.
Option B: Incorrect. The rad_settings.C file does not specify how the Security Gateway communicates
with the Security Management Server’s RAD service. Communication settings are typically handled
by SIC (Secure Internal Communication) and other configuration files, such as
$FWDIR/conf/fwopsec.conf.
Option C: Correct. The rad_settings.C file contains proxy settings for the RAD daemon, such as HTTP
proxy configurations used for accessing external services (e.g., Check Point’s online URL Filtering
database). This is critical when the Gateway requires a proxy to reach external resources for URL
categorization.
Option D: Incorrect. Hostname settings for the online application detection engine are not stored in
rad_settings.C. These are typically managed by the Application Database (application_db.C) or
resolved via DNS.
Reference:
The Check Point R81.20 Security Gateway Administration Guide discusses the RAD daemon and its
configuration, noting that $FWDIR/conf/rad_settings.C is used for proxy settings related to
Application Control and URL Filtering. The CCTE R81.20 course covers troubleshooting Application
Control and URL Filtering, including the role of configuration files like rad_settings.C.
For precise details, refer to:
Check Point R81.20 Security Gateway Administration Guide, section on “Application Control and URL
Filtering” (available via Check Point Support Center).
CCTE R81.20 Courseware, which includes modules on RAD configuration and troubleshooting
(available through authorized training partners like Arrow Education or Red Education).
Which two files contain the Application Database on the Security Gateway?
C
Explanation:
The Application Database on a Check Point Security Gateway stores information about applications
and categories used by the Application Control and URL Filtering blades. This database is maintained
in specific files on the Gateway.
Option A: Incorrect. api_db.C and api_custom_db.C are not standard files related to the Application
Database. These names may be confused with API-related configurations.
Option B: Incorrect. apcl_db.C and apd_custom_db.C are not recognized as Application Database
files. These names do not align with Check Point’s file naming conventions.
Option C: Correct. The Application Database is stored in application_db.C (the main database) and
application_custom_db.C (custom application definitions). These files are located in the
$FWDIR/conf directory on the Security Gateway.
Option D: Incorrect. appi_db.C and appi_custom_db.C are close but incorrect. The correct prefix is
application_, not appi_.
Reference:
The Check Point R81.20 Security Gateway Administration Guide describes the Application Control
and URL Filtering blades, including the storage of application data in application_db.C and
application_custom_db.C. The CCTE R81.20 course covers file structures and database management
for troubleshooting Application Control issues.
For precise details, refer to:
Check Point R81.20 Security Gateway Administration Guide, section on “Application Control and URL
Filtering” (available via Check Point Support Center).
CCTE R81.20 Courseware, which includes labs on Application Database management (available
through authorized training partners).
You need to monitor traffic pre-inbound and before the VPN module in a Security Gateway. How
would you achieve this using fw monitor?
B
Explanation:
The fw monitor command is a powerful troubleshooting tool in Check Point Gateways that captures
packets at various points in the processing chain. The question asks how to capture traffic pre-
inbound (before inbound processing, i.e., at the “i” inspection point) and before the VPN module
(before VPN decryption or processing).
The fw monitor syntax allows specifying inspection points using options like -pi (pre-inbound) and
module names (e.g., -vpn for the VPN module). The correct syntax to capture traffic before a specific
module is -pi -<module>, where the module name is prefixed with a minus sign to indicate “before”
the module.
Option A: Incorrect. fw monitor -p all captures packets at all inspection points in the chain, which
includes pre-inbound, post-inbound, pre-outbound, and post-outbound points, as well as points
around all modules. This is too broad and does not specifically target pre-inbound and before the
VPN module.
Option B: Correct. fw monitor -pi -vpn captures packets at the pre-inbound inspection point (“i”) and
before the VPN module (-vpn). The -pi specifies the pre-inbound point, and -vpn ensures the capture
occurs before VPN processing (e.g., decryption).
Option C: Incorrect. fw monitor -pi +vpn would capture packets at the pre-inbound point but after
the VPN module (+vpn indicates after the module), which contradicts the requirement to capture
before the VPN module.
Option D: Incorrect. This option is a duplicate of Option C in the provided question, likely a
typographical error. Even if corrected, +vpn is incorrect for the same reason as Option C.
Reference:
The Check Point R81.20 Gaia Administration Guide explains the fw monitor command and its
options, including how to specify inspection points and module positions. The CCTE R81.20 course
includes hands-on labs for using fw monitor to troubleshoot packet flow, emphasizing precise
inspection point selection.
For precise details, refer to:
Check Point R81.20 Gaia Administration Guide, section on “fw monitor” (available via Check Point
Support Center).
CCTE R81.20 Courseware, which covers advanced packet capture techniques with fw monitor
(available through authorized training partners).
What is NOT monitored as a PNOTE by ClusterXL?
A
Explanation:
ClusterXL is Check Point’s high-availability and load-sharing solution, which monitors critical
components to ensure cluster functionality. PNOTEs (Problem Notifications) are specific conditions or
processes monitored by ClusterXL to detect failures or issues that could impact the cluster’s
operation. When a PNOTE is triggered, ClusterXL may initiate a failover to maintain service
continuity.
Option A: Correct. TED (Threat Emulation Daemon) is not monitored as a PNOTE by ClusterXL. TED is
part of the Threat Emulation blade, which handles sandboxing and emulation tasks, but it is not a
critical cluster component monitored by ClusterXL.
Option B: Incorrect. Policy installation status is monitored as a PNOTE by ClusterXL. If a policy fails to
install or becomes corrupted, ClusterXL can detect this as a critical issue and trigger a failover.
Option C: Incorrect. RouteD (Routing Daemon) is monitored as a PNOTE by ClusterXL. Routing issues,
such as the failure of dynamic routing protocols, are critical for cluster operations, especially in
environments with dynamic routing enabled.
Option D: Incorrect. VPND (VPN Daemon) is monitored as a PNOTE by ClusterXL. VPN functionality is
critical in many deployments, and ClusterXL monitors VPND to ensure VPN tunnels remain
operational.
Reference:
The Check Point R81.20 ClusterXL Administration Guide details the components monitored by
ClusterXL via PNOTEs, including policy installation, routing (RouteD), and VPN (VPND). The CCTE
R81.20 course covers ClusterXL troubleshooting, including understanding PNOTEs and their role in
failover decisions. While TED is part of Check Point’s Threat Prevention suite, it is not listed as a
PNOTE in ClusterXL documentation.
For precise details, refer to:
Check Point R81.20 ClusterXL Administration Guide, section on “Problem Notification (PNOTE)”
(available via Check Point Support Center).
CCTE R81.20 Courseware, which includes modules on ClusterXL monitoring and troubleshooting
(available through authorized training partners like Arrow Education or Red Education).
You run cpwd_admin list on a Security Gateway and notice that the CPM process is not listed. Select
the best answer.
A
Explanation:
The cpwd_admin list command is used to display the status of processes monitored by the Check
Point WatchDog Daemon (CPWD). The CPM (Check Point Management) process is a core process on
the Security Management Server, responsible for management operations. However, on a Security
Gateway, the CPM process is not typically present, as it is specific to management functions.
Option A: Correct. The output of cpwd_admin list differs between a Security Gateway and a Security
Management Server. On a Security Gateway, processes like FWD, VPND, and PEP are monitored, but
CPM is not present because it runs on the Management Server. Thus, CPM will not appear in the
cpwd_admin list output on a Gateway.
Option B: Incorrect. While it’s true that CPM is not running on the Security Gateway, the reason it’s
not listed is not because it “can’t be monitored” by CPWD. On a Management Server, CPM is indeed
monitored by CPWD, but this question pertains to a Gateway.
Option C: Incorrect. CPM is automatically monitored by CPWD on systems where it runs (e.g.,
Management Server). There is no need to manually add it to WatchDog’s monitoring list.
Option D: Incorrect. CPM does not have its own separate monitoring system. On a Management
Server, CPM is monitored by CPWD like other critical processes. The statement about “only lower
processes” being monitored is inaccurate.
Reference:
The Check Point R81.20 Gaia Administration Guide explains the role of CPWD and the processes it
monitors on different Check Point systems (Gateway vs. Management Server). The CCTE R81.20
course (as per and) emphasizes understanding the differences in process monitoring between
Gateways and Management Servers, including the use of cpwd_admin commands for
troubleshooting.
https://edu.arrow.com/uk/training/course-detail/90175/Check-Point-Certified-
Troubleshooting-Expert-%28CCTE%29-R81.20-%28includes-180-days%27-lab-access%29/False
https://www.koenig-solutions.com/ccte-r81-20-language-course
For precise details, refer to:
Check Point R81.20 Gaia Administration Guide, section on “CPWD and Process Monitoring” (available
via Check Point Support Center).
CCTE R81.20 Courseware, which covers advanced troubleshooting of Security Gateway and
Management Server processes (available through authorized training partners).
In the Security Management Architecture, what port and process does SmartConsole use to
communicate with the Security Management Server?
A
Explanation:
In Check Point’s Security Management Architecture, SmartConsole is the graphical user interface
used to manage the Security Management Server. The communication between SmartConsole and
the Security Management Server relies on specific processes and ports, which are critical for
troubleshooting connectivity issues.
The CPM (Check Point Management) process is the primary process on the Security Management
Server responsible for handling management operations, including interactions with SmartConsole.
The default port for this communication is 18190 (TCP), used for the SIC (Secure Internal
Communication) and management GUI connections.
Option A: Correct. SmartConsole communicates with the Security Management Server using the
CPM process over port 18190. This port is used for GUI client connections to the management server.
Option B: Incorrect. The FWM (Firewall Management) process is an older process used in earlier
Check Point versions (pre-R80) for management tasks. In R81.20, CPM has largely replaced FWM for
SmartConsole communications. Additionally, port 19009 is used for other purposes, such as the
Check Point REST API, not SmartConsole.
Option C: Incorrect. While CPM is the correct process, port 19009 is not used for SmartConsole
communication. Port 19009 is associated with the Check Point Management API (e.g., for mgmt_cli
or REST API calls).
Option D: Incorrect. While CPM is involved, SmartConsole does not use both ports 19009 and 18191.
Port 18191 is typically used for log server communications (e.g., SmartConsole to Log Server), not
direct management server communication.
Reference:
The Check Point R81.20 Security Management Administration Guide explicitly details the ports used
in the management architecture. According to the guide:
Port 18190/TCP is used for SmartConsole to Security Management Server communication via the
CPM process.
The CCTE R81.20 course (as referenced in and) covers advanced management server
troubleshooting, including understanding the CPM process and its associated
ports.
https://www.koenig-solutions.com/ccte-r81-20-language-course
https://www.rededucation.com/events/1056-check-point-troubleshooting-expert-ccte-r81-20-
spanish-language/region-US/
For exact extracts, refer to:
Check Point R81.20 Security Management Administration Guide, section on “Communication Ports”
(available via Check Point Support Center).
CCTE R81.20 Courseware, which includes modules on management server diagnostics and
communication protocols (available through authorized training partners).
You receive reports that Users cannot browse internet sites. You are using identity awareness with
AD Query and Identity Collector in addition you have the Browser Based Authentication Enabled.
What command can be used to debug the problem?
D
Explanation:
Identity Awareness is a feature that enables the Security Gateway to identify users and groups
behind IP addresses, and apply security policies based on their identity12
.
Identity Awareness uses
different methods to acquire identities, such as AD Query, Identity Collector, and Browser-Based
Authentication12
.
To debug Identity Awareness issues, you need to use the command pdp debug on
the gateway, where pdp stands for Policy Decision Point, the component that handles the identity
acquisition and enforcement13
.
The command pdp debug has different flags for different identity
sources, such as adlog for AD Query, ic for Identity Collector, and nac for Browser-Based
Authentication13
.
The flag extended enables more detailed debug output13
.
Therefore, the correct
command to debug the problem of users not being able to browse internet sites with Identity
Awareness using AD Query, Identity Collector, and Browser-Based Authentication is pdp debug nac
extended on the gateway13
. The other options are incorrect because they either use the wrong
command (ad debug instead of pdp debug), the wrong flag (ad query instead of nac), or the wrong
location (on the management instead of on the gateway). Reference:
: CCTE Courseware, Module 9: Advanced Identity Awareness Troubleshooting, Slide 4
: Check Point R81 Identity Awareness Administration Guide, Chapter 1: Introduction to Identity
Awareness, Page 7
: Check Point R81 Identity Awareness Administration Guide, Chapter 5: Troubleshooting Identity
Awareness, Page 49
URL Filtering is an essential part of Web Security in the Gateway. For the Security Gateway to
perform a URL lookup when a client makes a URL request, where is the sync-request forwarded from
if a sync-request is required?
C
Explanation:
When a Security Gateway performs a URL lookup and the URL is not found in the local caches, a
request for online categorization is necessary. This process involves the Resource Advisor Daemon
(RAD), which has components in both kernel space and user space.
Based on descriptions of the URL Filtering categorization process (often cited in CCTE R81.20
materials):
A client (internal component, potentially the URLF Kernel Client or a similar kernel module handling
the traffic) initiates a URL lookup.
The URL is first checked against kernel caches.
If the URL is not found in the kernel cache (a cache miss), the RAD kernel component is notified.
The client component then typically sends an asynchronous request to the RAD kernel component.
The RAD Kernel Space component is then responsible for forwarding this request to the RAD User
Space module.
The RAD User Space module handles the actual online categorization, often by querying the URLF
Online Service (Check Point's cloud-based categorization service).
The result is then returned, and the kernel cache is updated.
The question asks where the sync-request (or a request requiring immediate online lookup) is
forwarded from. In this flow, the RAD Kernel Space acts as the intermediary that forwards the
request from the initial kernel-level lookup mechanism to the user-space RAD process for further
handling.
Supporting Information (derived from CCTE R81.20 related materials/discussions):
The typical flow for URL categorization when an online lookup is needed involves these steps:
"The kernel cache notifies the RAD kernel of hits and misses."
"The client sends an a-sync request back to RAD if the URL was not found." (This request goes to the
RAD Kernel Space).
"The a-sync request is forwarded to the RAD User space via the RAD kernel for online categorization."
This indicates that the RAD Kernel (RAD Kernel Space) is the component that forwards the request to
the RAD User Space.
Therefore, if a sync-request (a request needing immediate online lookup) is required, it is forwarded
from the RAD Kernel Space to the RAD User Space.
Reference Context (based on CCTE R81.20 materials and general Check Point URL Filtering
architecture):
Discussions and explanations related to Check Point Certified Troubleshooting Expert (CCTE) R81.20
curriculum often detail this RAD architecture. For example, study materials might state: "RAD has a
kernel module that looks up the kernel cache, notifies client about hits and misses and forwards a-
sync requests to RAD user space module which is responsible for online categorization." The 1 "RAD
kernel module" corresponds to the RAD Kernel Space, and it is this component that performs the
forwarding action to the RAD User Space.(Exact page numbers like "CCTE R81.20, p338/339" have
been referenced in public CCTE exam discussions pointing to this flow)
Which of the following inputs is suitable for debugging HTTPS inspection issues?
A
Explanation:
The input that is suitable for debugging HTTPS inspection issues is fw debug tls on
TDERROR_ALL_ALL=5. This input will enable the TLS debug mode and set the debug level to 5, which
is the highest level of verbosity. The fw debug command is used to control the debug features of the
firewall modules, such as TLS, CPTLS, HTTP, etc. The tls option will enable the debug mode for the TLS
module, which is responsible for handling the HTTPS inspection feature.
The TDERROR_ALL_ALL environment variable will set the debug level to 5, which will generate the
most detailed and comprehensive debug output.
The debug output will be written to
the $FWDIR/log/tls.elg file, which can be collected and analyzed with the TLSView tool1
to see the
details of the HTTPS inspection process, such as certificate validation, SSL/TLS negotiation,
encryption/decryption, etc. The other options are incorrect because:
fw ctl debug -m fw + conn drop cptls will enable the kernel debug mode for the firewall module, with
the flags conn, drop, and cptls. The kernel debug mode will generate the kdebug.txt file in
the $FWDIR/log directory, which contains information about the firewall traffic processing in the
kernel.
The kernel debug mode is useful for troubleshooting issues related to policy, NAT, routing,
and inspection, but not for issues related to HTTPS inspection, which is handled by the TLS module in
the user space2
.
vpn debug cptls on will enable the IKE debug mode for the CPTLS module, which is a component of
the VPN module. The IKE debug mode will generate the ike.elg and ikev2.xmll files in
the $FWDIR/log directory, which contain information about the IKE negotiation, authentication, and
key exchange between the VPN peers.
The CPTLS module is responsible for handling the SSL/TLS
encryption/decryption for the VPN traffic, but not for the HTTPS inspection traffic3
.
fw diag debug tls enable is not a valid command and will not enable the TLS debug mode. The fw
diag command is used to control the diagnostic features of the firewall, such as packet capture, core
dump, etc. The debug option is not a valid option for the fw diag command, and the tls option is not
a valid option for the debug option. Reference:
How to use the TLSView tool
How to debug the Firewall kernel (fw) module
How to debug VPN issues on Quantum Spark (SMB) Appliances
[fw diag - Check Point CLI Reference Card]
Which of the following would NOT be a flag when debugging a unified policy?
A
Explanation:
The Unified Policy is a feature that allows you to create a single policy layer that combines the
functionality of Access Control, Threat Prevention, and HTTPS Inspection12
.
To debug the Unified
Policy, you need to use the command fw ctl debug with the module name UP and the flag all or
specific flags for different aspects of the Unified Policy inspection34
. The possible flags for the
Unified Policy module are:
up_match: Shows the matching process of the Unified Policy rules.
up_inspect: Shows the inspection process of the Unified Policy rules.
up_action: Shows the action process of the Unified Policy rules.
up_log: Shows the logging process of the Unified Policy rules.
up_tls: Shows the TLS inspection process of the Unified Policy rules.
up_clob: Shows the CLOB (Content Limitation and Optimization Blade) inspection process of the
Unified Policy rules.
up_rulebase: Shows the rulebase loading process of the Unified Policy rules.
up_connection: Shows the connection tracking process of the Unified Policy rules.
The flag tls is not a valid flag for the Unified Policy module, as it is used for the TLS Inspection
module5
. Therefore, the correct answer is A. tls.
The other options are valid flags for the Unified
Policy module, as explained above34
. Reference:
: CCTE Courseware, Module 8: Advanced Access Control, Slide 7
: Check Point R81 Security Gateway Architecture and Packet Flow, Chapter 5: Unified Policy, Page 29
: CCTE Courseware, Module 8: Advanced Access Control, Slide 17
: Check Point R81 Security Gateway Architecture and Packet Flow, Chapter 5: Unified Policy, Page 32
: Check Point R81 Security Gateway Architecture and Packet Flow, Chapter 6: TLS Inspection, Page
What is the simplest and most efficient way to check all dropped packets in real time?
C
Explanation:
The simplest and most efficient way to check all dropped packets in real time is C. fw ctl zdebug +
drop in expert mode. This command is a shortcut command that sets the kernel debug flags to a
predefined value and prints the debug output to the standard output. It is useful for general
debugging of common issues, such as traffic drops, NAT, VPN, or clustering. It has a small buffer size
and does not require additional steps to start or stop the debugging.
However, it has some
limitations, such as it cannot be used with SecureXL, it cannot filter the output by chain modules, and
it cannot save the output to a file12
.
The other commands are not as simple or efficient as the fw ctl zdebug + drop command. The
command tail -f $FWDIR/log/fw.log |grep drop in expert mode will only show the drops that are
logged in the fw.log file, which may not include all the drops that occur in the kernel. The command
cat /dev/fw1/log in expert mode will show the raw binary data of the kernel debug buffer, which is
not human-readable and may contain irrelevant information.
The command Smartlog will show the
drops that are indexed and stored in the SmartEvent database, which may not be in real time and
may depend on the log server performance12
.
1:
https://sc1.checkpoint.com/documents/R81.10/WebAdminGuides/EN/CP_R81.10_AdvancedTechnic
alReferenceGuide/html_frameset.htm 2
: https://www.checkpoint.com/downloads/training/DOC-
Training-Data-Sheet-CCTE-R81.10-V1.0.pdf
The Check Point R81.20 Gaia Administration Guide describes fw ctl zdebug as a key troubleshooting
tool for real-time packet analysis, particularly for drops. The CCTE R81.20 course emphasizes using
fw ctl zdebug for kernel-level debugging, including monitoring dropped packets.
For precise details, refer to:
Check Point R81.20 Gaia Administration Guide, section on “fw ctl zdebug” (available via Check Point
Support Center).
CCTE R81.20 Courseware, which covers advanced troubleshooting techniques for packet drops
(available through authorized training partners).
For Identity Awareness, what is the PDP process?
A
Explanation:
The PDP process is the Identity server, which is a component of the Identity Awareness blade on the
Security Gateway. The PDP process is responsible for collecting and managing identity information
from various sources, such as Active Directory, Identity Agents, Captive Portal, Terminal Servers, and
RADIUS.
The PDP process also communicates with the PEP process, which is the Policy Enforcement
Point, to enforce identity-based policies on the traffic passing through the Security Gateway1
.
The
other options, such as Log Sifter, Captive Portal Service, and UserAuth Database, are either not
related to Identity Awareness or not processes, but rather files or services. Reference: 1
: sk93046:
Identity Awareness - How to Configure
The two procedures available for debugging in the firewall kernel are
i. fw ctl zdebug
ii. fw ctl debug/kdebug
Choose the correct statement explaining the differences in the two
D
Explanation:
The correct statement explaining the differences between the two procedures for debugging in the
firewall kernel is D. (i) is used for general debugging, has a small buffer and is a quick way to set
kernel debug flags to get an output via command line whereas (ii) is useful when there is a need for
detailed debugging and requires additional steps to set the buffer and get an output via command
line.
The command fw ctl zdebug is a shortcut command that sets the kernel debug flags to a predefined
value and prints the debug output to the standard output. It is useful for general debugging of
common issues, such as traffic drops, NAT, VPN, or clustering. It has a small buffer size and does not
require additional steps to start or stop the debugging.
However, it has some limitations, such as it
cannot be used with SecureXL, it cannot filter the output by chain modules, and it cannot save the
output to a file12
.
The command fw ctl debug is a command that allows the administrator to set the kernel debug flags
to a custom value and specify the chain modules to debug. It is useful for detailed debugging of
specific issues, such as policy installation, CoreXL, or Identity Awareness. It has a larger buffer size
and can save the output to a file.
However, it requires additional steps to start and stop the
debugging, such as setting the buffer size, clearing the buffer, dumping the buffer, and resetting the
debug flags12
.
The command fw ctl kdebug is a command that is used in conjunction with fw ctl debug to dump the
kernel debug buffer to the standard output or to a file.
It is part of the procedure (ii) for detailed
debugging in the firewall kernel12
.
The other statements are not correct or relevant for explaining the differences between the two
procedures for debugging in the firewall kernel. The command fw ctl zdebug can be used to debug
more than just the access control policy, and the command fw ctl debug/kdebug can be used to
debug more than just the unified policy.
Both commands can be used on both the Security Gateway
and the Security Management Server, depending on the issue to be debugged12
.
Reference: Check Point Processes and Daemons3, (CCTE) - Check Point Software2
1:
https://sc1.checkpoint.com/documents/R81.10/WebAdminGuides/EN/CP_R81.10_AdvancedTechnic
alReferenceGuide/html_frameset.htm 2: https://www.checkpoint.com/downloads/training/DOC-
Training-Data-Sheet-CCTE-R81.10-V1.0.pdf 3
:
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails
=&solutionid=sk97638