- CheckMates
- :
- Products
- :
- General Topics
- :
- Re: New VPN daemons in R81.20
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
New VPN daemons in R81.10 / R81.20
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
- vpnd handles most VPN functions
- iked handles IKE Negotiations
- cccd handles Endpoint Compliance functions
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
THX for this info.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
"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, ....)?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
sk173903 - "Resilient VPN architecture - multi-process architecture to handle IKE negotiations in dedicated scalable daemons, providing unprecedented resiliency"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is there any news on my question from Check Point.
Do you have deep dive information on the VPN daemons and VPN debug.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Excellent sk, thanks for sharing!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Very nice! THX
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.