Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
14KME
Participant
Jump to solution

R81 on Openserver

Hello,

I've added my questions to topic "R81 is now available (Questions and Answers)" already, but didnt get a response until now.

Maybe is a better way to use a new post. So here is what I'm looking for:

We are interested in using R81 on Openserver (Gaia). As fare as I see, this is released already.
Is anyone using it in this combination? (question 1)

sk166715 does not show R81 as "widely recommended for all deployments" - how it is for R80.40 (in sk111841). Can anyone give a date for the expected official "recommendation for all deployments"? (q2)

We are using R80.10 in a cluster now. What's your suggestion for a replacement of the Openservers (appliance is not an option)?
[variant-1] Using R81 for Console and Management with GWs on R80.40
or
[v2] Using Console, Management and GWs on R80.40
or
[v3] Using Console, Management and GWs on R81 (update the source system to 80.20 before)
or
[v4]<your input is welcome>
As fare as these combinations are supported. (q3)

0 Kudos
2 Solutions

Accepted Solutions
G_W_Albrecht
Legend Legend
Legend

I would suggest R80.40 / R80.40 if no R81 features are crucial and the version has to be supported and recommended 😎

CCSP - CCSE / CCTE / CTPS / CCME / CCSM Elite / SMB Specialist

View solution in original post

0 Kudos
Wolfgang
Authority
Authority

@14KME the faster policy installation works only with R81 on the gateways and on the management.

R81 is really new (only a few days out) , as @G_W_Albrecht suggests R80.40 is stable and recommended. I would never use such a new version in production if stability is your main goal.

Wolfgang

View solution in original post

11 Replies
shlomip
Employee Alumnus
Employee Alumnus

Hi,

At least for Question #2, moving a version to recommended is done after significant amount of Its Jumbo installations

and additional KPI's. We are now working on releasing R81 first jumbo.

this process (moving to recommended) usually takes few months, so a rough estimation for moving R81 to recommended is early 2021

You can see more information in sk95746 

0 Kudos
PhoneBoy
Admin
Admin

Which choice you make will depend entirely on your motivations for upgrading beyond being on a supported version.
If you need the features in R81, upgrade.
If you’re more conservative, R80.40 is a great choice.
R81 gateways do require R81 management.

14KME
Participant

My main motivations are to get an environment which is stable and a possibility of faster activation (Installation/Apply) for Rules.

It's annoying to spend a lot of time and hold the phone call while waiting for the installation of the policy (even only 'Access Control' has to be applied takes 5-8minutes; the other side with another firewall-vendor applied those in seconds e.g. setup of S2S-VPN).

Coming back to my future R81 (or even lower) environment on Openservers for the Gateways and with a VM for the Management:

So do your/the explanation indicate, it is actually the best combination of highest STABLE versions (and supported) to start with R81 for the Management and use R80.40 for the Gateways?

Only a supported version or a combination of supported versions will be used in our production environment.

0 Kudos
G_W_Albrecht
Legend Legend
Legend

I would suggest R80.40 / R80.40 if no R81 features are crucial and the version has to be supported and recommended 😎

CCSP - CCSE / CCTE / CTPS / CCME / CCSM Elite / SMB Specialist
0 Kudos
14KME
Participant

Thank you for your suggestion.

But why no R81 for Management?

Is 80.40 for Management faster in "Installing Policies" as 80.10 (or is this only in R81 better solved)?

0 Kudos
Wolfgang
Authority
Authority

@14KME the faster policy installation works only with R81 on the gateways and on the management.

R81 is really new (only a few days out) , as @G_W_Albrecht suggests R80.40 is stable and recommended. I would never use such a new version in production if stability is your main goal.

Wolfgang

Daniel_Kavan
Advisor

We are putting out new hardware Q1 2021, so it would be a great time to make a major version change to R81.  But if I go with R80.40 now, I'll be able to upgrade to R81 once R81 is the default and recommended version.   How long does it usually take for a major version like R81 to go from GA -> recommended?   I know it varies, but maybe 6 months like May/June 2021 wouldn't you say? The line drops down in sk152052 around that time.   In the mean time I, need to upgrade R80.30->R80.40 on the management side.   R80.30 manages R80.40 and R80.10 gw fine, but I heard of some issues with R80.40 managing R80.10 gws recently.  My current plan is to get all my gws off 80.10, then move the manager to R80.40.   And even later to R81.

 

0 Kudos
Tomer_Noy
Employee
Employee

R81 is a great version and we've gotten really good feedback so far.

Indeed R81 is not yet widely recommended (or the "default choice" as we sometimes call it). The general guidance is that if you need a specific feature from R81, and you are not very conservative, then you should go ahead and choose R81. On the other hand, if you have everything you need in R80.40, then you can choose that as a very good option for most customers.

It sounds like you are looking for the accelerated policy installation, which is only available in R81. You will need both R81 management and R81 gateway to enjoy the feature in full. That said, R81 also brought some policy installation performance improvements that are only on the management side, so even when the gateway is R80.40, it should still be a bit faster. Also, if you have multiple policies, R81 brought the option to install policy in parallel, without waiting for one to finish before starting the next one.

Good luck with your choice, and if you do choose R81, please make sure to share your feedback!

Daniel_Kavan
Advisor

Ok, I'm going to give it a try on R81.  My current manager is running on R80.30.  I built a new manager with R81.   Now, I'm going to run the migrate_server export with the upgrade tool on the R80.30 manager.  Update:  Interesting my migrate_server export was only 252 MB vs my normal migrate export of almost 2 GB.    I'm importing to R81 now to see if everything is there.  😁  Also, interesting that the migrate_server binary was already there in $MDS_FWDIR/scripts on the older R80.30 manager.  It didn't bring my license in.  The license on the SMS has expired.  Add a new license and try agian.  Meanwhile, my trial license isn't even one day old.... Hmm.   I assumed the -v version was supposed to be R81 in both the export and import, when I was exporting from R80.30.  In any event the export and import were successful with R81, I just can't log in with out a better license.

0 Kudos
Tomer_Noy
Employee
Employee

Starting from R80.20, we made some significant improvements to the upgrade mechanism, which you see in your upgrade flow.

  1. The way we export the data is more efficient, which explains why the size is 252 MB instead of 2 GB
  2. Upgrade tools are already on the source machine, and they have an automatic update process. That means that you don't need to manually bring in the tools when you upgrade to a new version. It also means that if we fix bugs in the export process (after the release), they will be automatically fixed on your machine when you start the upgrade.
  3. There is also the upgrade report in that you can use to follow up on the progress

Regarding the license, is it possible that the new machine has a different IP?
That might explain why the license wasn't carried over.

0 Kudos
Daniel_Kavan
Advisor

Management side:  The license is working today.  I'm not sure why it didn't work yesterday.  I was able to log in fine today, no license error.   Very nice.  

Gateway side: I built the gw in legacy boot mode, (HP DL 360 gen 10) now  rebuilding again in UEFI mode.  The iso is not picking up with UEFI, any one else have this issue?  I'm going to try R80.40 with UEFI, the R80.40 iso wouldn't boot up with UEFI either.  Confirmed!   CP doesn't support UEFI because of security reasons, sk154833 & sk114174.

Smart Event & Logging Server: Smart event settings/configurations ie blocking scans are imported after the new smart event server is built.  migrate_server export / import did the trick.

Q1: Does anyone know why I have docker0 interface of 172.17.0.1 on my manager and Smart Event VM?   Is that part of R81, Check Point, or my own enviroment?

Behavior R81:  I'm not seeing any changes made since last policy when pushing policy, even though I just made a change.?.?  Update: After pushing policy the initial time, new changes were seen.  Also, needed sk169714 for pushing TP the first time.

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events