Can an SMS running R81.20 Take 53 manage a Security Gateway cluster running R81.20 JHF 118?

[Joe_Kanaszka]

Hey guys.  I'm pretty sure the answer to my above question is yes, but I want to make sure just in case I can't upgrade my SMS and SmartEvent server before my migration.  After my migration, my new 9100 security gateways will be running R81.120 JHF 118.

In case I have time to upgrade my SMS and Smart Event:

Can an SMS running R81.20 Take 119 manage a security gateway cluster running JHF 118?

According to this matrix, It looks OK

https://support.checkpoint.com/results/sk/sk113113 - Management Servers and Security Gateways they can manage:

The Matrix does not mention any hot fixes for SMS and security gateways both running R81.20

So my takeaway is that as long as the SMS and Security Gateways are all running R81.20, the patch levels between the two have no impact on if an SMS can manage a security gateway.  Am I correct? 

[Bob_Zimmerman · Accepted solution]

Yes. Jumbos are independent. A management server running any jumbo can manage firewalls running any jumbo on the same major version or several earlier versions.

Some jumbos add the ability to manage newer versions, for example, to let an R81.10 management manage R81.20 firewalls.

That said, the management server has no relevance to traffic, so it's usually MUCH easier to get a window to update it than it is to get a window to update a firewall. It's pretty rare for a management server to run a jumbo much lower than the firewalls.

[Joe_Kanaszka]

Thanks Bob!  So I can really update the SMS anytime.  Perhaps shut is down, take a VMware snapshot, then upgrade to 119.  The only issue would be that I obviously cannot push policy until the SMS is back up.   

I've always thought that the hotfix on the SMS should be equal to or greater than the Security Gateways.  Thank you for this info! 

[Wolfgang]

@Joe_Kanaszka I believe you have to update your SMS running R81.20 to Jumbo take 65, following Quantum Force 9000 Appliances 

Normally as mentioned by @Bob_Zimmerman your SMS can run a different Jumbo version. But sometimes you need one to manage newly released hardware. If you can choose 9000 appliance as hardware type in a firewall object in Smartconsole you should be fine with your SMS.

[Joe_Kanaszka]

Thank you Wolfgang!

[Bob_Zimmerman]

65 is actually the minimum supported on the firewall itself. Jumbo 54 and SmartConsole build 653 added the 9000 series to the "Hardware" picker inside the firewall object, but I've never seen that actually affect how the policy works.

Really, though, the management should be the most current simply because updating it is much less risky than updating the firewalls. All you can lose is the ability to make changes or see your logs for a few hours. Zero chance of traffic impact. I've done all of my management updates and upgrades in the middle of the business day for years because that's the ideal time for it.

[Joe_Kanaszka]

Makes sense - thanks again Bob!  Do you need to install policy after the SMS and / or Smart Event appliance updates?

[Bob_Zimmerman]

You don't technically need to, but pushes should be frequent anyway, otherwise you risk accumulating latent issues. That is, if you only push a given firewall's policy once per quarter, and you have a problem after a push, you have three months of changes to look through.

In my environment, we push every single policy almost every single weekday. Most are pushed M-F, some (from mergers) are only M-R. That way, if something breaks, we only need to review a few sessions to see what it could be.

The rest of this isn't directly related to updating the management server.

I find the best way to prevent outages is to test stuff as frequently as I realistically can. We do all updates and most upgrades with CDT, which has an automatic failover. We update everything at least twice per year, so every cluster gets at least two failovers per year to make sure both members actually work.

You may want to check out my cluster config diff tool. It runs on a management server, finds all the clusters which report to it, dumps their clish configurations, and checks for differences. This helps spot things which could be an issue (like a route on one member which was forgotten on the other member) before you fail over.

[Joe_Kanaszka]

Yea - same here.  If I make any changes, I just don't publish and not install the policy - that would be a nightmare having to guess which change caused the issue!  At least if you install the policy after every change, you have a pretty good idea of what caused any issues.  I'll have a look at the CDT - sounds pretty cool!   Thank you again!

[the_rock · Accepted solution]

Hey brother,

Technically, you could even have SMS R81.20 jumbo 24 (for example) and gateways R81.20 jumbo 120 and all will work fine, there wont be any issues. As the guys said, jumbo fixes are totally independent in this case. I know most clients prefer to have everything on the same jumbo take, mind you, truth be told, 9 times out of 10, the fixes are related to the firewall. To be safe, its always best to check an official documentation page for fixes included.

https://sc1.checkpoint.com/documents/Jumbo_HFA/R81.20/R81.20/R81.20-List-of-all-Resolved-Issues.htm?...

Hope that helps.

[Joe_Kanaszka]

Thanks Andy!

[the_rock]

Of course, always happy to help you.

[Joe_Kanaszka]

Afternoon Andy!  Regarding my above question - do you typically have to install policy or install database when you update an SMS with a recent Fix?

[the_rock]

technically not, as you are not making any changes, but, I always do, just to make sure all still works.

[Joe_Kanaszka]

OK cool.  As Bob said above - as long as there is zero chance of a traffic disruption I'm cool with this.  I'm paranoid!  🙂

[the_rock]

All we can do is be careful, brother, thats it. But, I always try not to be too careful, then something opposite may happen lol. Anyway, better be safe than sorry!

[the_rock]

@Joe_Kanaszka 

Just for the context, here is a short list of things/commands I like to do when any jumbo is installed:

on mgmt:

ssh -> cpinfo -yfw1

df -h

nslookup 8.8.8.8 ir curl_cli -k google.com

gateways:

fw stat after policy is installed

also curl_cli -k and/or nslookup

ip r g 8.8.8.8

this is also good thing to run, just to make sure all looks normal(from my lab)

[Expert@CP-GW:0]# tracepath 8.8.8.8
1?: [LOCALHOST] pmtu 1500
1: 172.16.10.1 (172.16.10.1) 2.827ms
2: 192.168.0.4 (192.168.0.4) 3.828ms
3: unassigned-209.3.46.173.net.blink.ca (173.46.3.209) 2.062ms
4: unallocated-static.rogers.com (72.142.86.37) 2.386ms
5: 209.148.225.133 (209.148.225.133) 4.695ms
6: 209.148.225.105 (209.148.225.105) 4.099ms
7: 24.156.145.98 (24.156.145.98) 8.884ms
8: 9044-cgw01.mtnk.asr9k.rmgt.net.rogers.com (209.148.230.53) 5.905ms
9: 69.63.248.69 (69.63.248.69) 8.562ms
10: 72.14.216.54 (72.14.216.54) 6.480ms
11: 192.178.99.35 (192.178.99.35) asymm 12 5.943ms
12: 216.239.41.175 (216.239.41.175) asymm 13 8.071ms
13: dns.google (8.8.8.8) asymm 15 7.397ms reached
Resume: pmtu 1500 hops 13 back 15
[Expert@CP-GW:0]#

Hope that helps!