- Products
- Learn
- Local User Groups
- Partners
- More
Firewall Uptime, Reimagined
How AIOps Simplifies Operations and Prevents Outages
Introduction to Lakera:
Securing the AI Frontier!
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!
I am planning to upgrade the firewall manager from r81.10 to r81.20.
Cpuse doesn't list r81.20 though. I can see different r81.10 hot fixes but I can see any r81.20 package. Why would it happen?
I have another firewall manager vm in the lab running r81.10 and I can see the list of r81.20 packages in cpuse.
Again, a secondary management only becomes active if you log in to it with SmartConsole and explicitly tell it "The primary is dead. Become active." It's a four or five step process. As long as you don't do that, it will remain standby, and it will keep the data it had when it was last synchronized. Just don't go out of your way to intentionally tell both managements to become active, and this won't be a problem.
To ad on top of what @Bob_Zimmerman said, because I see still so many people get confused about it, so I will stress this out, in case its not clear.
-primary server will ALWAYS be primary
-secondary will ALWAYS be secondary (unless rebuilt)
-either one can be active or standby, so primary can be either active or standby and secondary can be either active OR standby
Andy
It makes sense to make the secondary active before starting the process of upgrading the primary.
And it also makes sense to make the primary active after the upgrade for testing.
So it makes sense that management HA behaves like clusterXL in that sense (like Andy mentioned) to enforce that only one of them can be active at a given time.
You got it.
That doesn't make sense at all, no. A management upgrade only takes a few hours. Making the secondary active in that window is asking for trouble. Unless you have a really good reason (like if the upgrade fails and you decide to roll back), you absolutely should not make a secondary management active while upgrading the primary.
What goal are you trying to accomplish by making the secondary management active before you start upgrading the primary?
Well, it can work sort of like clusterxl upgrade. If you leave status as is, its fine, but I know people who flip back and forth during the upgrade, thats fine too. I had done mgmt HA and clusterXL upgrades both ways, never had a problem.
Andy
I think it make sense to get secondary active a few days before running the firewall manager upgrade. It is just good practice in general, you isolate the device were you are making changes and you test than the secondary is good.
However that is why I am asking here. If management HA doesn't handle well two managers running two major version and this operation is considered risky I will for sure make sure than the secondary is not active when I perform this change.
Assuming the primary is currently active, the secondary will not go active unless you log into it and make it active - don't do this unless you have to roll back.
Take an export of the primary using the migrate_server command per the upgrade guide.
(optional) Test the import of this file in fresh R81.20 VM
Rebuild the primary to a fresh install of R81.20
Install recommended JHF onto primary
Import DB into primary
Make sure it all works (SIC is good, policies install, you get logs, all that), for however long you want. HA will fail so nothing you change will sync to secondary. The secondary won't be affected by this failing so you don't have to do anything about it.
Then if it's all good, fresh install the secondary, install same JHF and re-SIC it to primary.
That sounds accurate to me.
The Problem with this update are the traffic logs.
How attached are you to these?
Regards
Peter
Not an issue, we export logs to ELK.
Thanks to everyone. I successfully upgraded both firewall managers to r81.20. Only facing a couple of small issues in r81.20 related with scheduled backup and pki authentication and summary revision changes (this last issue only in the secondary firewall manager)
But otherwise is okay?
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
28 | |
16 | |
4 | |
4 | |
3 | |
3 | |
3 | |
3 | |
3 | |
2 |
Tue 07 Oct 2025 @ 10:00 AM (CEST)
Cloud Architect Series: AI-Powered API Security with CloudGuard WAFThu 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!Thu 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!Wed 22 Oct 2025 @ 11:00 AM (EDT)
Firewall Uptime, Reimagined: How AIOps Simplifies Operations and Prevents OutagesAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY