Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Maarten_Sjouw
Champion
Champion

Maestro basic setup documentation

Hey guys,

I've been playing around with some Maestro units and a number of gateways. I have been running into a number of problems that caused me to document all the actions that I needed to do for a specific type of installation, the document is about 3 different scenario's:

  1. Single site dual Maestro
  2. Dual site single Maestro
  3. Dual Site dual Maestro

Please check out the document and let me know what you think about it, also if you see things that you don't understand or know that should be different, please let me know.

 

Updated the document to v1.0, 16 dec 2019.

Updated the document to v1.2, 26 Feb. 2020. Added bonding.

Updated the document to v1.3, 03 Mar. 2020. updated some parts and added commands.

Updated the document to v1.5, 17 Mar. 2020. updated some parts and added commands after training.

Updated the document to v1.6, 25 May 2020. Update regarding HA licenses

Regards, Maarten
91 Replies
Maarten_Sjouw
Champion
Champion

Added the bonding parts for Dual MHO on a single and dual site setup.
I'm still looking at the way to configure dual site.
Regards, Maarten
Maarten_Sjouw
Champion
Champion

After following the Maestro training I have walked through and updated the guide in several places. Also added parts for configuring VSLS, which is not to be found in any official R80.20SP documentation yet.
Regards, Maarten
0 Kudos
Reply
MikeB
Advisor

Hi Maarten,
Thank you for all the value information. I wonder if it's supported the deployment with 3 MHO (2 in site A and just 1 in site B)
0 Kudos
Reply
Lari_Luoma
Employee
Employee

No. We only support 1 or 2 orchestrator setups. In dual site setup both both sites should have the same number of orchestrators.

0 Kudos
Reply
MikeB
Advisor

Thank you for your quick response Lari.
Regarding the Security Gateways in each side also should have the same number? or can be deployed 2 GW connected to 1 MHO in site A and just 1 GW connected to 1MHO in site B?
0 Kudos
Reply
Lari_Luoma
Employee
Employee

Yes, you should have the same number of appliances on both sites.

0 Kudos
Reply
Anatoly
Employee
Employee

Not mandatory, but better to have the same amount

Maarten_Sjouw
Champion
Champion

A small update, in the document there was a reference about HA licenses. When you have a cluster of appliances and one of them has a HA license on it, this is NOT supported on a Maestro configuration, so make sure to upgrade the box to a full license.
Regards, Maarten
Northy
Contributor

Hi Maarten, Do you have an official source for the HA license not being supported.

We are looking at migrating our VSX cluster into Maestro, 1 of our appliances has a blade for 25 VS's but its listed as "CPSB-VS-25-VSLS" the description says for HA/VSLS.

Will this mean we need to get a new blade license?
0 Kudos
Reply
Maarten_Sjouw
Champion
Champion

My source for this was the local Sales support team and Israel.
The only way to get this working is by asking sales for a quote to upgrade your VSX license as part of the purchase of the Maestro setup.
Normally this would be 20% of the normal license listprice.
Regards, Maarten
0 Kudos
Reply
mk1
Contributor

Hello all,

I've got question about link aggregation of management interfaces.

We have only one MHO140 and we're about to configure only one SG on it. I'm planning to configure LACP (magg) between ports 1 and 2. I will assign those ports to the SG, and after that configure LACP within. As far as I understood management ports can be shared between SGs. How to proceed if we decide to add new SG after some time? Do I have just to add ports 1 and 2 to the new SG, and create again LACP (magg) inside it?

Thank you!

0 Kudos
Reply
Norbert_Bohusch
Advisor

Hi mk1,

no, you can't share any physical ports between SGs. This includes the management interfaces.
So you would need to use port 3+4 for the second SG then to allow magg there.
Maarten_Sjouw
Champion
Champion

You can assign the same ports for management to multiple SG's, I would not assign more than 1 port to management, unless you are really afraid 1 of your switches will fail.
But the issue with using 2 ports and magg bonding them is indeed a good question that I think @Anatoly should be able to answer.
Regards, Maarten
Lari_Luoma
Employee
Employee

Physical management ports can be shared between the security groups. It is Check Point's best practice to create a MAGG interface (management aggregation) if you have two orchestrators per site.

MHO-140 has four physical management ports to manage security groups. If you have multiple security groups and available switch ports my recommendation is to use to configure separate magg using dedicated management ports for each SG. 

SG1: Eth1-Mgmt1 + Eth2-Mgmt1

SG2: Eth1-Mgmt2 + Eth2-Mgmt2

SG3: Eth1-Mgmt3 + Eth2-Mgmt3

SG4: Eth1-Mgmt4 + Eth2-Mgmt4

If you have more than four SGs or don't have enough switch ports (or use MHO-170 that has only two management ports), the physical management interfaces can be shared. 

SG1: Eth1-Mgmt1 + Eth2-Mgmt2

SG2: Eth1-Mgmt1 + Eth2-Mgmt2

You can still create a magg out of these ports, but the mode must be XOR or active-backup. LACP is not supported for magg ports in Maestro.

 

mk1
Contributor

Thank you all for the replies! I will try to add ports 1 and 2 to both security groups and create magg (active-backup) inside each one.

0 Kudos
Reply
Ricki_S
Participant

Hi Lari_Luoma

I have configured Bonding MAGG with XOR mode and the switch(cisco) has been configured, but due to human error/missing, bonding MAGG one of the interfaces is lost in the switch(cisco) configuration when trying to combine interfaces in the switch configuration and disable->enable the interface on orchestrator, traffic can not even pass to the Maestro. Can  you tell me the good step to combine again the Bonding MAGG?

0 Kudos
Reply
mk1
Contributor

Hello all,

My MHO IP is 10.200.1.10 and the gateway is 10.200.1.1. The same gateway is a security group, part of MHO and also its management IP.
10.200.1.0/24 is part of the encryption domain of that SG, and now I can't reach Maestro (10.200.1.10) or other IPs from the same subnet via VPN, which I think somewhere were described as a normal behaviour. So currently all the hosts which are part of that subnet should be re-configured with different IPs and put on a separate VLAN.

I'm running R80.20SP T279. Do you know whether the issue with reaching management subnet via VPN is fixed in R80.30SP?

I think it shouldn't be an issue, but just in case I need your opinion - is it fine if Maestro IP is in different subnet from the SGs?
For instance I'm planning to add Maestro Mgmt to VLAN100 and give it IP 10.1.1.1, and then give SGs IPs from range 172.16.1.0/24 (VLAN200).

One more thing - may I break something if I change SG management IP in production environment?

Please let me know if I didn't describe clear enough all my questions.

Thank you!

0 Kudos
Reply
Anatoly
Employee
Employee

Hi, 

It's completely fine to have separated networks for MHO itself and Security Groups. 

Please keep in mind, we do no support VPN or NAT on management interfaces of Security Group, since it doesn't pass via distribution. Better not to pass non-management traffic via Management interfaces.

 

Thank you,

 

Anatoly

mk1
Contributor

Hello Anatoly,

Thank you for your reply! Let's say my management is co-located on another data center, and I'm going to use public IP of the SG for management. In case like this, do I need to add physical MGMT ports to the SG at all?

0 Kudos
Reply
Anatoly
Employee
Employee

Yes, you need physical Mgmt ports, but you can manage your security group via uplink (traffic) interfaces.

Please note, when web services of Security Group (Web UI, Captive portal, etc...) won't work when using L4 distribution, so in this case, you have to disable it

0 Kudos
Reply
mk1
Contributor

Hello Anatoly,

I apologise if I'm asking stupid questions, but why do I need physical MGMT ports if I'm going to use my SG public IP for management?

I'm not sure I understood correctly your second sentence - WebUI won't work if use public IP instead of MGMT or I got it wrong?

0 Kudos
Reply
Anatoly
Employee
Employee

1. Because otherwise you cannot complete FTW for security group

2. I will work only with L3 distribution (disable L4 distribution, which is enabled by default)

0 Kudos
Reply
mk1
Contributor

Thank you for your replies!

0 Kudos
Reply
Lari_Luoma
Employee
Employee

I was reading this and got a little confused if you are talking about the same thing here. 🙂

I strongly recommend migrating to a dedicated management interface architecture in Maestro. It will be much better solution in the long run. Some of the reasons include:
o  Cutover(s) will be easier with a dedicated management interface as we’ll be able to stay connected all the time.
o  We should be able to install policy before the cutover, so we can’t use the current production IP anyway.
o  When the management server communicates with the gateway (SG) only one SGM will be aware of the communication and responding when using the dedicated management interface. This simplifies troubleshooting.
o  Management interfaces are separate from data interfaces allowing management traffic even under high load.
o  Anatoly can confirm, but my understanding also is that the orchestrators have QOS type of rules enforcing availability of the management traffic (when dedicated management interfaces are used)
o  When you take ssh to the production interface, your connection lands on a random SGM that can be confusing.

All this being said you still should be able to manage the Maestro system over a production interface in security gateway mode (VSX needs to use the DMI). Your issue is not necessarily a Maestro issue, but related to VPN somehow. Any errors in the logs?

If you could share a network diagram it could help us to understand the issue.

0 Kudos
Reply
mk1
Contributor

Hello Lari,

I'm fully agree with what you said, but unfortunately in my case the management server is located remotely. That means I have to manage SG via it's public IP. Initially I configured LOM interfaces to be part of the same subnet which is part of the management interfaces, but after I learnt they can't be reached via VPN I had to move them behind data interfaces.

I was interested for the cases like mine, where the management server is located remotely, what is the purpose of dedicated management interfaces, but as Anatoly mentioned I just can't move on with FTW without them.

So here is my case with example - I have magg0 interface on MHO and SG, which is part of VLAN100 10.100.1.0/24.

SG1 - 10.100.1.1

MHO - 10.100.1.10 - GW: SG1

LOM1 - 10.100.1.11 - GW: SG1

LOM2 - 10.100.1.12 - GW: SG1

10.100.1.0/24 is part of VPN encryption domain and I wanted MHO, LOM1 and LOM2 to be reachable via VPN, but after this is not possible I had to move them to a separate VLAN which is part of data interfaces.

0 Kudos
Reply
mk1
Contributor

Hello all,

we have 1xMHO-140 with 2x6000 appliances connected to it. With this setup we could have only one security group, so I'm wondering what is the best approach for upgrade both appliances with the latest JHF? According link below we should divide them into logical groups, but I think this approach is fine when you have more than one MHO.

https://sc1.checkpoint.com/documents/R80.20SP/WebAdminGuides/EN/CP_R80.20SP_Maestro_AdminGuide/Conte...

As far as I can understand I have to proceed with the following commands:
g_clusterXL_admin –b 1_02 down

and in gclish:
installer import local <full path to jhf.tgz>
installer install 1 member_ids 1_02

After the secondary member is upgraded I have to the same with the primary one (SMO). Is that fine?
Is there a difference if I don't use the global approach with gclish and just go to the secondary member and type:
clusterXL_admin down

and in clish:
installer import local <full path to jhf.tgz>
installer install 1

and then do the same with the primary member.

What about if we need to upgrade to major version - for instance from R80.20SP to R80.30SP? What is the best approach in that case?


Thank you!

0 Kudos
Reply
Lari_Luoma
Employee
Employee

You can still upgrade the gateways one at a time. MHO and SG can run different takes. Since you have only one MHO, upgrading it will cause an outage due to reboot so plan a maintenance window for the MHO upgrade. 

0 Kudos
Reply
mk1
Contributor

I did the upgrade with:

g_clusterXL_admin -b 1_02 down
installer install 1 member_ids 1_02

g_clusterXL_admin -b 1_01 down
installer install 1 member_ids 1_01

But I'm still wondering what will happen when I have to upgrade from R80.20SP to R80.30SP.

0 Kudos
Reply
Anatoly
Employee
Employee

Hi,

Upgrade from R80.20SP to R80.30SP is not supported, because there are versions for different appliances. Appliances which works with R80.20SP are not supporting R80.30SP (except 23K), and newer appliance which support R80.30SP does not work with R80.20SP

Thank you,

Anatoly

mk1
Contributor

Thank you Anatoly! This is something new for me and I didn't expect it. So it seems from the whole 6000 series only 6500 and 6800 don't support R80.30SP. This is curious...

0 Kudos
Reply