- Products
- Learn
- Local User Groups
- Partners
- More
Introduction to Lakera:
Securing the AI Frontier!
Quantum Spark Management Unleashed!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
New VPN daemons were launched with R81.10. In the new version R81.20 you can see that these daemeons have been further revised.
Now iked runs as a multi-process and controls all IPsec VPN tunnels.
The other two processes, vpnd and cccd, each run only once on the gateway.
As far as I have understood correctly, the processes from R81.20 onwards are responsible for the following:
VPN Type | vpnd | iked |
Site-to-Site VPN | - | IPSec ESP |
- | IPSec NAT-T | |
- | Permanent tunnel | |
- | MEP | |
- | Link selection | |
Remote Access VPN | - | Endpoint - IPSec RA Client |
- | L2TP | |
CCC protocol | - | |
Visitor Mode | - |
For debugging, I noticed that the IKED daemon must now be debugged accordingly for example for iked0, iked1,...
Depending on the corresponding daemon (now shown in R81.20 with "vpn tu tlist -z") the debug must be set specifically for it.
If the daemon is now known, a special debug for this iked index id can be enabled:
# ike debug -i <iked index id> trunc ALL=5
This creates the corresponding debug files with the corresponding iked index id:
vpnd-ikev<iked index id>trace
So far I have understood everything.
Now my questions:
1) Where can I find Check Point documentation describing the new R81.20 VPN architecture?
2) How can I enable a VPN debug and how can I evaluate the multi R81.20 iked daemons? Are there any sk's or a documentation here.
3) Is there a design overview of how vpnd, iked and cccd work together?
I've seen some internal documentation on the new architecture, but don't think it's public yet.
I assume you can enable debug on multiple iked at the same time using the process you mentioned.
If I understand correctly:
iked and cccd were added in R81.10
iked became multi-threaded in R81.20.
Prior to R81.10, all three functions were included in vpnd.
Since R81.10, the new VPN is voodoo magic for me.
I'm looking for documentation (SK's, what's new infos, debug infos,...) on how to debug this and how the new daemons work on R81.10 / R81.20.
On a 4 core LAB system with 3 CoreXL instances I see that only two iked daemons are started but three vpnd Dameon are started
I would also have expected three iked daemons here.
Do you have any technical documentation on how the new VPN design works?
From what I see, iked is for IKE negotiations related to IPsec RAS VPN, IKE with DIAP and Large Scale VPN. The regular S2S are handled by vpnd, still.
See skI4326 and VPN admin guides for more details.
Also, both daemons are mentioned in the R81.10/20 VPN admin guides, for example:
The CCC daemon cccd
(introduced in R81.10).
Responsible for the Circuit Cross-Connect (CCC) protocol, while:
IKE for the same clients runs in the IKE daemon iked
CCC TLS for the same clients runs in the VPN daemon vpnd
Listens on these ports on a Security Gateway:
TCPT: 444 (TCP)
Session infrastructure manager: 9993 (TCP)
The IKE daemon iked
(introduced in R81.10).
Handles these VPN connections:
All connections from IKE Remote Access clients clients (for example, Endpoint clients)
Site-to-Site connections from peer Security Gateways with a Dynamically Assigned IP address (DAIP)
Large Scale VPN (LSV) connections
Connections from SmartLSM ROBO gateways
Listens on these ports on a Security Gateway:
IKE: 30500 (UDP)
IKE NAT-T: 34500 (UDP)
Session infrastructure manager: 9994 (TCP)
L2TP: 1701 (UDP)
THX for this info.
"iked" magic goes on for me, though.
When I look at the system with htop, 6 iked processes are started on a 3 CoreXL system.
I would like to understand the new vpn technology in depth so that we can better help our customers in case of issue.
Is it planned that there will be more information here in the future.
If this information exists, where can I find it (SK's, ....)?
sk173903 - "Resilient VPN architecture - multi-process architecture to handle IKE negotiations in dedicated scalable daemons, providing unprecedented resiliency"
Site to Site VPN R81.20 Administration Guide
------------------------------------------------------------------------------------------
Number of IKED instances = 3 CoreXL / 2 instances per daemon = 1.5
===
-------------------------------------------------------------------------------------------
When I do the math, the formula for me looks like this:
Number of IKED instances = (Number of CoreXL Firewall Instances) * (Value of Kernel Parameter 'ike_num_instances_per_daemon')
There should be a "*" sign and not a "/" sign.
Number of IKED instances = 3 CoreXL * 2 instances per daemon = 6
===
-------------------------------------------------------------------------------------------
That's my problem. I don't understand the technology behind it.
Why two instances per daemon? This is not described in the Admin Guide.
I would like more information from Check Point here.
With R81.10 and R81.20, you can see that a new development has taken place here. We had some VPN problems with the new release in the last months. We had open many VPN tickets at the support. But with newer R81.10 Jumbo HF versions it has gotten better.
Is there any news on my question from Check Point.
Do you have deep dive information on the VPN daemons and VPN debug.
You've pretty much uncovered most of what has been communicated to TAC about how to debug the new vpnd/iked.
The traditional debug command of vpn debug trunc ALL=5 should debug all the iked processes at once, it will just generate more files 🙂
Having said that, on a busy gateway, you might want to debug a specific instance of it, particularly if the issue is with a specific peer (since a given instance of iked is used for a specific VPN peer).
FYI, we've released a new SK on this topic: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...
This is meant to replace several SKs on debugging VPN and includes information necessary for debugging VPNs in R81.20.
Excellent sk, thanks for sharing!
Very nice! THX
Attention, quoting from Important security update - stay protected against VPN Information Disclosure (CVE-2024-24919)
In R81.10 we added a feature to improve VPN performance - named CCCD
This feature is disabled by default, and we know about few advanced customers who are using it.
Customers who enable CCCD are still vulnerable to CVE-2024-24919 even after installing the Hotfix!
YOU MUST DISABLE CCCD TO BECOME PROTECTED!
Instructions below and also on SK182336:
Run the command: vpn cccd status
The expected output is: vpn: 'cccd' is disabled
.
If the output differs, stop the CCCD
process by running the vpn cccd disable
command.
More info by the link above.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
11 | |
9 | |
8 | |
7 | |
6 | |
6 | |
6 | |
5 | |
5 | |
5 |
Tue 23 Sep 2025 @ 06:00 PM (IDT)
Under the Hood: CloudGuard Network Security for Nutanix - Overview, Onboarding, and Best PracticesWed 24 Sep 2025 @ 03:00 PM (CEST)
Bereit für NIS2: Strategische Werkzeuge für Ihre Compliance-Reise 2025Wed 24 Sep 2025 @ 03:00 PM (CEST)
Bereit für NIS2: Strategische Werkzeuge für Ihre Compliance-Reise 2025Thu 25 Sep 2025 @ 03:00 PM (IDT)
NIS2 Compliance in 2025: Tactical Tools to Assess, Secure, and ComplyThu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY