Maestro basic setup documentation

[Maarten_Sjouw]

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

[Maarten_Sjouw]

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.

[Maarten_Sjouw]

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.

[genisis__]

If you have two MHO's in each sites are you saying the only SYNC port that is required is the external one (47)?  I would have though the internal SYNC port would also be required for local SYNC traffic.

[Lari_Luoma]

In a dual site implementation you need at least two sync ports, one is the orchestrator sync between the orchestrator at the same site and one is a site sync, between the sites.

[genisis__]

Great, that makes sense.

[MikeB]

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)

[Lari_Luoma]

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

[MikeB]

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?

[Lari_Luoma]

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

[Anatoly]

Not mandatory, but better to have the same amount

[Maarten_Sjouw]

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.

[Northy]

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?

[Maarten_Sjouw]

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.

[mk1]

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!

[Norbert_Bohusch]

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]

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.

[Lari_Luoma]

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]

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.

[Ricki_S]

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?

[genisis__]

Does this still apply in R80.10? 

[Lari_Luoma]

I believe you mean R81.10? R81.10 supports uplink sharing.

[genisis__]

Sorry, yes R81.10+

[mk1]

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!

[Anatoly]

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]

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?

[Anatoly]

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

[mk1]

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?

[Anatoly]

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)

[mk1]

Thank you for your replies!

[Lari_Luoma]

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.