- CheckMates
- :
- Products
- :
- General Topics
- :
- Re: Do I need to install policy after each HOTFIX ...
- 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
Do I need to install policy after each HOTFIX upgrade?
I have a query that do I need to install policy after each upgrade? And if yes then both cluster members or the Firewall which is upgraded/not upgraded selected for policy push? I am not sure if HotFix upgrade requires policy install step. I have MDS managing all the firewalls.
Earlier when I did policy install step it was when OS was upgraded R77 to 81. I have change the version name from r77 to r81 in Gateway Cluster Properties-->General Properties-->Platform--->Version and then push the policy.
I followed these steps while upgrading from R77.30 to R81 take 392:
Start with Passive Firewall(ideally)
Install latest/recommended Deployment Agent(DA) if installation is not automatically enabled on the firewalls
Upload/Copy of IOS Image on the concerned firewall
Verify IOS Image - Check_Point_R81_T392
After successful verification - Upgrade FW with IOS image
Upload Hot Fix - Check_Point_R81_JUMBO_HF_MAIN_Bundle_T77
Verify uploaded Hot Fix_Bundle_T77
After successful verification, Install Hot Fix
Change Name to R81 on MDS
Policy Push for version R81 after First Firewall IOS & HF upgrade
Revert to Clish Mode in the both Firewalls CLI
Repeat same steps for Active Firewalls
Policy Push for version R81 after First Firewall IOS & HF upgrade
Make sure Primary Firewall is now active
Thanks!
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Installing policy is required on version upgrades because the policy compilation is different for each version.
This is not the case for hotfix installations.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Installing policy is required on version upgrades because the policy compilation is different for each version.
This is not the case for hotfix installations.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Note that this is about the policy push in the middle of a major or minor version upgrade (when you have only upgraded one member). That's definitely not needed for jumbos.
You should push policy at the end, once both members are updated.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Prerequisites
To use Central Deployment:
-
A policy must be installed on the target Security Gateways and Cluster Members.
Would recommended to the same if you for example Jumbo update the server that manages the gateways. Maybe during the versions something changed regarding policy push so you want to push policy.
For normal Jumbo updates via CLISH or CPUSE I would also do it just to be sure but it is not needed. Jumbo update can finish and just run fine without push. But in my opinion it is also a form of a health check after jumbo.
If you like this post please give a thumbs up(kudo)! 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I would say 100% you dont need to, because gateways will fetch last known policy from the mgmt server. The only time I had seen happen otherwise is when you do major upgrade, say from R80.40 to R81.20, where after reboot, it loads initial policy, so you need to unload it and install real one from mgmt server. In one instance, I even had customer tell me it loaded whats called "default filter", which literaally block everything and you need to console in, run fw unloadloca, but thats super RARE.
Either way, I always advise people to have physical access, just to be on the safe side.
Hope that helps.
Best,
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
For the context and I hope @PhoneBoy will correct me if Im mistaken, but I believe this is how it works with policy:
1) FW will always get policy from the mgmt first
2) If 1 fails, then it will try fetch locally stored one in $FWDIR/state/_tmp/FW1
3) If 1 and 2 fail, then it would load initial policy, which allows ssh AND web UI, but ONLY on port 443
4) if all fails, then most likely default filter will be applied, which block everything, including ssh and web UI
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I believe this is still how it works after all these years 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I figured, but have to confirm from the BEST! 🙂
