- Products
- Learn
- Local User Groups
- Partners
- More
Quantum Spark Management Unleashed!
Introducing Check Point Quantum Spark 2500:
Smarter Security, Faster Connectivity, and Simpler MSP Management!
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!
Hey guys,
Have a perspective customer, currently with Fortinet and they are super impressed with R82 release, but wanted to know when it might become recommended version? I told them my educated guess would be probably some time in summer 2025, but maybe someone else may have better info? 🙂
Tx as always!
Andy
Before the end of H1 I would think, I believe aligned to the third Jumbo or so (subject to change).
The requirement for R82.10 for the 3900 series is due to their ARM processors, which are not supported by the Linux kernel until 5.14 (RHEL 9.x), which is the new kernel version employed by R82.10. R82 uses Linux kernel 4.18. All this will be covered in my upcoming Gaia 4.18 Immersion self-guided video training series, which I'm currently completing.
The announcement has been made:
Before the end of H1 I would think, I believe aligned to the third Jumbo or so (subject to change).
Appreciate it Chris, Im sure they will be happy about that 🙂
Andy
We heard June, July, and the latest is September. There are new appliances which require R82 - which is not the recommended version (I appreciate that it IS fully supported). We've got multiple customers with hardware going end of support and were hoping to deploy R82, but now might just do that for management with R81.20 on gateways and a later blink upgrade.
Im also very surprised its not recommended yet.
Andy
My educated guess is that it should be OK for management, after all it runs in Smart-1 Cloud without noticeable issues, while gateways remain in R81.20. At least it would allow to run the newest 3900 series our customers are already asking without being too greedy on the production systems.
Our policy however is to stick with the recommended releases unless there is an absolutely compelling reason (the 3900), and with all those replacements happening right now going straight to ElasticXL would have been nice.
100% is fine for any management server, in my opinion. I had people upgrade even on prem servers, no issues. But for gateways, I would not do it until it is officially recommended by CP.
Andy
We upgraded our on-premises management this week so we could manage the new 3920s, no issues so far. The log view seems "better", they adjusted scale or font or something, it's different, but in a good way. I also enjoy being able to see the version and JHF on the Gateways & Servers tab.
I love that feature as well.
Andy
So far, super solid.
Andy
How can you manage 3920 appliance if according to the Check Point appliance support, the only supported version for 3920, 3950, 3970 and 3980 is R82.10, which is even not officially released as GA ?
If I purchase 3920, will be FCD the version which doesnt exist yet as R82.10 is currently only in EA stage ?!
R82 jumbo 19 (and SmartConsole R82 build 1053) added the ability to manage R82.10 on the 3900 series. PRJ-61143
Good stuff.
The requirement for R82.10 for the 3900 series is due to their ARM processors, which are not supported by the Linux kernel until 5.14 (RHEL 9.x), which is the new kernel version employed by R82.10. R82 uses Linux kernel 4.18. All this will be covered in my upcoming Gaia 4.18 Immersion self-guided video training series, which I'm currently completing.
Good to know!
I've not used R82 in production yet, but in my lab using ElasticXL and VSNext with JHFA19 it seems riddled with issues. So unless someone has any real production implementation experience of R82 ElasticXL / VSNext, then I'm doubtful this is ready for production, happy to be corrected, but my comments are based purely from my lab experience, and TAC cases I've raised, all related to relatively foundational stuff.
I think R82 need to get to JHFA80 or higher before it gets to recommended state, so in my option Checkpoint would be better off considering recommended state next year so the customer experience would be better as a whole.
VSNext has still dozens of limitations as per sk79700. The biggest decision maker is lack of IPv6 support.
I feel lack of ipv6 support is universal, regardless what fw you use : - )
Andy
Hey,
VSNext does support IPv6 — the SK was incorrect and has now been updated accordingly.
Best regards,
Matan
You mean NAT64?
Because IPv6 is definitely supported
Or did you mean something else entirely?
The article was just updated 2 days ago and IPv6 is now claimed as supported.
I use R82 standalone in the lab, no issues, but of course, cant be compared to production. Would be interesting to see if anyone is using R82 elasticxl in production yet. One of my colleagues is deploying it for the customer this month, so lets see how it goes.
Andy
I have HA ElasticXL with VSNext in my proxmox lab and to me, with these specific technologies, if you deployed it in production I suspect the client experience, and stability would not be great; Its also logical that frequent jumbo's are coming and some clients don't like frequent patching.
It would definitely be good to get other experiences on these technologies shared here, as I do think R82 has a number of good features.
Agreed. Like any new version, takes time.
Andy
Another observation that Checkpoint may want to consider changing, the EoS for R82 is 2028, I think it would be better to change this to 2030. I suspect the take up of R82 will increase more next year, so that really only leaves two years before another upgrade is required (excluding Jumbos of course). Clients would prefer a longer period without being forced to upgrade/rebuild.
We know R82.10 (kernel version 5.14) is coming and perhaps this should be seen as a 'Early Deployment' release that goes mature in 2030 and then EoS in 2035 or 2036?
I know that R82.10 that is currently in EA is based on RHEL 9.
However, if I recall correctly, the R82.10 that ships on the 3900s actually uses a 4.18 kernel.
It is 5.14.
That makes sense...just checked my lab and shows below.
Andy
[Expert@R82:0]# uname -a
Linux R82 4.18.0-372.9.1cpx86_64 #1 SMP Thu Jun 5 17:40:21 IDT 2025 x86_64 x86_64 x86_64 GNU/Linux
[Expert@R82:0]#
JHFA34 released guys.
Yep...yesterday.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
10 | |
7 | |
7 | |
6 | |
6 | |
5 | |
5 | |
5 | |
5 | |
5 |
Wed 10 Sep 2025 @ 11:00 AM (CEST)
Effortless Web Application & API Security with AI-Powered WAF, an intro to CloudGuard WAFWed 10 Sep 2025 @ 11:00 AM (EDT)
Quantum Spark Management Unleashed: Hands-On TechTalk for MSPs Managing SMB NetworksFri 12 Sep 2025 @ 10:00 AM (CEST)
CheckMates Live Netherlands - Sessie 38: Harmony Email & CollaborationWed 10 Sep 2025 @ 11:00 AM (EDT)
Quantum Spark Management Unleashed: Hands-On TechTalk for MSPs Managing SMB NetworksFri 12 Sep 2025 @ 10:00 AM (CEST)
CheckMates Live Netherlands - Sessie 38: Harmony Email & CollaborationAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY